[Dri-devel] CVS merge problem solved + suggestion for cvs policy
Hi all, I'm happy to report that I found a solution to the merge problems Eric and I were seeing. I believe the problem had to do with vendor branches. They are created automatically when sources are imported using cvs import. Many files from XFree86 had a vendor branch (e.g. revisions 1.1.1.x) with several revisions, each corresponding to a cvs import. The config-0-0-1-branch and savage_1-0-0_branch were forked off such vendor branches of these files. However, the last merge from XFree86 was done using cvs commit instead of cvs import. Therefore the new head revision of the XFree86 files was e.g. 1.2. Now a normal cvs update -d -j HEAD would determine 1.1 as common ancestor revision of the branch and the current trunk while the real ancestor revision is 1.1.1.x (on a vendor branch). The solution is to explicitly specify the ancestor revision as the branch point. This is the command line I used for that purpose: cvs -z3 update -d -j config-0-0-1-branch:2003-05-25 -j HEAD where 2003-05-25 is the day before the first commit on the config-0-0-1-branch. Note that -kk is not necessary. In fact it produces unnecessary conflicts instead of preventing them. I suggest an update of the cvs policy in order to avoid such problems in the future. The above operation would have been easier with a tag marking the branch point. Thus creating a branch should consist of two steps: cvs tag --fork cvs tag -b --branch Then a merge from trunk would be done with: cvs -update -d -j --fork -j HEAD If I get positive feedback on this I would update the wiki page myself. Best regards, Felix __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] CVS merge problem solved + suggestion for cvs policy
On Tue, Oct 07, 2003 at 12:33:49PM +0200, Felix Kühling wrote: > Hi all, > > I'm happy to report that I found a solution to the merge problems Eric > and I were seeing. I believe the problem had to do with vendor branches. > They are created automatically when sources are imported using cvs > import. Many files from XFree86 had a vendor branch (e.g. revisions > 1.1.1.x) with several revisions, each corresponding to a cvs import. The > config-0-0-1-branch and savage_1-0-0_branch were forked off such vendor > branches of these files. > > However, the last merge from XFree86 was done using cvs commit instead > of cvs import. Therefore the new head revision of the XFree86 files was > e.g. 1.2. Now a normal cvs update -d -j HEAD would determine 1.1 as > common ancestor revision of the branch and the current trunk while the > real ancestor revision is 1.1.1.x (on a vendor branch). The solution is > to explicitly specify the ancestor revision as the branch point. This is > the command line I used for that purpose: > > cvs -z3 update -d -j config-0-0-1-branch:2003-05-25 -j HEAD > > where 2003-05-25 is the day before the first commit on the > config-0-0-1-branch. Note that -kk is not necessary. In fact it produces > unnecessary conflicts instead of preventing them. > > I suggest an update of the cvs policy in order to avoid such problems in > the future. The above operation would have been easier with a tag > marking the branch point. Thus creating a branch should consist of two > steps: > > cvs tag --fork > cvs tag -b --branch > > Then a merge from trunk would be done with: > > cvs -update -d -j --fork -j HEAD > > If I get positive feedback on this I would update the wiki page myself. Or simply if you don't get any negative feedback - maybe its the lack of some caffeine intake but I'm having troubles to grasp the CVS concepts you mentio, so I'll trust on your judgment, especially since it appears to simply the procedure considerably. Jose Fonseca --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] CVS merge problem solved + suggestion for cvs policy
José Fonseca wrote: On Tue, Oct 07, 2003 at 12:33:49PM +0200, Felix Kühling wrote: Hi all, I'm happy to report that I found a solution to the merge problems Eric and I were seeing. I believe the problem had to do with vendor branches. They are created automatically when sources are imported using cvs import. Many files from XFree86 had a vendor branch (e.g. revisions 1.1.1.x) with several revisions, each corresponding to a cvs import. The config-0-0-1-branch and savage_1-0-0_branch were forked off such vendor branches of these files. However, the last merge from XFree86 was done using cvs commit instead of cvs import. Therefore the new head revision of the XFree86 files was e.g. 1.2. Now a normal cvs update -d -j HEAD would determine 1.1 as common ancestor revision of the branch and the current trunk while the real ancestor revision is 1.1.1.x (on a vendor branch). The solution is to explicitly specify the ancestor revision as the branch point. This is the command line I used for that purpose: cvs -z3 update -d -j config-0-0-1-branch:2003-05-25 -j HEAD where 2003-05-25 is the day before the first commit on the config-0-0-1-branch. Note that -kk is not necessary. In fact it produces unnecessary conflicts instead of preventing them. I suggest an update of the cvs policy in order to avoid such problems in the future. The above operation would have been easier with a tag marking the branch point. Thus creating a branch should consist of two steps: cvs tag --fork cvs tag -b --branch Then a merge from trunk would be done with: cvs -update -d -j --fork -j HEAD If I get positive feedback on this I would update the wiki page myself. Or simply if you don't get any negative feedback - maybe its the lack of some caffeine intake but I'm having troubles to grasp the CVS concepts you mentio, so I'll trust on your judgment, especially since it appears to simply the procedure considerably. Hmm. These problems only arise because of the way the merge was done? Why not just document the right way to do the merge? Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] CVS merge problem solved + suggestion for cvs policy
On Tue, 07 Oct 2003 12:32:45 +0100 Keith Whitwell <[EMAIL PROTECTED]> wrote: > José Fonseca wrote: > > On Tue, Oct 07, 2003 at 12:33:49PM +0200, Felix Kühling wrote: > > > >>Hi all, > >> > >>I'm happy to report that I found a solution to the merge problems Eric > >>and I were seeing. I believe the problem had to do with vendor branches. > >>They are created automatically when sources are imported using cvs > >>import. Many files from XFree86 had a vendor branch (e.g. revisions > >>1.1.1.x) with several revisions, each corresponding to a cvs import. The > >>config-0-0-1-branch and savage_1-0-0_branch were forked off such vendor > >>branches of these files. > >> > >>However, the last merge from XFree86 was done using cvs commit instead > >>of cvs import. Therefore the new head revision of the XFree86 files was > >>e.g. 1.2. Now a normal cvs update -d -j HEAD would determine 1.1 as > >>common ancestor revision of the branch and the current trunk while the > >>real ancestor revision is 1.1.1.x (on a vendor branch). The solution is > >>to explicitly specify the ancestor revision as the branch point. This is > >>the command line I used for that purpose: > >> > >>cvs -z3 update -d -j config-0-0-1-branch:2003-05-25 -j HEAD > >> > >>where 2003-05-25 is the day before the first commit on the > >>config-0-0-1-branch. Note that -kk is not necessary. In fact it produces > >>unnecessary conflicts instead of preventing them. > >> > >>I suggest an update of the cvs policy in order to avoid such problems in > >>the future. The above operation would have been easier with a tag > >>marking the branch point. Thus creating a branch should consist of two > >>steps: > >> > >>cvs tag --fork > >>cvs tag -b --branch > >> > >>Then a merge from trunk would be done with: > >> > >>cvs -update -d -j --fork -j HEAD > >> > >>If I get positive feedback on this I would update the wiki page myself. > > > > > > Or simply if you don't get any negative feedback - maybe its the lack of > > some caffeine intake but I'm having troubles to grasp the CVS concepts you > > mentio, so I'll trust on your judgment, especially since it appears to > > simply the procedure considerably. > > Hmm. These problems only arise because of the way the merge was done? Why > not just document the right way to do the merge? There may be more cases where you commit new revisions to imported sources. The result is the same except the number of files affected is probably smaller. OTOH I might report this as a bug against CVS and they should fix it :) > > Keith Felix __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] CVS merge problem solved + suggestion for cvs policy
> > Hmm. These problems only arise because of the way the merge was done? Why > > not just document the right way to do the merge? > I'd agree with Keith the proper way to merge needs documenting, CVS vendor import is what is needed, the XFree CVS is vendor imported into our DRI tree, the changes from the last XFree merge are then merged onto the trunk for files that we have changed... I recently (with some help) manually cleaned up some Linux-VAX development CVS trees that had been hand merged not using vendor stuff, it just takes judicious use of the cvs admin -b command... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] CVS merge problem solved + suggestion for cvs policy
On Tue, 2003-10-07 at 13:32, Keith Whitwell wrote: > > Hmm. These problems only arise because of the way the merge was done? Why > not just document the right way to do the merge? I think tagging the branch point is a good idea regardless. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] CVS merge problem solved + suggestion for cvs policy
Michel Dänzer wrote: On Tue, 2003-10-07 at 13:32, Keith Whitwell wrote: Hmm. These problems only arise because of the way the merge was done? Why not just document the right way to do the merge? I think tagging the branch point is a good idea regardless. I agree. Documenting both the right way to do a merge *and* suggesting the extra tag (as a back-up) are good ideas. It would probably be a good idea to also document *why* these steps are desireable. :) --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] CVS merge problem solved + suggestion for cvs policy
On Tue, Oct 07, 2003 at 12:23:16PM +0100, José Fonseca wrote: > On Tue, Oct 07, 2003 at 12:33:49PM +0200, Felix Kühling wrote: > > Hi all, > > > > I'm happy to report that I found a solution to the merge problems Eric > > and I were seeing. I believe the problem had to do with vendor branches. > > They are created automatically when sources are imported using cvs > > import. Many files from XFree86 had a vendor branch (e.g. revisions > > 1.1.1.x) with several revisions, each corresponding to a cvs import. The > > config-0-0-1-branch and savage_1-0-0_branch were forked off such vendor > > branches of these files. > > > > However, the last merge from XFree86 was done using cvs commit instead > > of cvs import. Therefore the new head revision of the XFree86 files was > > e.g. 1.2. Now a normal cvs update -d -j HEAD would determine 1.1 as > > common ancestor revision of the branch and the current trunk while the > > real ancestor revision is 1.1.1.x (on a vendor branch). The solution is > > to explicitly specify the ancestor revision as the branch point. This is > > the command line I used for that purpose: > > > > cvs -z3 update -d -j config-0-0-1-branch:2003-05-25 -j HEAD > > > > where 2003-05-25 is the day before the first commit on the > > config-0-0-1-branch. Note that -kk is not necessary. In fact it produces > > unnecessary conflicts instead of preventing them. > > > > I suggest an update of the cvs policy in order to avoid such problems in > > the future. The above operation would have been easier with a tag > > marking the branch point. Thus creating a branch should consist of two > > steps: > > > > cvs tag --fork > > cvs tag -b --branch > > > > Then a merge from trunk would be done with: > > > > cvs -update -d -j --fork -j HEAD > > > > If I get positive feedback on this I would update the wiki page myself. > > Or simply if you don't get any negative feedback - maybe its the lack of > some caffeine intake but I'm having troubles to grasp the CVS concepts you > mentio, so I'll trust on your judgment, especially since it appears to > simply the procedure considerably. This is a little puzzling to me to, as I did do the last merge with cvs import. Alan. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
