bug-cvs
[Top][All Lists]
Advanced

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

Re: CVS_LOCAL_BRANCH_NUM feature


From: Mark D. Baushke
Subject: Re: CVS_LOCAL_BRANCH_NUM feature
Date: Wed, 05 Mar 2003 08:44:56 -0800

Derek Robert Price <derek@ximbiot.com> writes:

> Mark D. Baushke wrote:
> 
> >There has been some talk in recent months (see the URL: and messages in
> >the thread:
> >http://www.mail-archive.com/freebsd-hackers@freebsd.org/msg38563.html)
> >that it may be desirable to have a command-line switch to control the
> >selection of the magic branch number. This would allow users to put it
> >into their .cvsrc file. I have NOT tried to implement any of those
> >suggestions.
> >
> 
> The more I think about it, the more this seems more appropriate for
> the CVSROOT/config file, as this would most likely be a server-wide
> configuration if anything.  Can you name a good reason to even keep
> the env variable or add a command line switch if this was a
> CVSROOT/config option?

I consider that committing to the mainline CVSROOT/config file in the
sure knowledge that it may be stomped by the master repository seems an
iffy proposition.

CVSup will merge your mainline repository CVSROOT and CVSROOT/config,v
and CVSROOT/config although it may (or may not -- depending on the CVSup
configuration) lose the CVS_LOCAL_BRANCH_NUM value in the checked out
CVSROOT/config file until such time as the CVSROOT has any other commit
to cause the mkmodules() to rebuild the checked out administrative
files.

This kind of collision with the master respository and possible results
of losing the configuration seems less than robust to me.

It is a reason. 

A reason to keep the env variable is that there are many "HOW TO"
documents out there which are not getting updated very often that are
associated with CVSup and getting them all updated will take time. For
now, if folks use the cvs 1.12 sources (from cvs or after release), they
will be able to have a recipe that works properly with CVSup.

It is another reason, but perhaps not as good as the first reason.

        -- Mark




reply via email to

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