info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Greg A. Woods
Subject: Re: renaming a directory in the checkout / recursive add and commit for all subdirs
Date: Fri, 21 Sep 2001 02:59:43 -0400 (EDT)

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

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

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

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

-- 
                                                        Greg A. Woods

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]