Menu
▾
▴
#21 hop tweak using wrong version
We had a file, say revision 1.10. Created and closed
a new change containing revision 1.11. That change
was failed and we wanted to check-in an 'undone'
version, essentially revision 1.10 again.
We tried using hop tweak and it reported that the code
had not changed. It seems to be comparing the
submitted file to revision 1.10 still, even though
there's a 1.11 checked in. Seems to me it should be
comparing the file to version 1.11. If we create a
new change and check in the original code, it works.
Actually, we've had this happen a couple times, where
a change has failed and we've wanted to basically
throw away the change and go back to the code's prior
state. Maybe there's value in looking at some sort
of 'undo change' that reverts all the files back to
their previous revision and marks the change as
invalid. I'd peg that as a low priority though.
Logged In: YES
user_id=161477
This is probably caused by sticky tags on the file. The
"tagged" revision is probably still 1.10. I think.
If this is the case, you may need to "break" with the hop
model and do a "cvs update -A" on the file, to removed the
sticky tag.
Logged In: YES
user_id=280857
Yep, it's centered around the cvs diff -w in checkForChanged
and the sticky tags
Say I have version 1.1, modify it, then create a change with
version 1.2 but don't apply it. I then undo all my changes
locally, so that I'm sitting back at revision 1.1. cvs diff -w
compares my file to the last revision I checked out, which
would be 1.1, and states there are no changes.
If the check is modified to include the latest revision number,
i.e. cvs -w -r 1.2 that works. Not sure what effect that would
have on the checkIn method which also calls
checkForChanged, though.
That should be ok, if I can get either the number of the latest
revision in the last closed change, or get it directly from cvs.
I'll look more into it later.