RE: cvs add <directory>

[Greg A. Woods]

[ On Sunday, May 25, 2003 at 11:25:17 (-0700), Paul Sander wrote: ]
> Subject: RE: cvs add <directory>
>
> Plus the following:
> - Storing the complete history of a file in one place, and easily viewing
>   it.

You can do that now -- you just have to have more than two bain cells to
rub together.  Anyone with any decent amount of intelligence could even
write a font-end driver program that could present coherent reports
covering the history of files across renames.  Indeed examples have
already been posted.

You sure as heck don't need any new layer of indirection and all its
associated additional complexity just to implement such a feature.

K.I.S.S.

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

If you need to do that then you are abusing your repository.

You shouldn't have any binary files in the first place, and if you've
resigned yourself to the limitations of keeping binary files in CVS then
you should have had the foresight to make damn sure they are isolated in
their own module and that they are not going to get into such clashes.

Engineer your projects from start to end, don't just let them happen.
The bigger they are, the more critical this is!

K.I.S.S.

> - Storing version histories of distinct files separately, even if they
>   share a spot in a workspace at some time.

This is only a requirement if you start down the slippery slope you seem
to like to slide down every so often.  If, on the other hand, you simply
keep things simple as they are now then you don't have to worry about
this issue because it's automatically handled by the current design.

> - Disallowing merges between distinct files that happened to share a
>   spot in the workspace at some time.

Why bother?  Conflict detection will always catch this kind of thing.

K.I.S.S.

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

Like I said, your engineers are either abusing the repository, or
they're not very well trained software engineers in the first place.

The repository, at least if you're using CVS or something like it, is
for recording important milestones in the history of the project, not
for recording every silly blunder or every keystroke everyone makes
along the way to each milestone.  Blunders may happen, but you should
try to avoid them, and even undo them when possible, not record them!

K.I.S.S.

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

The elegance of the implementation is a "cop out"?  Get real.  The
designers of CVS and CVS-II very deeply understood the issues here.  If
you don't believe it, i.e. if you can't see that this is obviously true
from their resulting implementations, then please ask them directly.

> Adding a layer of indirection does not add significantly to complexity, nor
> does it detract significantly from the elegance of the solution.

Now you're really out in some dream land somewhere.

The only limitations are in the minds of those not willing to learn how
to do things the simple, easy, and obvious ways.  _Think_ before you
name something!

Any and all of the features you're talking about would radically
complicate CVS, and worse if any kind of backward compatability were to
be retained for existing repositories then you'd really end up with a
can of worms.  The use of the filesystem to maintain structure is the
most simple implementation possible -- anything more adds immense
complexity since there's nothing there now.

K.I.S.S.

If you want to store your code in a database then please do.  If you
want to create a CVS-like end-user API for your database, then please
do.  If you want to try to use and extend the CVS client-server protocol
for your database, then please do.  Just please don't try to confuse the
masses by trying to call your resulting concoction "CVS".

Note that the tools you are so fond of holding up to the light as what
you think are good examples of such tools have actually evolved under
the complex pressures of the commercial software marketplace.  They do
not in any way resemble what would likely have resulted from an open
source attempt to build similar tools.  They contain a multitude of
features that are useless to vast numbers of their users and which are
there only because their owners thought those unnecessary features would
help hold or grow the market share of their tools.  Open source software
such as CVS does not have to fight for market share -- it is free to
meet only the real needs of its users.

-- 
                                                                Greg A. Woods

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