[Freeciv-Dev] Re: freeciv-test

[Jason Short <vze2zq63@xxxxxxxxxxx>]

Daniel Sjölie wrote:

> Jason Short wrote:
>
> > Raimar Falke wrote:
> > > If it is so you may go through patches-submitted and apply all patches
> > > which do something the user may notice. Mhhhh the CMA isn't in
> > > patches-submitted.
> > >
> > > The problem I see and which only time will answer is how much work is
> > > required to have this tree updated and how much work are you willing
> > > to spend.
> > Yes, this is the question.
> >
> > I would suggest that a side branch of the tree be kept in sync with 
> > "official" CVS.  That is, any time a patch is applied to the "official" 
> > branch it also be applied the <whatever> branch of freeciv-test (or this 
> > can be done on a periodic basis by updating freeciv-test to 
> > match...whatever).
> > Then, the main branch can contain all freeciv-test changes.  This can be 
> > updated from the side branch using CVS's branch-merging capabilities 
> > (cvs update -j).
> > The main point is to allow merging of incompatible patches with a 
> > minimum of problems.  If a patch exists on freeciv-test, and is applied 
> > in a different form to "official" freeciv, merging the changes back into 
> > freeciv-test is nontrivial.  One alternative is to back out the original 
> > patch (which may be difficult if it is mixed with other patches) before 
> > updating.  Using branching, the matching parts will be merged cleanly 
> > and other parts will be dealt with using CVS's "conflict" system 
> > (whereby the two versions are placed side-by-side, and you manually 
> > resolve the conflict).  A third alternative is to manually make the 
> > changes.  In my experience the second way is _much_ easier.
> Sounds good...
> Not sure I follow your every turn though...
> Some examples might be enlightening... :)
>
> Here's an example of what I thought...
> 4 branches (more with more patches)
> main
> cvs (in sync with official freeciv cvs)
> sound
> conndlg
>
> then when you want to update the sound patch what you do is update the
> sound branch (it should contain latest sound patch on top of latest
> freeciv cvs), check that in to the sound branch and merge the sound
> branch into the main branch... That would be easiest with another
> working copy for that... Like:
>
> source@abyss~/freeciv-test/sound>
> (working copy of sound branch here - update and check in)
> source@abyss~/freeciv-test/sound>cd ../main/
> (working copy of main branch here)
> source@abyss~/freeciv-test/main>cvs -z3 up -dP -j sound
> source@abyss~/freeciv-test/main>cvs -z3 ci -m 'updated sound merged'
>
> And similar for updating the main branch to latest freeciv cvs or latest
> version of another patch...
>
> Do you think that would work? Do you have a better way (with example :)?
That should work, yes.  I had not considered having a separate branch 
for each patch; doing so will enable you to use the merging features to 
merge the patches themselves (which is very good) - but will up the 
overhead because each branch needs to be maintained (i.e. kept in sync 
with "official" CVS, at least sometimes).
In your example above, note you've checked out two copies of freeciv-test:

~> mkdir freeciv-test; cd freeciv-test
~/freeciv-test> cvs co -d[...] freeciv-test
~/freeciv-test> mv freeciv-test main
~/freeciv-test> cvs co -d[...] freeciv-test
~/freeciv-test> mv freeciv-test sound; cd sound
~/freeciv-test/sound> cvs up -r sound


Consider the problems when updating from "official" cvs, though.  You'll 
need (at least sometimes) to propogate the changes back through _all_ of 
 the branches.  If part of the sound patch is committed, for instance, 
after you update the "official" branch of freeciv-test you'll probably 
want to merge those changes into the sound branch, and then merge from 
there into the main branch.  If you've gone a few days without merging 
and parts of the sound patch and the improved connection dialog patch 
have been put into CVS, you'll need to merge through both branches 
before going to main (I think).
If some random extra patch is applied that changes code that has already 
been changed by both the sound patch and the conndlg patch, then you'll 
need to (1) update the official branch of freeciv-test, (2) merge those 
changes into the sound branch + resolve conflicts, (3) merge those 
changes into the conndlg branch + resolve conflicts, and (4) merge those 
changes into the main branch + resolve conflicts.  In this case keeping 
things up-to-date becomes an O(n) problem.  Fortunately this should be rare.
OTOH, if something unrelated is committed to official CVS, you can 
probably just get away with merging straight to the main branch.  But if 
you try to merge to the main branch and end up getting conflicts, then 
something's wrong and you'll have to (1) figure out what patch(es) is 
causing the problems and (2) merge through that branch(es) first.
Overall, I think the way you suggest is best for large patches.  But for 
small patches that don't conflict with each other, I would consider 
having a separate "combined" branch that puts all of these patches into 
one branch.
jason