Date: Sat, 8 Jun 1996 14:19:15 -0400 From: Garrett Wollman <wollman@lcs.mit.edu> To: "Jordan K. Hubbard" <jkh@time.cdrom.com> Cc: Nate Williams <nate@sri.MT.net>, hackers@freebsd.org (FreeBSD Hackers), freebsd-stable@freebsd.org (FreeBSD Stable Users), FreeBSD-current@freebsd.org (FreeBSD current users) Subject: Re: The -stable problem: my view Message-ID: <9606081819.AA02548@halloran-eldar.lcs.mit.edu> In-Reply-To: <16852.834188423@time.cdrom.com> References: <199606071529.JAA29241@rocky.sri.MT.net> <16852.834188423@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
<<On Fri, 07 Jun 1996 16:00:23 -0700, "Jordan K. Hubbard" <jkh@time.cdrom.com> said: > 1. You make a change in -release. > 2. You merge it into -stable. > 3. You make another change in -release. > 4. You go to do another merge into -stable and wind up with a whole *mess* > of conflicts. `cvs update -j' is NOT a decent merge tool! The problem is that you need to carefully specify BOTH merge points. If you are just saying `cvs update -j HEAD foo.c', then yes, of course you are going to lose. This process works: 1. You make a change on the head. It gets rev 1.42. 2. You merge it into the branch with `cvs update -j1.41 -j1.42'. 3. You make another change on the head. It gets rev 1.43. 4. You merge it into the branch with `cvs update -j1.42 -j1.43'. Your conflicts arise because you are not correctly specifying the beginning point of the merge, and so the three-way merge program attempts to re-add the changes between 1.41 and 1.42 in addition to the changes between 1.42 and 1.43, and the conflicts arise because of the unexpected presence of those 1.42 changes in the branch version. If the changes from 1.42 and 1.43 do not themselves overlap, then the merger /ought/ to be able to deal with this (just as it does when you do a `cvs update' and the working file already contains the changes that it wants to apply from the tree). When the changes overlap, then it's impossible for the merger to tell what's going on without some external help (which is what most commercial version-management tools provide). Notice that this implies that attempting to do wholesale merges of branches is a non-starter in CVS. It /has/ to be done incrementally in order to work. Moreover, the model that CVS was really designed for is more like this: 1. You create a branch. 2. You do lots of development work on the branch. 3. You complete the development work on the branch. 4. You merge the entire branch into the head and forget about it. This works also, although it is a bit slower than it might be becaus of the way RCS represents branches. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9606081819.AA02548>