Re: BRANCH LABEL FOR DIRECTORIES

[Greg A. Woods]

[ On Sunday, June 17, 2001 at 10:40:03 (-0700), Paul Sander wrote: ]
> Subject: Re: BRANCH LABEL FOR DIRECTORIES
>
> The truth is, that there are times when the revision history must be
> retained when a file is re-added, and there are times when it must not.
> CVS makes no distinction between these two cases, and always keeps
> revision history.

Yes, which is what allows the user to choose when to ignore the
past-lives history.  Like I said, an option (ON by default) to stop
showing history after the first dead revision is encountered would
easily push this decision to the user.  This should be the best of both
worlds.

> I personally don't care if empty directories are managed or not.  It matters
> to others, so I warn them in advance.

That's not what you were doing.....

The best response would be to tell people to always put at least the
following in their ~/.cvsrc; and to tell them that CVS does not manage
revision history of directories since that's antithetical to its design.

        checkout        -P
        update          -d -P

>  And it does matter later if something
> is added to the directory and the build process depends on its absence.

That's pure nonsense!  Obviously if something's added in a directory
that the build process doesn't expect to exist then the build process
will have to be adjusted to deal with it!  CVS is not a build system
(though it can manage the changes to one).  Sure the build might be
broken for a short while if the initial committer hasn't tested
everything properly before committing, but anyone who freezes a release
with such breakage gets all that they deserve.

> The way in which CVS operates will sometimes cause empty directories to
> appear, and other times not.  This is confusing to most users, and they
> learn to rely on the wrong behavior because it's the default case.

People who use CVS correctly will never have empty directories.  The
"correct" way was intended to be the default way many many many years
ago but once Brian Berliner stopped directly managing the code the folks
who took up the reins were stupidly paranoid about changing the
necessary options and "conveniently" forgot to do so even over two or
three releases.

> In an SCM environment, this is quite simply wrong.  When a file is renamed,
> its version history must survive the relocation.  Why you don't understand
> this is beyond me, but it's a critical need when merging renames across
> branches.  Version history does not survive the delete-and-add sequence.

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

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

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

I cannot understand why you ignore the very simple concepts used by CVS
and instead try to apply some ideals meant for a system with a totally
different design.  Its as if you have a one-track mind for ClearCase or
whatever it is that taught you what you know.

Even worse you continue to bad-mouth CVS instead of explaining how it
works and how to use it effectively.  If you don't like it and/or don't
understand it then you should simply keep quiet (and maybe even try to
learn its simple concepts instad of misleading people).

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

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.

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

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

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

-- 
                                                        Greg A. Woods

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