RE: cvs add <directory>

[Greg A. Woods]

[ On Sunday, May 25, 2003 at 19:51:07 (-0700), Paul Sander wrote: ]
> Subject: RE: cvs add <directory>
>
> 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.

Yup.

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

Because it is done independently of of the repository, and works just as
well from any arbitrary client, and it can even be done by hand.

It might not be as efficient as possible, but it's certainly simple and
elegant, and since it's not by any measure a critical function it
doesn't have to be all that efficient.  Indeed given the rarity of this
requirement in the real world it's usually sufficient to leave it as a
manual process.  That's certainly worked well enough for me and for
several of the free OS projects.  Even the NetBSD repo admins have come
to realize that this is sufficent as they've backed down from their
original policy of doing deep copies in the repo.

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

Paul!  Use the right tool for the job!  If you have to manage change in
files in which those changes cannot be readily displayed and managed
with diff, patch, et al, then you need to choose a different version
tracking tool -- one that can do what you need it to do.

CVS is not, and was never intended to be, a complete software
configuration managment solution.  Please RTFM again and try not to
forget this fact this time!

A complete software configuration system for a large project may include
several different version tracking tools, several different build tools,
as well as overall processes and procedures which tie them all together.

If you think you can achieve a coherent and comprehensive software
configuration solution with one tool, then PLEASE GO USE IT!

> This only works if you can forsee all possible directions that a project
> can take over its lifetime.

Paul that's what "engineering" is all about -- dealing with real-world
change and managing a project over its lifetime.

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

You're spreading F.U.D. again Paul.  That is most definitely not what I
said -- quite the opposite.  See above.

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

You're spreading more F.U.D. Paul.

Conflict detection WILL ALWAYS catch merges between different files that
share the same name in the filesystem with more than enough "meaning"
for any even minimally talented programmer to figure it out.

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

You didn't read what I wrote again Paul.  "milestones" are not "releases".

> I believe that developers must be permitted to check in their work
> arbitrarily.

THEN PLEASE GO USE SOME OTHER TOOL WHERE THIS USAGE PATTERN WORKS!!!!!

In CVS this is even documented as a "Bad Thing", as it will be with most
types of concurrent versioning systems which encourage developers to
update early and update often:

    When to commit?
    ===============
    
       Your group should decide which policy to use regarding commits.
    Several policies are possible, and as your experience with CVS grows
    you will probably find out what works for you.
    
       If you commit files too quickly you might commit files that do not
    even compile.  If your partner updates his working sources to include
    your buggy file, he will be unable to compile the code.  On the other
    hand, other persons will not be able to benefit from the improvements
    you make to the code if you commit very seldom, and conflicts will
    probably be more common.
    
       It is common to only commit files after making sure that they can be
    compiled.  Some sites require that the files pass a test suite.
    Policies like this can be enforced using the commitinfo file (*note
    commitinfo::.), but you should think twice before you enforce such a
    convention.  By making the development environment too controlled it
    might become too regimented and thus counter-productive to the real
    goal, which is to get software written. 

Note also that more and more people are choosing to use two-phase commit
systems such as Aegis, and those definitely do not allow arbitrary
checkins -- they take testing and peer review to a new level!

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

That clearly flies in the face of discussions which occured on this
list, and clearly whatever discussions you had very much pre-date the
"dead" state for removal checkins.

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

More F.U.D. Paul.

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

So, why haven't you long ago left this forum and gone to help some other
versioning tool project achieve these goals you seem to think are so
important?  If you have already done so, then why don't you stay there?
Are you just here to spread F.U.D.?

> CVS serves the same audience as those other tools, and is subject to the
> same pressures.

You are very wrong, but if you don't believe me then please at least try
to (re)read ESR's "The Cathederal and the Bazaar", and maybe also try
watching the documentary "Revolution OS".  It worked for Jim Clark,
maybe it'll work for you too.

>  The difference is that CVS is a hobby project, and no
> one willing to work on it is willing to implement these features.

Hmmm... that's odd -- I and many others have been paid professional fees
for some of the work we've done on CVS.  The difference is that the
project doesn't always take up all the paid-for features that some _one_
may have wanted.

The only problem with CVS is that there's no project leader, no visionary.

-- 
                                                                Greg A. Woods

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