Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 4 May 1997 11:20:07 -0700 (MST)
From:      Terry Lambert <terry@lambert.org>
To:        joerg_wunsch@uriah.heep.sax.de
Cc:        current@FreeBSD.ORG, joes@spiritone.com
Subject:   Re: Help with merging in local changes with CVS etc...
Message-ID:  <199705041820.LAA14228@phaeton.artisoft.com>
In-Reply-To: <19970504174407.EZ62108@uriah.heep.sax.de> from "J Wunsch" at May 4, 97 05:44:07 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> > I know I will need to maintain a copy of the full CVS repository, but
> > how do I ensure that the change will remain in effect after further
> > changes (pulled in with CVSup)?
> 
> Are you sure you really want to check it into your CVS?  I think the
> cvsup documentation in the handbook mentions how this would to be
> done, though i'm not familiar with it either.

It involves a FreeBSD committer providing a branch tag for local
use by the committer -- one tag per thread of changes.

It don't provide a mechansim for coelescing the tag head when you
finally accept the changes for commit.

It doesn't provide a history merge mechanism (which would rely on
the coelese) so that if a change that impacted the post-merge code
needed to be backed out (say a VM change or dimilar dependency),
then the post-backout would no longer function.

> If you just apply the modifications to your tree, subsequent `cvs
> update' operations will try its best to maintain your local changes
> to the checked out tree.

It won't always be successful, so you should be prepared to resolve
conflicts manually.  Because of this, you must manually do the
updates, and resolve before subsequent updates.  This means that
it's impossible to automate the process.

It also mens that you can't locally maintain history for your code
in your local tree (ideally, you would track colliding changes so
that you could back the colliding tree out to whatever revision you
wanted, and your merged code would still function; no dice with the
suggested method).


> I think i've got some 20+ files in my kernel source tree that
> differ from the official versions, and a few files outside the kernel.
> I sometimes commit the changes once they `matured' (see the syslogd
> commit yesterday), sometimes i don't commit them since they are
> unclean and need more work, some of the changes are purely local
> (e.g. i've totally ripped off rm'ing the old compile directory from
> config(8) since bothered me once too many).

You are in a different boat.  You can commit changes to the main tree
and get them communicated to your local copy of the tree that way.  It
won't work for people who don't have commit priveledges to the main
tree, only to their copy of the main tree.


CVS is barely adequate.  8-(.


					Regards,
					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.



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