info-cvs
[Top][All Lists]
Advanced

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

RE: cvs add <directory>


From: Paul Sander
Subject: RE: cvs add <directory>
Date: Sun, 25 May 2003 11:25:17 -0700

>--- Forwarded mail from address@hidden

>[ On Saturday, May 24, 2003 at 11:50:33 (-0700), Shankar Unni wrote: ]
>> Subject: RE: cvs add <directory>
>>
>> And the solution, in terms of CVS, may well be some compromise like
>> MetaCVS, where you give up the idea of the repository structure
>> mirrorring your object directory structure. Instead, your "files" are
>> just synthetically named objects, and you have a meta-data file that can
>> be versioned and used to recreate the actual object structure on
>> checkout.

>What do you think you would gain by adding all that complexity?

>The only valid reason that anyone over the past decade of discussion
>surrounding CVS and CVS-II, including Paul and yourself, has ever come
>up with for adding even a tiny amount of the kind of complexity you're
>talking about is the supposed ability to _automatically_ merge changes
>between renamed files on different branches.

Plus the following:
- Storing the complete history of a file in one place, and easily viewing
  it.
- The ability to replace a file with a new one having a different data
  type.  (For example changing keyword expansion from -kkv to -kb without
  affecting how the user generates workspaces by tag or datestamp.)
- Storing version histories of distinct files separately, even if they
  share a spot in a workspace at some time.
- Disallowing merges between distinct files that happened to share a
  spot in the workspace at some time.

>In reality the need to do this is, for all intents and purposes,
>absolutely zero in any and all projects where CVS is best suited for use
>as the version tracking tool.  I.e. it's not because CVS is limited in
>this way that CVS is only useful for such projects, but rather that CVS
>is useful as-is for such projects because this ability is never needed
>for them.

I don't know what reality you're living in, but this comes up several
times over the lifetime of a big project.

The only projects there CVS has met all of the requirements of a project
(for me, anyway) have been short-lived prototypes or toy projects.  Some
show-stopper has always come up when things get serious.

>In reality the ability of CVS to record the generic structure of the
>workspace by mirroring its structure into the repository is the very
>most elegant solution for any tool which needs to do what CVS is
>designed to do.

The direct mapping has its limitations, as we're seeing, and it's a cop-out
while the designer punted on an issue that he didn't fully understand.
Adding a layer of indirection does not add significantly to complexity, nor
does it detract significantly from the elegance of the solution.  (Some would
argue that adding the indirection enhances the elegance, if the payoff is
large, which it is.)

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





reply via email to

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