[crossfire] Moving server towards a modularized system?

[tchize]

Le Mercredi 18 Janvier 2006 15:42, Miguel Ghobangieno a écrit :
>Except that you are not working on one section of the
>code, you are restructuring the whole server into
>diffrent modules. This means that if you develop in
>cvs there will be breakage with any and everyone else
>as you sweeping edits touch every facet of the glory
>that is crossfire.
>
>The C in CVS may mean concurrent but it doesn't mean
>perfect.
>
>If you want to make the sweeping changes on your own
>system; enjoy. But please, before committing to cvs do
>extensive bugtesting so that it 1) doesn't make the
>code any slower, 2) doesn't break anything, and 3)
>maybe makes MS less of a hog?
>

First, it will be a step by step change. For the obvious reason, a patch 
changing 40% of server code would take weeks to create and during this 
change, developper of the patch would have to do a regular 'cvs update' to 
incorporate other developpers change and would have to adapt each of their 
change to new modular system.

Second, indeed cvs isn't perfect. It's written in there doc, nothing can 
replace the coder in case of a conflict (eg we are moving away the whole 
parts of move_apply() somewhere else and at same time another developper is 
trying to add new object type). This is not a problem. After cvs update, the 
guys trying to add things to move_apply() will see a conflict in move_apply() 
and will see the other coder comment saying "this code has been mainly moved 
to xyz". Just also move your new add-on.

Once again, there has been restructurations in the past. This of course lead 
to conflicts during cvs update process. Then what? Just fix the conflict. 
That's how teamworks goes. Team is adapting you code changes during their 
development process, when team has commited adapt your uncommited changes to 
what team commited.

Unless you work on a 'checkout, work on my stuff for 2 months locally, try to 
commit', the conflicts shouldn't be a big deal as, once again, it is very 
difficult to commit big patches.


If it is really needed, i suppose the change could be done in a branch. This 
would allow people who want to explore the idea of modularized system to work 
in team and try different paths without fearing the 'try not to break the 
existing'. This head should then be merged on this branch in a regular basis. 
This is lots of additionnal work. But it also has it's gains imho. And when 
modularized system is ok, move it to the head.  But there, this mean when 
branch is finally moved to the head (if idea does not proves to be a dead 
end), people will indeed see a 40% of server code patch coming.


-- 
--
Tchize (David Delbecq)
tchize at myrealbox.com
Public PGP KEY FINGERPRINT:
    F4BC EF69 54CC F2B5 4621  8DAF 1C71 8E6B 5436 C17C
Public PGP KEY location:
    http://wwwkeys.pgp.net/pgpnet/wwwkeys.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20060118/06adc2f6/attachment.pgp