Re: BRANCH LABEL FOR DIRECTORIES

[Noel L Yap]

Greg's comments generally fall under the "That's by design" category but it's
not obvious that that design is good.

IMHO, it is not.  Directories are as first class a file system element as files
are.  I've been working lately with a SCM tool that versions directories and
I've found that it makes life much easier (at least with regards to renames and
branching) .  It's true that I could possibly go back to using something without
this capability, but I would much prefer if it were there.

Noel


|--------+----------------------->
|        |                       |
|        |          address@hidden|
|        |          .com         |
|        |                       |
|        |          06/18/01     |
|        |          04:25 AM     |
|        |                       |
|--------+----------------------->
  >----------------------------------------------------------------------------|
  |                                                                            |
  |       To:     address@hidden, address@hidden                     |
  |       cc:     (bcc: Noel L Yap)                                            |
  |       Subject:     Re: BRANCH LABEL FOR DIRECTORIES                        |
  >----------------------------------------------------------------------------|






>--- Forwarded mail from address@hidden

>[ On Sunday, June 17, 2001 at 20:26:34 (-0400), Ralph Mack wrote: ]
>> Subject: Re: BRANCH LABEL FOR DIRECTORIES
>>
>> Well, that depends upon what you mean by "an addition", doesn't it,
>> Greg? If you mean the deletion of the old object with all of its baggage
>> and the creation of a new object _with all of the old object's baggage_,
>> I would tend to agree that the sequence implements the concepts of
>> renaming or moving an object.

>Yes, of course -- a rename is an addition "with all the old object's
baggage".....

And in a version control system, that baggage includes the file's entire
revision history, by definition.

>> In a Unix file system, that baggage consists of a set of permissions,
>> owner and group assignments, and perhaps a couple of things that I
>> forget, but is nonetheless a relatively light bundle.

A file under version control is not a normal Unix file.  A specific
revision of the file could be.  But there's a difference that you choose
to ignore.

>> A file under revision control has a history of revisions (and - one hopes -
>> ancestors and migrations) that describe all the important events of its
>> colorful life. Does moving or renaming a file by deletion and addition
>> retain the file's family history? It sounds to me as if it reduces it to a
>> Unix file with none of these attributes and then recreates it as if it were
>> newborn. All connection to the past is lost.

>In CVS the history stays in place (it must, by design).  It's like the
>unix filesystem in the sense that the data blocks, and indeed the inode
>structure itself, stay in place when you rename the file (though in some
>senses that's a terrible analogy for my purposes since in CVS you do
>actually have to carry more of the baggage yourself! ;-).

And in a version control system, the revision history maps to the data
blocks, and it's up to the system to provide the correct view of whatever
versions the users choose to place in their sandbox.  The version history
changes over time, but no matter how the user links to it, they see the
same thing.  And depending on how the user selects the file, they not
only see a different path to it, they may see different contents as well.
This is a fundamental version control concept.

>> Do you regard this loss as a frivolous concern?

>THERE IS NO LOSS!  In fact if you do the remove and add with appropriate
>commit comments there's actually an information gain -- and anyone
>looking at the revision history of the files (from either direction)
>will be able to follow what has happened with great accuracy.

>> To me the power of source
>> control lies not just in its ability to store all the versions of software
>> but to accurately reflect the historic relationships of those versions.

>CVS will not delete any revision history if you do a rename by way of
>"cvs add" and "cvs rm" -- on the contrary it will add history entries
>which detail this ``change'', provided that you (or your wrapper script
>or front-end client) provide the appropriate change comments for each
>operation.  Time for a concrete CVS example, I think:

>    cp oldfile.c newfile.c
>    cvs rm -f oldfile.c
>    cvs add newfile.c
>    cvs commit -m 'renamed oldfile.c to newfile.c' oldfile.c newfile.c

>Now if you do "cvs log" on either name you'll find it very hard to miss
>what's actually happened.  If the comment is even more detailed the
>reason might even be apparent after the fact too!  ;-)

Okay, now consider this:

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

Guess what:  The old revision history is now hidden from the user.  To
see the revision history of either of either file prior to the rename,
he must figure out what tags (if any) have been applied to the files prior
to the rename, use one of them to check out the module, and bounce back
and forth between the two workspaces to see everything.

>Think of the "cp" and combined "commit" parts of this sequence as the
>baggage carrying bits.  The "cp" copies the current contents, and the
>"commit" leaves pointers to the past and future revisions.
>Hmmm... maybe that analogy with the unix directory tree isn't so bad
>after all.  In Unix you have to "carry" the name (transforming it on the
>way if it stays in the same directory or changes in the new directory),
>while in CVS you have to carry both the name and the current file
>contents.  In both the attributes (in Unix the file blocks and the inode
>structure; and in CVS the revision history) stay in place.

Except that in CVS the revision history does not remain in place; a new
RCS file has been created, and it is modified from that time forward
while the old one is ignored.

>What I find is really most important about the relationships of
>revisions is not how they relate to one another along one "timeline",
>but rather how the different revisions of *different* files relate to
>one another at any given point in time.  CVS does this (best) with tags.

In that case, your requirements are really simpler than most.  You're
using CVS as little more than a collection of tarballs.  Most users of
version control systems need to (sometimes often) merge branches, so
having the complete version history available for that operation is
required.  And such capabilities are expected to work without special
cases if there's an intervening rename.

>Certainly the relationships of the revisions for any one file are
>important across time too, especially if you do branching and merging.
>Obviously in CVS if you do the "Sliders" thing too often with too many
>files then you'll make your branching and merging into a much more
>difficult job.  Each renamed file will have to have all the appropriate
>branches created in it and any merges will require manual handling of
>all renamed files (which can turn into a real nightmare if you move
>all/many of the files in one directory into another).  These limitations
>in the base CVS functionality should encourage users to think very hard
>about renames and indeed the multi-step operation is a good reminder of
>the potential for future difficulties.

Sometimes the users don't have a choice.  Sometimes their tools force
reorgs or retyping files.  Sometimes they maintain code from other sources
(e.g. offsite porting or maintenance organizations).  Simply telling the
users that combining branches and renames is too hard is not acceptable.

>In all my time of tracking various incarnations of *BSD with CVS I've
>only renamed about a half-dozen files.  I often do dread merging them,
>but it's not really that hard to do once I get in the mood to do
>it.... :-)  (I've actually moved whole sets of files to new directories
>too, but also transformed them drastically at the same time -- eg.
>moving gnu/awk to bin/awk and changing it into The One True AWK at the
>same time, and of course then I don't have to do any merging....)

Yeah, you replaced renames with repeatedly re-importing your sources
into clean modules, right?  This is merely a work-around, and a clumsy one
at that.

I worked on the Unix System V (both the definitive and the Solaris variants)
for four years, and in that time I experienced no fewer than two significant
reorganizations in each, all fed from offsite.  The teams I worked with
required the complete version history of every file to be immediately
accessible from their workspaces so that they could use "cvs log" and "cvs
update -j" without thinking about how to find the same file in some other
place that it occupied prior to a reorg.  Not having that capability was a
tremendous hardship.

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


_______________________________________________
Info-cvs mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/info-cvs




This communication is for informational purposes only.  It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan Chase & Co., its
subsidiaries and affiliates.