Re: address@hidden: Re: rename in cvs]

[Greg A. Woods]

[ On Thursday, October 11, 2001 at 19:51:13 (GMT), Kaz Kylheku wrote: ]
> Subject: Re: address@hidden: Re: rename in cvs]
>
> It's only not the same file because of the braindamaged version control
> system which cannot represent that semantic idea! As far as the user is
> concerned, it is the same file, under a different name.
> 
> Merely, the software has failed to capture the user's perfectly
> sensible idea. Instead, it provided a half-baked emulation: delete the
> old, recreate under new name.

I think you have extremely unrealistic expectations.

I suggest you do a survey of similar tools and count the number that can
do exactly what you want.  I suspect you'll find that number to be quite
low and almost certainly only include high-end commercial packages.

> This breaks seriously, for instance, under merging.  Suppose work takes
> place on FOO on a branch. Then on the trunk FOO is removed, and a BAR is
> created with identical contents, in order to emulate a rename.  When the
> branch is later merged, the FOO patches will not be applied to BAR.

Indeed -- you've spotted one of the many limitations of CVS.  While it
likes to do merging, a lot, it doesn't always know when to do merges and
it cannot be relied upon to do all merges and to always do them
correctly.  The programmer is still ultimately responsible for all
merges.

> Moving
> the patches to BAR will require error-prone manual work.

Merging is always potentially error prone.  Manual merging is often
almost ininitely _LESS_ error prone than automated merging.  Why the
heck do you think some people oppose CVS so much?  It's primarily
because they don't trust automated merging!!!!  It is certainly not a
bad thing that CVS forces you do to some manual merging.  It might be
nice if it could store more metadata to suggest to you when you have to
do a manual merge, but it doesn't and so you must keep track yourself
and verify that the results of all merges include all of the changes you
intend them to keep.

> This should be pereceived as enough of a problem to completely deter
> clueful users form trying to rename files.  The best way to view CVS
> is that it does not handle renames at all, so don't even think about
> ever doing it using *any* of the methods recommended in the manual.

Well, if you have lots of branches you want to avoid renames as much as
possible, but it's not a dead-end un-penetrable brick wall -- a little
bit of consiousness is all it takes to work around this limitation.

The biggest trick is to learn to plan properly.  If you do your renames
at major milestone markers in your development process then you can
likely eliminate most of the need to merge changes across the renames.

This isn't rocket science -- it's really quite basic accounting.
There's really nothing new about this limitation -- any tool more
primitive than CVS would have similar limitations and any experience
developer should know that big changes which have no semantic meaning
must be planned carefully so that they don't obscure other changes.

People did change management manually for decades.  CVS can do much of
the really mundane work, but it is not a complete change management
system.

> I can live without being able to view the complete history of the
> object in one piece. But the other breakage, in particular merging,
> makes it totally unacceptable to do a rename.

I think you've got big blinders on.  If you expect one tool to suddendly
do everything and totally eliminate any and all manual change management
then you will likely never be satisified.  Take your blinders off and
learn to do some of the tasks "the hard way" -- it really isn't all that
hard and so long as you don't do too many renames in places where
merging will eventualy be necessary you won't have very much trouble
managing your changes around renames.

> I accept the limitation only because CVS has open source code, a suitable
> redistribution license, good reliability and a set of capabilities that
> is good enough for many purposes. 

In the freeware markeplace there's always room for more tools!  :-)

-- 
                                                        Greg A. Woods

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