info-cvs
[Top][All Lists]
Advanced

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

Re: BRANCH LABEL FOR DIRECTORIES


From: Greg A. Woods
Subject: Re: BRANCH LABEL FOR DIRECTORIES
Date: Sat, 16 Jun 2001 14:13:39 -0400 (EDT)

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

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

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

Quit spreading F.U.D. Paul.

-- 
                                                        Greg A. Woods

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



reply via email to

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