RE: cvs add <directory>

[Paul Sander]

>--- Forwarded mail from address@hidden

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

The method you've described in the past depends on a linked structure
involving having users write special syntactic sugar in their commit
comments, then sorting out which versions of the RCS files to dump out.
How does traversing such a structure, robustly, be simpler than a single
layer of indirection?  I fail to see the elegance of such a solution to
this particular problem.

>K.I.S.S.

And I believe the proper quote is "Keep it as simple as possible, but
no simpler."

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

What about converting ASCII text documentation to Rich Text format or
XML?  These are not binary formats, yet the same restrictions apply.
A product development effort should be able to make this type of change
at any time without having the tool balk in some way.

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

This only works if you can forsee all possible directions that a project
can take over its lifetime.  That means the project is either very simple,
or a short lifetime is planned.  Neither of these is realistic in the
general case.

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

In other words, never reuse part of your filesystem.  Sound advice.  NOT!

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

Not in any meaningful way, it doesn't.  Better still to side-step that
particular problem and never rely on a content merge to discover this
kind of change.

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

Architects cannot forsee every possible way the project might grow over
time.  The project must be able to evolve, and it is unacceptable that
tools such as CVS would impose arbitrary limitations.

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

If this were true, then only product releases would be checked in.
I believe that developers must be permitted to check in their work
arbitrarily.  To do otherwise invites them to circumvent whatever
process is in use by the shop.  How many times have the users been
confused by missing changes after having cp'ed files from another
user's workspace?  It's way better to support code sharing by committing
changes and dealing with the blunders later.

Oh, they're not allowed to make mistakes?  Too bad.

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

I did.  Brian knew that a "rename database" was necessary.  And he realized
that he didn't understand all of the issues, so he didn't produce a robust
solution.

Oh, and by the way, simplicity at the cost of robustness is a cop-out.
There are more; just look in the CVS source code for the word "punt".
Also consider the use of /bin/true as a most elegant version control
solution.

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

"Radically complicate"?  "Add immense complexity"?  These are vacuuous
claims, Greg.  Surprisingly, the CVS implementation is robust enough
to extend it without undue grief.  Don't believe me?  Take a look at
another one of my hot buttons:  A datatype-specific merge tool registrar.
I've already proven, with a simple patch (despite your claim that it
could not be done simply), that such a feature could be built into CVS
by doing it.

I do believe that adding a layer of indirection will break backward
compatibility with the existing implementation, meaning that existing
servers would not work on new repositories, and existing clients would
not work with new servers.  I also believe that a straightforward conversion
is possible, so that end users will not notice the difference until these
funny corner cases suddenly start working in reasonable ways.

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

No database is needed.  It can all be done with RCS files and a new
locking mechanism.

Oh, and a project is defined by its identifying qualities, which does
not always imply its name.  In the case of CVS, the identifying qualities
are the concurrent development paradigm and its command line.  Arguably it
also includes all end-user visible artifacts found in a workspace.  The
repository itself is an artifact of the implementation, and changing it
does not affect the identity of CVS.  Don't believe me?  See how the CVSROOT
directory has changed over the years, and how different features of RCS
files have been interpreted differently over time.

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

CVS serves the same audience as those other tools, and is subject to the
same pressures.  The difference is that CVS is a hobby project, and no
one willing to work on it is willing to implement these features.

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