[Freeciv-Dev] Re: freeciv-test

[Daniel Sjölie <deepone@xxxxxxxxxx>]

Jason Short wrote:
> Raimar Falke wrote:
> > So this is for people who know
> >  - how to do a CVS checkout
> > and who doesn't know
> >  - which patches fly around
> >  - how to apply a patch
> > ?
> 
> It's not just a question of "knowing", it's a bigger question of effort. 
>   Applying each new patch to CVS is a pain...each time a new version 
> comes along each tester must revert and re-apply the patch.
> 
> It is also helpful to have one repository of a number of patches; that 
> way all of them can be tested at once.  With ~10 patches available at 
> any one time, that's a 10x increase in testing efficiency.  (Although it 
> may take longer to track down problems if they do occur.)

Exactly...

> > 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 :)?

> As I've said before, this process would be substantially easier using a 
> development branch of the "official" CVS repository.  If CVS allowed 
> giving commit access to only a certain branch, this would be a 
> no-brainer...but since it doesn't (AFAIK), this would probably mean 
> maintainership of the branch would go out to a few trusted people, and 
> we'd have the same bottleneck we do now.

Right... But it might be good to have a completely separate repositry to
try new stuff like cvs merging out with... ;)

/Daniel

-- 
Now take a deep breath, smile and don't take life so seriously... :)