Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 18 Apr 1997 23:58:08 +0200 (MET DST)
From:      Eivind Eklund <eivind@nic.follonett.no>
To:        terry@lambert.org (Terry Lambert)
Cc:        hackers@freebsd.org
Subject:   Re: Accomodating Terry
Message-ID:  <199704182158.XAA15898@nic.follonett.no>
In-Reply-To: <199704182053.NAA02753@phaeton.artisoft.com> from Terry Lambert at "Apr 18, 97 01:53:44 pm"

next in thread | previous in thread | raw e-mail | index | archive | help
> If (A) or (B) could be accomodated with a seperate branch, a seperate
> branch would be sufficient.  I question the difficulty of "going
> mainstream" with a part of the code in such a branch (it seems that
> you would end up with unacceptable all/none choices), or of it being
> able to "keep up" with mainstream developement:
> 
>         mainstream -------> branch
>             |                 |
>             |                 v
>             |               branch
>             |                 +
>             |           local changes
>             |                  
>             |                  
>         mainstream -------> branch           <<< How can this happen
>             +                 +                  without a code slave?
>          changes        local changes
>                               +
>                            changes
> 
> If this is an imagined hurdle, it'd be nice to know.

It might be.  You don't have to tag the entire tree, you can tag just
the files you are working on.  This will allow you to have a 'partial
branch', while keeping nicely current on the rest of the tree.
You will have to merge the changes done to the parts of the tree you
are working on; however, this is usually fairly simple.

If you are doing several set of unrelated changes, you can probably
also get your own branch for each of these.

If core is unwilling to give you commit-access even if you guarantee
to stay in your own branch, a way of hacking some of the wanted
features is by treatingthe FreeBSD main development as a vendor
branch, and using cvs import to maintain the parts you don't change.

This will require an upgrade of your CVS to 1.9 (which I don't know
why isn't in the FreeBSD tree already; I've just never gotten around
to asking).  With CVS 1.8, it will try to import into the FreeBSD
repository.

If you have a good idea for how it would be possible to handle this
situation (without thinking of what CVS can handle today), we can of
course contact the cvs-info mailing-list and see if somebody there
might benefit from similar features and can be convinced to write
them :)

Eivind / eivind@freebsd.org / perhaps@yes.no
http://maybe.yes.no/perhaps/



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704182158.XAA15898>