info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: BRANCH LABEL FOR DIRECTORIES


From: Paul Sander
Subject: Re: BRANCH LABEL FOR DIRECTORIES
Date: Sun, 17 Jun 2001 10:40:03 -0700

>--- Forwarded mail from address@hidden

>[ On Saturday, June 16, 2001 at 09:50:38 (-0700), Paul Sander wrote: ]
>> Subject: Re: BRANCH LABEL FOR DIRECTORIES
>>
>> One of CVS' worst design flaws is that it does NOT version directories.

>That's *NOT* a flaw!  That's a *FEATURE*!  And a very valuable one at that!

>In fact one can easily argue that it was an explicit design goal!

>The only major implementation flaw with this feature in CVS is that when
>a previously deleted file is re-added then the new file appears to have
>the history of the old deleted file too.  There are several possible
>ways to fix this, the easiest being to simply have "cvs log" and friends
>stop printing history, by default, just after they encounter a "dead"
>revision.

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.

>> Files appear as they are added,

>and disappear as they are removed...

>>  and CVS relies on timestamps and tags
>> to reproduce the proper combination of file versions from the past.

>timestamps _OR_ tags, but hopefully people primarily use tags for
>anything related to release management.

>Yes, it's all quite nifty and automatic, just as it should be.

>> The result is that managing empty directories is difficult at best, and

>Why would you ever want to manage empty directories?!?!?!?!?

>You should create them in your build process, if absolutely necessary
>(eg. "make obj" in the *BSD build process).

>This stupid issue has been discussed to death over the past eight or so
>years.  Why you want to always bring it up again is a mystery to me.

I personally don't care if empty directories are managed or not.  It matters
to others, so I warn them in advance.  And it does matter later if something
is added to the directory and the build process depends on its absence.

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.

>> you can't reorganize your sources (e.g. rename a file).

>Yes, you CAN.  All rename operations, in all facets of computing, is
>simply a deletion and an addition in whatever order is appropriate (and
>sometimes it's an atomic operation from the point of view of the user,
>and sometimes, as currently in CVS, it's not).

>CVS even optimises away the handling of deleted files so that moving
>files from one directory to another doesn't always cause the performance
>penalty of scanning all the deleted files.

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.

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

>Quit spreading F.U.D. Paul.

This is not FUD, it's fact.  CVS just can't handle these situations in its
current form, and its developers remain unresponsive to these requirements
despite many years of heated debate.

So, my advice to the original poster is this:  If these situations are
important to you, look elsewhere.  If you never need to reorganize your
source tree, then (barring its other limitations) CVS might work for you.

--- End of forwarded message from address@hidden




reply via email to

[Prev in Thread] Current Thread [Next in Thread]