version=3.0.0
Sender: current-users-owner@NetBSD.org

Quoting Greg A. Woods (woods@weird.com):
> [ On Friday, January 7, 2005 at 23:36:42 (-0800), Wolfgang S. Rupprecht wrote: ]
> > Subject: Re: anoncvs server available
> >
> > One embellishment you might want to do is to create hard links and
> > have only to one real CVS/Root file.
> 
> I wouldn't do that -- though I'm not sure why not....  Perhaps just
> because I've had my head stuck in the CVS code often enough over the
> years to be afraid it'll break.  :-)

I would have to agree that such a move would make me nervous, at least
within a single working directory, and I have been using CVS for
forever.  I know I have seen some odd results after
creating a backup working directory with files hardlinked between
them, but the oddness was in the backup copy, and I never took the
time to look at it in detail.
 
> I wouldn't worry about not touching CVS/Root files which don't seem to
> have the right content either.  In theory all files in a given module
> should always be checked out from the same server, and if any CVS/Root
> files are not right then they should be fixed, so the brute-force update
> is best:
> 
> 	find . -type f -print | fgrep CVS/Root | while read rfile; do
> 		echo ":ext:anoncvs@anoncvs.NetBSD.org:/cvsroot" > $rfile
> 	done

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.  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).  At
least 38 of these are under pkgsrc/www for stuff relating to
Zope/Plone.  I have even manipulated the CVS/Entries file so that it
recurses into the directories automatically.  My doing what you
suggest would be outright suicide.  Of course, I am not your typical
CVS user either, having used it heavily since it was originally posted to
USENET.

> 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, 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.  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).  Would I do it?  No, not given the fact that I
have a script which updates the entire pkgsrc tree in about 30 seconds.

> I would also recommend quite strongly _against_ ever setting $CVSROOT in
> your environment (unless you have a local repository that you would
> normally always want to use).  The primary reason why CVS stores the
> repository information in the CVS/Root files is so that it will always
> do the right thing by default (i.e. without '-d' or $CVSROOT) for any
> existing working directory.  I.e. so long as you don't try to mess with
> it manually then it will always do the right thing.  Normally of course
> the $CVSROOT value is ignored and the content of the CVS/Root files is
> preferred, but as per the manual:
> 
>      Once you have checked out a working directory, CVS stores the
>      appropriate root (in the file `CVS/Root'), so normally you only
>      need to worry about this when initially checking out a working
>      directory.

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.  The worst I have had is
two different repositories with identical module names, where I got
the wrong one during a checkout. 8) Of course, in that case, I just
remove the working directory and start over.  There are commands such
as rtag which would be even worse, but with them, I am already
paranoid and double check things if I am working in a different
repository.

> (The only tricky part is that CVS_RSH has to be set right each time if
> you ever use any combination of "rsh" and "ssh" -- e.g. the former for
> efficiency and better performance on an internal/private network.  I do
> wish its value had been included in the CVS/Root files too!  The whole
> idea of using environment variables with CVS should have been abolished
> once CVS grew its network client/server ability.)

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.

> Ideally of course there should have been (or be) some way to do the
> equivalent of the above little shell loop directly with the "cvs"
> program, but sadly no such feature has been implemented yet, even though
> it's an FAQ on the info-cvs list.

There are so many things which could/should have been implemented
which seem so simple, such as changing the CVS/Root, doing file moves,
or even directory moves.  But lets face it, you can easily do them
with a few shell commands, and if you are tired of typing the shell
loop, you can always add it to a shell script file (say as a
function), and reuse it when needed.  I tend to do this for anything
which is complex, or which I do more than 2-3 times.  I have a number
of functions for cvs in a file named cvs.fcns which I pull into my
environment every time I login.  The result?  To change my CVS/Root
files for pkgsrc, I mearly did the following:

      cd /source/usr/pkgsrc
      get_cvs_root
      set_cvs_root netbsd-fr
      change_cvs_root
      cvs_update

For the curious, get_cvs_root will update my CVSROOT variable from the
file ./CVS/Root, while set_cvs_root will save the old CVSROOT value
and set it to a new value (this is a growing switch/case structure).
Then the change_cvs_root verifies that OLD_CVSROOT and CVSROOT are
set, then proceeds to do the loop I gave yesterday.  No worries about
it clobbering the CVS/Root files for areas coming from my
repository. 8)  Finally, cvs_update does the update itself, defaulting
to the previous midnight, and creates a file which helps me know when
I last did an update.  It will eventually even go so far as to catch
the output and tell me at the end how many conflicts or other problems
I encountered.

Oh, are there things I would like to see in CVS.  Yes! I would rather
see them improve the multiple repository stuff, rather than waste time
on stuff that we can easily do with shell commands (and may also want
done differently).  I think it would be really nice to have the
ability to create something like a union mount, but for CVS
repositories.  That way, I could do commands which would allow me to
do tags on a repository such as the NetBSD one we have all been
talking about, but to store the tags in the local repository.  And
extending that, I could also create branch in which I could then make
changes, additions, etc.  So if I were then working on some neat
feature, adding a package, etc., I do not need to worry about
constantly importing updates from the NetBSD repository into my
personal repository, then merging those with my work.  Impossible?
Not really from what I can see.  Remember how CVS uses versions
strings like 1.17.0.2?  How about a version such as 1.17.ka8zrt.1??
Effectively, the same, but with a little added code, would not collide
with the main repository branches.  I would have probably written this
by now, but am not knowledgeable enough with the client/server
protocol, and have items which are much higher priorities.

- Doug    

-- 
Douglas Wade Needham - KA8ZRT        UN*X Consultant & UW/BSD kernel programmer
Email:  cinnion @ ka8zrt . com       http://cinnion.ka8zrt.com
Disclaimer: My opinions are my own.  Since I don't want them, why
            should my employer, or anybody else for that matter!