RE: renames under CVS

[Greg A. Woods]

[ On Tuesday, February 26, 2002 at 19:50:23 (-0800), Noel Yap wrote: ]
> Subject: RE: renames under CVS
>
> One of the side topics of this thread is XP.  You
> wouldn't be doing XP if you do "ideal, or even just
> better, planning of your modules".

No, not this thread -- this thread is about renames alone.  Please don't
drag in irrelevant issues.  XP is not for everyone, nor even for the
majority, at least not without a _lot_ of "fixing".

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

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).

Yes some degree of serialization is necessary, 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!

> > Finally of course we'd need to find some way to assess the difference
> > between an ideal filename, and one that's suitable and sufficient for
> > the purpose.  While we might all like to rename many of the files and
> > directories in our projects, there's no fundamental necessity requiring
> > us to rename files that are not "grossly" mis-named.
> 
> This measure would be extremely subjective.

That's partly my point!  ;-)

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

-- 
                                                                Greg A. Woods

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