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: Mon, 18 Jun 2001 14:10:49 -0400 (EDT)

[ On Monday, June 18, 2001 at 00:51:22 (-0700), Paul Sander wrote: ]
> Subject: Re: BRANCH LABEL FOR DIRECTORIES
>
> 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.

NO, it does not "hide" it either.  Any semi-sentient being can find it
in no time at all.

> 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 audit trail is not necessarily dependent on the user -- there are an
almost infinite number of ways to mechanise and automate its creation
(and its tracking too)!

>  The version control system should track the rename separately,
> in the version history but separate from the user's comments.

Why?  There's no logical difference.

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

I think you're living in a dream world of marketing driven featuritis.

I've been using CVS intensively for how many years now?  Eight?  I've
*NEVER* had any major problems with renames, and I don't just avoid them.

> What if you rename the top directory of a deep tree?  That's a LOT of
> manual merging to do.

Why would anyone do anything so idiotic?

>  And sometimes the rename is necessary.

No, such things are *NEVER* "necessary"!  It's a figment of your
imagination.  It might be highly desirable, but never ever "necessary".

>  And
> sometimes the users expect the rename operation to be both reversible
> and repeatable.  CVS does not provide this capability in any sense.

Ha! Of course some users, such as perhaps yourself, have totally
unrealistic expectations.  That's the nature of the game.  CVS isn't a
market driven product -- it's a freeware niche product.  You're
comparing apples and oranges and then wondering why there's no
consistent taste between the two.

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

Users who do idiotic things like that will get stupid results.  G.I.G.O.

CVS is not a system for button pushing automatons -- you have to think
to use it properly.

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

Fine.  Go use such a system and forget you ever heard about CVS.

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

In your dreams 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]