Re: renaming a directory in the checkout / recursive add and commit for all subdirs

[Paul Sander]

>--- Forwarded mail from Greg Woods:

>[ On Wednesday, September 19, 2001 at 19:30:19 (-0700), Paul Sander wrote: ]
>> Subject: Re: renaming a directory in the checkout / recursive add and commit 
>> for all subdirs
>>
>> 'Course, this procedure makes it harder to gather the entire
>> version history of any file together into one place (you need to
>> check out a new sandbox for every reorg to see it all)

>No, you don't have to check out a new sandbox.  All the commit comment
>logs and previous revision deltas, old releases, etc. are all
>immediately and completely accessible, even without ANY working directory.

I ran a little experiment, the transcript I've included at the bottom of
this message.  The gist is that Greg's claim technically is true, but
not if CVS best practices are followed.  The hiccup is that in order to
see the complete version history, you can't prune empty directories in
your workspace.  Best practices include adding the -P option to your .cvsrc
file for checkout and update, which always prunes.

>>, and
>> it's harder to merge between branches if the contributor branch
>> didn't have this procedure done at the same time as the destination
>> branch.

>Huh?  Never been a problem for me (and yes, I've done it multiple
>times).  I suppose if someone tried to do a merge without knowing what
>had happened they might be in for a bit of a surprise, but provided the
>commit comments are meaningful enough they should be able to figure out
>what to do quickly enough.

This assumes a couple of things:  First, that the commit comments are
"meaningful enough", which is rarely the case.  Second, to perform a
merge across directories like this, it's necessary to either do the
work by hand or create and apply context diffs, and we assume that
developers are willing and able to do this.  In my experience,
developers prefer not to do the merge by hand, and they don't know
about the patch(1) program which makes applying context diffs harder.

>> Another way to handle some of these cases is replicate the RCS
>> files in the repository (and delete version tags), but that method
>> has its own problems.

>Yup.  The problems are almost as serious, and potentially even more
>serious if you've got other potential clashes with other "dead" files in
>the destination directory.  Never replicate files in the repo and never
>make any links (hard or symlinks) in the repo!

My experience has been that replicating the RCS files causes fewer
problems than the remove/add method.  If your developers expect the
revision history to be complete after the rename without having to
search through the workspace, and you're careful about managing your
tags, it is a viable method.  But your mileage may vary.

>> Still another way is to write a new module and hack in the new
>> location of the renamed directories.  That solves the problems
>> of both methods above, but adds its own set.  For example, all
>> users of the new module must perform a fresh checkout, plus you
>> must track multiple modules for a single product.

>Yes, that works well enough in a few cases, but generally it simply
>migrates the problem to a place where CVS has no good support tracking
>release relationships (i.e. to the modules file).

>It also relies on complex features of the `modules' feature which may
>not be stable and which are known not to behave identically on
>client-server and local checkouts.

Actually, the behavior of the modules database is defined well enough
for it to work if you stick strictly to the documentation and don't
try to be tricky.  Alias modules and ampersand inclusion are sufficient
and work reasonably well.

But, as Greg suggests, you must track changes to the modules using a
method other than tags.  That means using ad-hoc naming conventions
within the modules database.  It's a pain, but it works in some cases.
Again, your mileage may vary.

I've used all three methods, and each has its strengths and drawbacks.
Use the one that gives you the fewest problems.

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



Here's the transcript of my experiment:


# Check out a module that contains just the directories "a" and "a/b"
bugs(paul:.cshrc):testhome% cvs checkout a
cvs checkout: Updating a
cvs checkout: Updating a/b

# Populate the a/b directory
bugs(paul:.cshrc):testhome% cd a/b
/usr2/paul/cvshome/cvs/src/testhome/a/b
bugs(paul:.cshrc):b% echo "This is the initial version of a.c" > a.c
bugs(paul:.cshrc):b% cvs add a.c
cvs add: scheduling file `a.c' for addition
cvs add: use 'cvs commit' to add this file permanently
bugs(paul:.cshrc):b% cvs commit -m "I WANT TO SEE THIS MESSAGE" a.c
RCS file: /usr2/paul/cvshome/cvs/src/testroot/a/b/a.c,v
done
Checking in a.c;
/usr2/paul/cvshome/cvs/src/testroot/a/b/a.c,v  <--  a.c
initial revision: 1.1
done

# Apply a tag to all files in the module
bugs(paul:.cshrc):b% cvs tag REL1 a.c
T a.c

# Rename of a/b to a/c
# Begin by creating a/c
bugs(paul:.cshrc):b% cd ..
/usr2/paul/cvshome/cvs/src/testhome/a
bugs(paul:.cshrc):a% mkdir c
bugs(paul:.cshrc):a% cvs add c
Directory /usr2/paul/cvshome/cvs/src/testroot/a/c added to the repository

# Move a/b/a.c to a/c/a.c, according to best practices
# That is mv the file, "cvs rm" from the old location and "cvs add" in the new
bugs(paul:.cshrc):a% cd b
/usr2/paul/cvshome/cvs/src/testhome/a/b
bugs(paul:.cshrc):b% mv a.c ../c
bugs(paul:.cshrc):b% cvs remove a.c
cvs remove: scheduling `a.c' for removal
cvs remove: use 'cvs commit' to remove this file permanently
bugs(paul:.cshrc):b% cvs commit -m "Moved a/b/a.c to a/c/a.c" a.c
Removing a.c;
/usr2/paul/cvshome/cvs/src/testroot/a/b/a.c,v  <--  a.c
new revision: delete; previous revision: 1.1
done
bugs(paul:.cshrc):b% cd ../c
/usr2/paul/cvshome/cvs/src/testhome/a/c
bugs(paul:.cshrc):c% cvs add a.c
cvs add: scheduling file `a.c' for addition
cvs add: use 'cvs commit' to add this file permanently
bugs(paul:.cshrc):c% cvs commit -m "Moved a/b/a.c to a/c/a.c" a.c
RCS file: /usr2/paul/cvshome/cvs/src/testroot/a/c/a.c,v
done
Checking in a.c;
/usr2/paul/cvshome/cvs/src/testroot/a/c/a.c,v  <--  a.c
initial revision: 1.1
done

# Apply a tag for good measure
bugs(paul:.cshrc):c% cvs tag REL2 a.c
T a.c

# Update and prune the workspace, making sure that the result really is
# a rename of a/b to a/c, according to best practices
bugs(paul:.cshrc):c% cd ..
/usr2/paul/cvshome/cvs/src/testhome/a
bugs(paul:.cshrc):a% cvs update -P
cvs update: Updating .
cvs update: Updating b
cvs update: Updating c
bugs(paul:.cshrc):a% ls
./   ../  CVS/ c/

# Now seek out version history dating back from before the rename
# I want to see "I WANT TO SEE THIS MESSAGE" recorded in a/b/a.c's
# version history.
bugs(paul:.cshrc):a% cvs log
cvs log: Logging .
cvs log: Logging c

RCS file: /usr2/paul/cvshome/cvs/src/testroot/a/c/a.c,v
Working file: c/a.c
head: 1.1
branch:
locks: strict
access list:
symbolic names:
        REL2: 1.1
keyword substitution: kv
total revisions: 1;     selected revisions: 1
description:
----------------------------
revision 1.1
date: 2001/09/21 04:29:38;  author: paul;  state: Exp;
Moved a/b/a.c to a/c/a.c
=============================================================================

# But now if best practices are violated and we update and leave empty
# directories, the history appears.
bugs(paul:.cshrc):a% cvs update -d
cvs update: Updating .
cvs update: Updating b
cvs update: Updating c
bugs(paul:.cshrc):a% cvs log
cvs log: Logging .
cvs log: Logging b

RCS file: /usr2/paul/cvshome/cvs/src/testroot/a/b/Attic/a.c,v
Working file: b/a.c
head: 1.2
branch:
locks: strict
access list:
symbolic names:
        REL1: 1.1
keyword substitution: kv
total revisions: 2;     selected revisions: 2
description:
----------------------------
revision 1.2
date: 2001/09/21 04:29:13;  author: paul;  state: dead;  lines: +0 -0
Moved a/b/a.c to a/c/a.c
----------------------------
revision 1.1
date: 2001/09/21 04:27:27;  author: paul;  state: Exp;
I WANT TO SEE THIS MESSAGE
=============================================================================
cvs log: Logging c

RCS file: /usr2/paul/cvshome/cvs/src/testroot/a/c/a.c,v
Working file: c/a.c
head: 1.1
branch:
locks: strict
access list:
symbolic names:
        REL2: 1.1
keyword substitution: kv
total revisions: 1;     selected revisions: 1
description:
----------------------------
revision 1.1
date: 2001/09/21 04:29:38;  author: paul;  state: Exp;
Moved a/b/a.c to a/c/a.c
=============================================================================