Re: [Koha-devel] Re: distributed VCS, some thoughts.

[Jerry Van Baren]

Paul POULAIN wrote:
> thinking of it, I was wondering wether a distributed VCS should be
> considered as a "Release Manager" oriented VCS.
>
> I explain : unless i'm mistaken, it means :
> - kados is the RM
> - paul & chris are working on some feature
> - paul "commit" the feature to kados repository, who will accept it (or
> how is he warned that I made something ?)
> - chris update his copy from kados one.
>
> iiuc, a D-VCS is in fact a RM-VCS to my mind. Thus the question : do we
> have a RM that can afford that task/responsability ?
> Once again, I may be mistaken, but i'm a little bit less enthusiasm if
> i'm right...

This is where a D-VCS *really* shines (at least git, probably the others 
as well).  The advantages of D-VCS is that you have not only branches 
but also replicated repositories to work with.  The following is how 
things work with linux and git.  It may apply to other D-VCS, but I 
don't know.

You have a development master repository.  For linux, it is Linus 
Torvald's on kernel.org.  For Koha, this likely would be the 3.x 
development one.  Only Paul Poulain (or whoever is the development 
master) does commits into this repo.  Paul and Chris would have their 
own feeder repos and _ask_ Paul to pull changes, they would not 
(normally) push changes into the RM repo.

The RM (Kados) also has a master repository.  Bugfixes and also any 
backporting of new features get pulled into the repository by Kados. 
Pulls is the norm, pushes are generally not done.

You then have feeder repositories that the master maintainer (Paul for 
the development repo, Kados for the release repo) pulls improvements 
from after they've been vetted.  This would be Paul & Chris & everybody 
else in a hierarchy.

All the koha developers then have their local working repository, which 
is a clone of the master + "value added".  In the local repository, they 
pull changes from the master RM repo to keep up to date, as well as 
doing their local work.  If another feeder repo has a change they 
want/need, they can pull that change directly from the feeder repo 
(including "cherry-picking" changes).  Since git keeps track of changes 
by their hash name, when the master RM repo picks up a feeder's change, 
the local repos that already have that change just say "been there, done 
that, fast forward" and life is good.  Otherwise a merge is done and 
life is still good (except for a collision, but that is unavoidable and 
is no different than what happens with CVS/SVN).

Local changes are source controlled in the local repo - something I've 
never succeeded in doing well with CVS/SVN, but is transparently trivial 
with git.  When a local change is considered ready for inclusion, by 
convention a branch is created in the local repo with a distinctive name 
and the appropriate upstream repo owner is notified (traditionally by 
posting a patch on the developers' email list so everybody can review 
the change).  The upstream repo owner then pulls the change into the 
upstream repo, ultimately ending up in the master RM repo (or the "new 
HEAD" repo) and spreading back out over the world from there.

Poor ASCII-art diagram:

            backport
Development --------> Release
   ^   ^               ^  ^
   |    \      _______/  /
   |     \    /    _____/ bugfixes
feeder1 feeder2   /
  ^  ^  ^ ^  ^   /
 /   |/   |   \ /
dev1 |   dev3 dev4
    dev2

(I tried to make a line from "dev2" into both feeder1 and feeder2 - the 
tree need not be a strict hierarchy.  Dev2 can generate a change that 
gets pulled into both feeder1 and feeder2 and subsequently into 
Development with no confusion - if feeder2 gets pulled into Development 
first, the duplicate in feeder1 will be identified and "fast forwarded.")

HTH,
gvb