RE: renames under CVS

[Greg A. Woods]

[ On Wednesday, February 27, 2002 at 00:07:04 (-0800), Paul Sander wrote: ]
> Subject: RE: renames under CVS
>
> What if someone realizes that a tag really was needed, and checks out
> with a timestamp after the fact?  That happens, too.  In fact, it just
> happened in one of my shops within the past two weeks.  Moving the
> file in the repository would have broke the reproducibility requirement.

What the hell are you complaining about?!?!?!?!?

OBVIOUSLY the file would simply be moved back to its original name in
the repostiory, and then it would be renamed using the proper
'add/remove' procedure and any history (revisions and tags, etc.) would
be moved to the new file!  Geez!  What a stupid question!  You're really
grasping at ever shorter straws now!


> > If you actually try this you'll find that it's possible to prepare a
> > working directory with all the necessary secondary changes, and to
> > commit those just prior to making the move in the repository itself.
> > Everyone else with an active working directory will simply "cvs update"
> > (and deal with any merges the same way they would if the file had been
> > renamed using the "add/remove" procedure).
> 
> Hmmm...  That means doing the update, then locating the original version
> from which the sandbox derives (after losing the version number during
> the update), checking it out to a temporary location, and running diff3
> or merge by hand (on the original version, the modified sandbox copy in
> the original location, and the new sandbox copy in the new location, and
> resolving the conflicts as necessary), then renaming the output of the
> merge into the new location.  Five steps!  FIVE!!  To complete an
> operation that should take TWO!  (Count 'em:  update and edit.)  This
> is rediculous!

Now what are you whining and moaning about?  You clearly did not do as I
said you should do and actually try this at home yourself before
spouting off more untruths and attempting to spread yet more F.U.D.

In this case you don't need to do a separate checkout and 'diff3' --
you're only dealing with one set of changes, not a merge of two sets.
Even if you were really lazy and didn't update before someone committed
a new revision to the renamed file you're still only doing a one-way
merge, and it's merely the opposite of what would happen normally if
you'd done the update immediately and then done an update again after
the first new rev was committed (i.e. you're moving your changes instead
of the new rev's).

The revision number of the original file in the working dir is not lost,
it is right there before your eyes when you type 'cvs status oldfile'.
You simply move your changes to the new file with ONE step:

        cvs diff -r OLD.REV oldfile | patch newfile

(yes, I can count -- that's two steps total, no more than what you said
it should take)

Now if you actually had done this at home, as I had done, you would have
been able to try to claim you'd found a bug I had not reported and try
to turn the tables on me yet agin (and indeed I did not report it
because I wanted to see if you would try to do this -- but thanks for
being so predictable and not trying the test!).  Anyone want to "guess"
what the bug is?  (maybe I can even find a fix before Paul figures it
out!  ;-)

-- 
                                                                Greg A. Woods

+1 416 218-0098;  <address@hidden>;  <address@hidden>;  <address@hidden>
Planix, Inc. <address@hidden>; VE3TCP; Secrets of the Weird <address@hidden>