From owner-freebsd-hackers Wed Dec 10 17:00:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA12527 for hackers-outgoing; Wed, 10 Dec 1997 17:00:47 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from golden.net (golden.net [199.166.210.183]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA12336 for ; Wed, 10 Dec 1997 16:59:10 -0800 (PST) (envelope-from dchapes@ddm.on.ca) Received: from ymris.ddm.on.ca (cisco1-38.cas.golden.net [207.6.168.38]) by golden.net (8.8.5/8.6.12) with ESMTP id TAA20048 for ; Wed, 10 Dec 1997 19:27:47 -0500 (EST) Received: from squigy.ddm.on.ca (squigy.ddm.on.ca [209.47.139.138]) by ymris.ddm.on.ca (8.8.7/8.8.8) with ESMTP id TAA01788; Wed, 10 Dec 1997 19:26:53 -0500 (EST) (envelope-from dchapes@ymris.ddm.on.ca) Received: (from dchapes@localhost) by squigy.ddm.on.ca (8.8.7/8.8.7) id TAA07700; Wed, 10 Dec 1997 19:26:52 -0500 (EST) Message-ID: <19971210192651.12352@ddm.on.ca> Date: Wed, 10 Dec 1997 19:26:51 -0500 From: Dave Chapeskie To: hackers@freebsd.org Cc: Jason Evans Subject: Re: OS Ports References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 In-Reply-To: ; from Jason Evans on Wed, Dec 10, 1997 at 03:30:32PM -0800 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, Dec 10, 1997 at 03:30:32PM -0800, Jason Evans wrote: > Say I grab current, and stay synched with it, but I start making changes > to my local tree. As time goes on, I make more and more changes, while my > tree still tracks current. At some point, aren't my changes going to > cause conflicts that make it a losing battle to keep my own tree? Say in > file foo.c George changes lines 10-20 in the main tree, and I change lines > 15-20. When I sync my tree with freebsd.org, there will be a conflict. If > I manually resolve this conflict, will I have to deal with it repeatedly > every time I sync with the main tree? > > Even if I only have to resolve the conflict once, tracking current can't > be automatic, can it? It seems to me that I'd have to manually resolve > conflicts. You would only resolve the conflict once (by merging the change with yours). Conflicts like the one you mention aren't too bad. CVS does a good job of marking these out so that they are easy to find and resolve. The real nasty will be logical conflicts (ie you add a call to function foo then someone changes the syntax of calls to foo. Since the changes don't overlap in the files CVS will not catch this) > Jason > > P.S. Please excuse what is likely incorrect terminology for tree > synchronization and conflict resolution. What are the proper terms? Merging and conflict resolution. > Jason Evans > Email: [jasone@canonware.com] > Home phone: [(650) 856-8204] > Quote: ["Invention is 1% inspiration, 99% perspiration" - Thomas Edison] One thing you have to watch for is that CVSup will overwrite revisions with the same number (last I saw). For example if foo.c is at revision 1.42 and you commit 1.43 to your local tree. When 1.43 is committed to the real tree, CVSup will blow away your change. The same thing applies to tag names. Although this may not directly help you here is what I've done in the past. I create a branch from a release point (ie RELENG_2_2_RELEASE) and put all changes in there. Then when I want to sync up with a new release I do a CVS merge. For example, if I called my local branch LOCAL_2_2 then I'd merge the changes from revision RELENG_2_2_RELEASE to revision LOCAL_2_2 and apply this to a new branch from RELENG_2_5_RELEASE called LOCAL_2_5 (via a single CVS command). This works well for the kind of changes I make since it limits how often I need to fix conflicts and because I need to run stable. (Note with local branches it's still possibly to get your changes overwritten if someone else makes a branch on the real tree at the same point. One way to avoid this is to modify your local CVS to be able to use a branch number other than 0). Following current would seem to be a little more problematic unless you only periodicly do cvs merges. Perhaps you can do something with the vendor branch stuff. You'll have to find a good solution from a CVS guru. -- Dave Chapeskie, DDM Consulting E-Mail: dchapes@ddm.on.ca