RE: renames under CVS

[Paul Sander]

>--- Forwarded mail from address@hidden

>[ On Tuesday, February 26, 2002 at 19:50:23 (-0800), Noel Yap wrote: ]
>> Subject: RE: renames under CVS

>> > We would also need a graph showing how many of those
>> > files could be
>> > harmlessly renamed in the repository (i.e. which
>> > have tags and branches,
>> > and which do not).
>> 
>> Why would files with tags and branches be any
>> worse/better off than those without?

>Do I really have to explain this?  I think it should be completely
>self-obvious to anyone who's used CVS for even one project over even
>just two releases.  Certainly anyone who understands how renames work in
>CVS should instantly understand why.  This has been discussed many times
>in the past in this forum too.  I think you've even participated in some
>of those past discussions.

>Sigh, oh well, one more time for old time's sake:

>Files without tags or branches can be safely and easily renamed in the
>repository, leaving no evidence that they ever existed under the old
>name since that old name is not yet relevant to the overall change
>history of the project.

>Yes other cleanups in the build makefiles/scripts/etc., or #include
>lines, etc., which may have referenced the old name will have to be
>adjusted, and the commits of these changes will leave traces of the old
>name and when it was obliterated, but in the bigger picture these little
>details are irrelevant.

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.

>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!

>Yes some degree of serialization is necessary,

Mark the date and time, Noel, Greg made a concession!  Congratulations!
:-)

>but even on a large
>project with users working around the clock around the world this isn't
>a difficult thing to prepare everyone for (I've been part of such a
>change -- it worked just fine with no hitches and no complaints and no
>adverse after-effects).  Apply the K.I.S.S. principle, do some
>expectation management with your colleagues using a touch of T.L.C. and
>then get on with your life and your project!  Geez man!  What's so hard
>about all this?  We're dealing with practical systems here, not some
>pie-in-the-very-blue-sky dream machine with 100% ultimate perfection and
>complete and total error free operation and abslolute fool-proof features!

We're not asking for "100% ultimate perfection and complete and total
error free operation and abslolute fool-proof features".  We just want
something that works most of the time and satisfies our needs.  You're
the one making this all-or-nothing distortion.

>> I'm guessing you don't include "being able to work
>> with others" as part of your criteria in assessing
>> success.

>Some of you people seem to be being blinded by your tools I see....

I think we see a lot farther than certain others...

>--- End of forwarded message from address@hidden