Re: CVS_LOCAL_BRANCH_NUM feature

[Mark D. Baushke]

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

> Ah.  That's a good point.  I hadn't considered multiple repository
> mirrors being used by the same user yet.  Via pserver access and inetd
> or xinetd, a user could configure different ports per repository and
> thus change the CVS_LOCAL_BRANCH_NUM content.

In practise, most folks have their own 'business' CVS repository and a
CVSup mirror of the repository that provides their operating system
(like FreeBSD or NetBSD or OpenBSD). The only time that anyone needs to
worry about the CVS_LOCAL_BRANCH_NUM is when there is a need to create a
tag or commit a local change to a mirror repository. In all other cases,
users would not want to have that environment variable set.

Of course, open source developers may have cvs trees checked out from a
number of places like cvshome.org, sourceforge.net in addition to any
repository mirrors or normal repositories that they have on their own
machines.

> Perhaps it is better to leave local mode to a script which could be
> distributed in contrib or with CVSup which would change the env var
> dependant on the CVSROOT.

If I understand you, then yes, the number of people that typically need
to make use of the CVS_LOCAL_BRANCH_NUM should be fairly small and doing
it in an ad hoc fashion seems to be 'good enough' for most folks or
there would probably have been more pressure for a command-line switch
to be added to the FreeBSD or NetBSD or OpenBSD versions of cvs...
 
> Even better, back to the CVSROOT/config option, can CVSup be
> configured to ignore updates to a single file, such as CVSROOT/config
> in order to allow mirrors to maintain their own configuration?  This
> might be the most sensible approach and just might be doable now (with
> the addition of the CVSROOT/config option to CVS).

CVSup is very flexible. However, in this case I have seen that the more
flexibility you use, the easier it is to add pain to your life. In this
case, users would need to make sure that they avoided adding CVSROOT to
the list of modules that gets updated...

For more information on CVSup and how it relates local changes in a CVS
Repository there is a FAQ...

| Local Modifications in your CVS Repository

|  41. Can I check my own local changes into a CVS repository that I
|      update with CVSup from a master site?

See http://www.cvsup.org/faq.html#canilocal

|
|  42. How can I keep CVSup from deleting the revisions I have checked in
|      locally?

See http://www.cvsup.org/faq.html#nodelete

|
|  43. How can I keep the revision numbers of my local check-ins from
|      conflicting with revision numbers originating at the master site?

See http://www.cvsup.org/faq.html#revconflicts

Even more amusing are the folks that have a local mirror of a repository
and commit rights to the master. They may checkout their tree using a
local path like

  cvs -d /cvs/freebsd checkout src

and then commit using something like this:

  cvs update -T                 # cvs FreeBSD command option for CVS/Template
  cvs -d :ext:MASTER_CVS.freebsd.org/cvs commit foo.c

so, even when they may have a 'local' version of the repository, there
are times when they do a commit to the master repository... 

        Enjoy!
        -- Mark