Re: BRANCH LABEL FOR DIRECTORIES

[Greg A. Woods]

[ On Tuesday, June 19, 2001 at 08:50:34 (-0400), Ralph Mack wrote: ]
> Subject: Re: BRANCH LABEL FOR DIRECTORIES
>
> >> cp olddir/oldfile.c newdir/newfile.c
> >> cp olddir/oldfile2.c newdir/newfile2.c
> >> cvs rm -f olddir/*
> >> cvs add newdir/newfile.c newdir/newfile2.c
> >> cvs commit -m 'reorganized source to be better'
> >> cvs update -P
> 
> > However I can't let that sit.  What a downright stupid and misleading
> > example.  
> 
> This doesn't seem like a manufactured scenario to me - more like something
> that comes up every so often, although I'll admit it has fewer files than 
> the normal case. It looks like what I would do if you had to move the 
> contents of a directory from one place in the directory tree to another? 

There are two differences between Paul's example and the one I gave.
One of those differences is irrelevant to this issue, and the other is
critical.  The irrelevant difference is the use of two files moving from
one sub-directory to another (and the implication that maybe the
directory is also being renamed, though that's not necessarily what's
happening).  The critical difference though is the meaningless and
useless commit and perhaps misleading comment in Paul's example.
 
> How would you do it, Greg? 

I gave a more meaningful and "future useful" commit comment in my
example.

Paul's example is probably less useful and more misleading than if it
were simply left empty.  At least an empty comment can be more easily
flagged for correction!  ;-)

A "future useful" commit comment is something that's critical for every
commit in every revision control system, not just one that removes or
adds one or more files, of course.  It's very important for the
committer to always ask themselves the question "Does my explanation
clearly and completely describe this change to some future maintainer
who is trying to understand it and its intent?"

Paul's message might be sufficient in the form of an e-mail message that
includes all the file names and all the actions (such as one that might
be produced by the "log_accum" loginfo script).  However to anyone in
the future examining any of the revision histories of any of those
individual files, it will not only be incomplete, but it might even be
misleading.

The only thing special about commit messages for renamed/moved file(s)
in CVS is that they have to be somewhat redundantly worded if they're to
be used identically for both the removed and the added file(s).  However
I don't think they're very hard to devise for anyone willing to take a
moment to think about what they're writing.

CVS is not a replacement for good inter-developer communications, though
sometimes it is the vehicle.

> It isn't enough to say that you simply wouldn't let this happen to you.
> Migrations, even mass migrations, are a fact of life; demands of logistics
> often place their prevention beyond our control; since they cannot be 
> prevented, they need to be supported without damaging continuity.

Once burned, twice shy?  Certainly learning from one's mistakes is
painful.  Luckily in this case the commit messages can be changed after
the fact, at least so long as it is caught before the committer
disappears or forgets what he or she did.

> I don't see CVS as a niche product at all. CVS is as mainstream as Linux
> or Java.

It really doesn't matter how widely used CVS is -- it's popularity is
simply an indication of how commonly people do the things it can do (and
perhaps how commonly people try to use it to do things it cannot do well).

CVS is a niche product because it offers only those specific features
necessary for tracking the change history of source code (including the
source text that might be used to produce documentation), and because it
helps solve a couple of common problems often encountered by users of
more traditional source control systems such as RCS or SCCS.  CVS is a
niche product because it explicitly, by design, does not attempt to
provide a generic change control system that can be used in _all_
scenarios where it is useful to track changes to files stored on a
computer system.  CVS is a niche product because it does not need a
large market share in order to survive (it could survive quite well if
only one person used it).

> Most of what most people need is easy to learn and use, with 
> the exception of branches and merges. Set up is kind of fragmentary, as
> for many Linux services, but it seems to have all the right hooks in all 
> the right places for integration into corporate build mechanisms. Its
> support for Windows clients is adequate. As companies become more 
> accustomed to shareware, I could see it become the preferred version 
> control system for corporate Unix/Linux. If the Windows version could 
> register out of the box as a Win2000 service, I could see it becoming 
> popular for Windows shops, too.

Lots of people would no doubt disagree with at least your claim that CVS
has "all the right hooks in all the right places".  Indeed there's
another thread going on right now about the relative usefulness of the
'taginfo' hook....

> Its biggest drawback as a mainstream product is that branching and 
> merging require you to know a lot more than with other products and
> require certain voluntary behaviors that aren't immediately obvious,
> like tagging on both branches when doing merges.

All of those drawbacks can be "solved" externally to CVS itself, either
by documentation or by driver scripts and/or front-end enhancements that
compile higher-level requests into the basic CVS actions necessary.

Indeed there are already add-ons to CVS that help give it higher level
functionality without compromising the integrity of the basic repository.

> A few enhancements, 
> like tracking moves, renames, and merges will permit reasonable default 
> behavior in most situations for those developers who do not have a 
> passionate interest in revision control.

Tracking of merges, if you mean what I think you mean, is an entirely
separate issue from the basic difficulties of initiating and using
branches.  Tracking of merges is really only necessary for certain
specific "patterns" of branch and merge usage.

Note that "moves" and "renames" are really the same thing.

-- 
                                                        Greg A. Woods

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