Subject: Re: CVS/Root and other CVS items (was Re: anoncvs server available)
To: None <email@example.com>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 01/10/2005 18:11:17
[ On Saturday, January 8, 2005 at 20:45:45 (-0500), Douglas Wade Needham wrote: ]
> Subject: CVS/Root and other CVS items (was Re: anoncvs server available)
> As I pointed out in my previous message, where I mentioned the section
> in cvs.info titled "Multiple repositories", I have added directories
> to my working directories which come from my own repository.
I've never found that to be a very smart practice. I just "cvs add"
things locally to keep track of what's new. This works OK even for
files in new directories, though if one rsync's the whole repo as I do
then you have to somehow prevent rsync from trashing the new empty
directories in the repo (I just have a wrapper script that re-creates
them after the rsync, which means when I add a new directory then I have
to edit the script too. I experimented with different group ownerships
such that rsync couldn't remove them as the user it runs as, but haven't
got it all working smoothly yet).
> This is
> really evident in my pkgsrc tree, where I have well over 40
> directories which reflect new packages I am working on towards
> submitting to pkgsrc (or in some cases, are private packages).
Shouldn't you be using pkgsrc-wip? :-) :-) :-) :-)
If I really want to keep history on changes to locally added files then
I would do it with SCCS/CSSC (just to be different from RCS and to avoid
creating any new *,v files anywhere) right in the working directory.
However I usually don't bother with trying to keep local history of my
local changes, especially since CVS keeps backup files for me during
every merge on update -- they're more than sufficient history for me.
> My doing what you
> suggest would be outright suicide.
Indeed it would, but for this discussion I was specifically trying to
avoid the issue of combining multiple repository sources in the same
> > Note that "cvs -d BLAH update" is _not_ recommended, IIRC. It will not
> > update the CVS/Root files, and as a result it could very easily result
> > in an inconsistent working directory state.
> I have never seen anything stated against this
Well I'm sure it's been discussed on info-cvs before....
> so I would say it is
> probably OK, so long as you have a working directory which deals with a
> single repository and its mirrors.
Well there's still the issue of newly created directories which would
then have the new CVS/Root value.....
> The majority of the time, your
> "inconsistent state" would be no worse than doing a checkout/update while
> someone was doing checkin which was across multiple directories (and
> therefore, non-atomic).
Not true any more, IIUC -- cvs commits lock all directories with
modified files first.
> I have dealt with multiple repositories, and had a default CVSROOT set
> for probably a decade, and never had a problem doing updates, etc. I
> have a script which handles setting it depending on which repository I
> want, so I do not have to worry about typos.
Yeah, but you see most people don't have such a script.
In general nobody should ever set $CVSROOT and everyone should only use
'cvs -d REPO' explicitly on the first checkout, or with commands that
don't need a working directory (such as rtag, as you mentioned).
> Agreed that it would have been nice to have CVS/Root differentiate
> between ssh and rsh (or some other variant). But I know of almost no
> CVS server which uses rsh, as every server I know of uses either ssh
> or pserver.
Hmmm... I thought you'd been using CVS since the early days? I.e. the
days before both pserver and ssh ever existed? :=)
Using rsh on a private/internal network really is very common and really
does have great benefit for efficiency and performance.
This ultra-silly and ignorance driven paranoia about rsh does get in the
way of it being used often enough though.
> There are so many things which could/should have been implemented
> which seem so simple, such as changing the CVS/Root,
Yes, that's a simple one, except for the UI issues....
> doing file moves,
a file move is simply a three-step "cvs rm; cvs add; cvs commit"
Same goes for almost any database "change" operation in any aspect of
Note the atomicity of the "move" is ensured by the simultaneous "commit"
of both add and remove operations (since "add" and "rm" really only
affect the local working directory, bizzare implementation quirks of new
> or even directory moves.
CVS doesn't manage directories. :-)
(directory moves are just moves of the files within them and thus the
same three steps are involved, but one set for each file)
> But lets face it, you can easily do them
> with a few shell commands
Exactly, though as a strong advocate of a front-end such as PCL-CVS, I
would suggest that such scripts are overkill and unnecessary :-)
I just mark the files I want to operate on an PCL-CVS does the rest with
a single command!
Greg A. Woods
H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <email@example.com>
Planix, Inc. <firstname.lastname@example.org> Secrets of the Weird <email@example.com>