Date: Wed, 10 Dec 1997 19:26:51 -0500 From: Dave Chapeskie <dchapes@ddm.on.ca> To: hackers@freebsd.org Cc: Jason Evans <jasone@canonware.com> Subject: Re: OS Ports Message-ID: <19971210192651.12352@ddm.on.ca> In-Reply-To: <Pine.LNX.3.95.971210151952.19030I-100000@paladio>; from Jason Evans on Wed, Dec 10, 1997 at 03:30:32PM -0800 References: <Pine.BSF.3.96.971210132013.21564C-100000@acroal.com> <Pine.LNX.3.95.971210151952.19030I-100000@paladio>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971210192651.12352>