Re: BRANCH LABEL FOR DIRECTORIES

[Paul Sander]

>--- Forwarded mail from address@hidden

>[ On Sunday, June 17, 2001 at 10:40:03 (-0700), Paul Sander wrote: ]
>> Subject: Re: BRANCH LABEL FOR DIRECTORIES

>Paul, quit spreading F.U.D.!!!!!

>CVS NEVER automatically deletes ANY version history whatsoever!!!!!
>Therefore, obviously, in CVS the revision history DOES survive!!!!!

No, it doesn't delete it, but it does hide the old stuff (which is just
as bad).  Once the remove-add sequence is done, there is no reliable
method to track down the original location, and under some circumstances
there may even be no way for the end user to recover it.

>Revision history for renamed files is TRIVIAL to find and examine!!!!!!

I beg to differ.  Even in your preferred method, you rely on the user
to carefully leave a bread crumb trail, by noting the rename in the commit
comment.  The version control system should track the rename separately,
in the version history but separate from the user's comments.

>> Next, you're going to say that there's no problem here that a linked list
>> can't solve.  But there is:  In CVS, the list must track all branches to
>> the original source to support merges properly.

>Nobody said anything about supporting merges across renames.  Such a
>feature is simply not necessary in a basic version tracking system like
>CVS.  It could of course be built on top of CVS though (eg. as a wrapper
>script, or in a custom client).

You're kidding, right?  Don't support merging across renames?  This
capability is one of the most basic requirements of any version control
system worthy of the name.

>In the mean time for those few times when renames and merges are
>necessary it is relatively easy for a user to do a manual merge.  All
>the revision history, including all past deltas, is still there to
>extract.

What if you rename the top directory of a deep tree?  That's a LOT of
manual merging to do.  And sometimes the rename is necessary.  And
sometimes the users expect the rename operation to be both reversible
and repeatable.  CVS does not provide this capability in any sense.

>>  Worse, if the original file
>> is re-added as a different type, then appending it to the old version history
>> is useless and possibly harmful.

>People using different file "types" in CVS are already doing things well
>beyond the design goals of CVS and are therefore strictly on their own.
>CVS does not really have any proper concept of file "types", after all.

Okay, let's pick nits and say only that the format of the data contained in a
file changes.  Let's say that it changes from RTF to HTML.  Strictly speaking,
the file's "type" does not change, but using CVS in the normal way produces
gibberish in certain cases that are easy for the average user to fall into.
This just would not happen if version histories tracked the entire lifetime
of a file, not just that portion of its life when it occupied one spot in
the filesystem.

>>  It's much better to keep a file's complete
>> revision history over its entire lifetime (regardless of its location in
>> the filesystem), and to keep version histories unique for each file
>> (even if it occupies the same place in the filesystem as another file
>> on differing branches or different stages of the product's lifecycle).

>Paul you are ignoring some fundamental aspects of CVS, much to your
>detriment (and to those of people who don't critically review what you
>write).  CVS cannot do what you think you want it to do, in the way you
>think you want it to.  Perhaps you should unsubscribe from this list and
>go seek help elsewhere.

>Meanwhile the people who wish to understand and use CVS properly can
>learn that CVS tracks the revision history not by it's logical content,
>but rather by its label and position.  Renaming a file within CVS is
>simply a matter of stopping the use of one label in one position and
>starting the use of another label in another position.  This should be a
>very simple concept to learn, and indeed with a little experimentation
>CVS can demonstrate these concepts with great clarity.

No, I'm not ignoring some fundamental aspects of CVS; I'm exposing them.
The correct way to track revision history is to keep its logical content,
label, and position inseparable.  When one changes, the rest must follow.
CVS does not do this, that fact causes a lot of problems for a lot of
users.

>Of course people reading the manual should also be warned that it is
>still somewhat misleading and gives some very very bad and self-
>contradictory advice on the topic of renames.  The only correct way to
>rename a file is that described in the node "The Normal way to Rename".
>The "Moving the history file" trick is just plain wrong -- such a thing
>should never ever Ever EVER be done (if you want to use CVS properly),
>and the manual should simply warn never to do it (and people who think
>they know better can void their warranty if they want).  The trick
>dscribed in the "Copying the history file" node is also wrong as it is
>not generically "safe" and it does not even work correctly in all cases,
>especially not if you are using branches.  It should probably also be
>deleted entirely from the manual, though maybe it could be documented in
>a special appendix so that people who think they know better will at
>least have a reference of how to do it half-right and will be clearly
>told of the disadvantages (not all of which are currently documented).

Or, CVS could be changed to really do it right...

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