RE: cvs add <directory>

[Paul Sander]

>--- Forwarded mail from address@hidden

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

Efficiency is one of the characteristics of an elegant solution.  Solutions
are frequently both elegant and efficient, but rarely elegant and inefficient.

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

I think the NetBSD folks gave up when they figured out that the method
they were using to perform directory renames scaled poorly.  They had
no choice but to use a different workaround to the rename problem that
didn't cause their modules database and repository to explode.

As for the "rarity" of having to review the history of any given file,
that's just bogus.  My users review the history every time they perform
a merge.

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

Okay, let's assume for the moment that all of my source files are ASCII
text.  That includes HTML, XML, RTL, C, C++, Perl, plaintext, and whatnot.
Diff, patch, et al, theoretically all work on these.  The merge problem
arises when more than one datatype (XML and plaintext, for example) are
stored in a single RCS file.

What's happening is that CVS is trying to use a single version history
to describe more than one file.  That's just plain wrong.

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

We're discussing version control specifically, not general SCM solutions.

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

Whatsay we limit this discussion to the handling of directories?

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

"Prescience" is not usually in the job description of the software architect.
They can plan for growth or to phase in new features.  They can try to
anticipate possible future directions.  Their predications are never 100%
accurate, nor should they be expected to be.

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

What's happening is that if a file on one branch is replaced by a new
datatype, and then merged from a second branch, the result is meaningless.
The operation itself has questionable semantics.

In CVS, the only way to avoid this situation is to keep just one datatype
in each RCS file.  I daresay that this goes a step further, which is to
say that the purpose of the content also must not change over the lifetime
of the RCS file.  Because CVS equates paths with RCS files, the only way
to achieve this is to adopt a "one file, one path" policy.  (Well, "one file,
many paths".)  You can never adopt a "one path, many files" policy, which
is what happens when a file is replaced.  (The branch resolves which file
lives at a particular path.)  And the only way to achieve the "one file,
one path" policy is to never reuse a path (i.e. replace a file with a
different one).

>> > > - 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 merge will complete successfully, maybe with conflicts.  The results
are usually gibberish, but might be syntactically meaningful and in any case
require testing.  Maybe that's enough "meaning" for you, but it's way better
if the merge were not even attempted.  Alternatively, the user could be
given both contributors to choose from.  In any case, it's a lot more work
for both user and software to perform a merge whose results you know in
advance will be discarded.

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

Oh, so you set intermediate goals, too.  Good for you.

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

I'm starting a new thread on this one because it's getting too far
away from directory management.

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

We have discussed Brian's recognition of a "rename database" requirement
on this list before.  No change here.

Brian was long gone before the "dead" state was used, so of course our
discussion happened before then.  However, even the "dead" state doesn't
address the rename problem adequately.

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