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

[Paul Sander]

>--- Forwarded mail from Greg Woods:

>[ On Thursday, September 20, 2001 at 22:00:31 (-0700), Paul Sander wrote: ]
>> Subject: Re: renaming a directory in the checkout / recursive add and commit 
>> for all subdirs
>>
>> >--- Forwarded mail from Greg Woods:
>> > 
>> > 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.

>Paul:  YOU DO NOT EVEN NEED ANY WORKING DIRECTORY TO SEE ALL HISTORY!!!!

>You certainly don't have to avoid any "cvs best practices" either.

See the transcript below.  Your turn to provide transcripts showing how
you manage this without a sandbox.

>> This assumes a couple of things:  First, that the commit comments are
>> "meaningful enough", which is rarely the case.

>The procedure is documented clearly in the manual.  If people don't read
>the manual and learn how to do this, as well as follow any additional
>local procedures properly, etc., then they probably shouldn't be working
>on the project in the first place as they are probably incompetent.  If
>you only have incompetents to work with then it's not too hard to
>concoct a wrapper script to implement a packaged "cvsrename" feature
>that does everything for them (though of course if you're paranoid
>you'll never trust them to use it so you might just as well do
>everything yourself!).  Furthermore if it's a multi-person project then
>you will have peer review and peer pressure, and if that doesn't work
>then nothing will and your project is probably doomed anyway.

Only about 10% of the developers I know have ever opened the manual to
their version control tool.  They rely instead on quick reference cards
and get by with the minimum effort.

And peer reviews don't usually include commit comments at the moment
they're written.  They're either done before the commit if the policy
is to commit only good code, or they're done after the commit when it's
too late to edit the comments.

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

>You must live in some weird space warp Paul.  Most programmers I know,
>and myself included, have been doing all of that without complaint for
>decades now.  If it takes a swat with a clue-by-4 to get someone to do
>manual merges where necessary then you might want to think twice about
>having them on your team in the first place.  People who don't know
>about 'patch' probably don't know about 'diff' either and obviously have
>not read the CVS manual (which mentions the 'patch' program and its uses
>explicitly in several places), probably shouldn't be allowed to use cvs,
>and certainly shouldn't be maintaining code where any merges are
>necessary, manual or otherwise!!!!

I think you're the one living elsewhere.  In my world, merges are avoided
like the plague, the developers preferring to minimize the number of
large merges performed.  CVS makes merging easier when sharing a branch,
but the old habits when working on isolated branches remain.

And every developer I know uses diff regularly.  But they're familiar
only with the standard Unix tools and plus the ones in their personal
toolkits.  They really are unaware of patch until I tell them about it.

And no, they don't read the CVS manual because either a) they don't use
Emacs, or b) they're not interested in learning all of the nuances of
CVS (preferring instead to learn the minimum to get by).

None of this means they're poor software engineers; it just means that
they're more interested in solving their problems, not jumping through
hoops with the uninteresting version control system.

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

>hint:  try "cvs log a/b/a.c"  You will be able to discover the correct
>pathname to use courtesy the (re)birth comment you were supposed to have
>written in the first revision of the added file, i.e. the file who's
>pathname you do know.

Tried that.  Didn't work without having a/b in the workspace.  That
meant having to do an "update -d" to get it.  It's all in the transcript
of my prior message.

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

# Let's see what's here.  This is post-rename, and pruned (according to
# best practice).
bugs(paul:.cshrc):a% ls
./   ../  CVS/ c/

# Display the history of everything available
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
=============================================================================

# Only the post-rename history is shown.  But it shows the path of the
# original file.  I'll try getting the log of that.
bugs(paul:.cshrc):a% cvs log b/a.c
cvs [log aborted]: no such directory `b'

# It didn't work.  Now pick up the old directory, which is empty.  Because
# I'm not pruning, this is not a best practice.
bugs(paul:.cshrc):a% cvs update -d
cvs update: Updating .
cvs update: Updating b
cvs update: Updating c

# The directory's there now, try getting the pre-rename history.
# This time, it works.
bugs(paul:.cshrc):a% cvs log b/a.c

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

# Done.