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

[Kyle Hall]

I've been chatting with kados, and he suggested I get some feedback from
Jerry.

It seems that if we switched to git we would need someone full-time just
managing commits from the way I read Jerry Van Baren's post. It seems like
the koha community, though dedicated, just isn't big enough to absorb the
cost of losing development time to managing source code control. I doubt
there are many programmers out there that would prefer to be managing the
code they've written rather than writing more code ; )

What leads me to these conclusions is the whole hierarchy of 'pull' rather
than push. It means that at each level of development, say me->chris->josh,
everyone except the first person (me ) has to actively pull changes from the
level below them. Please correct me if I am mistaken.

Kyle

On 3/16/07, Jerry Van Baren <gerald.vanbaren at smiths-aerospace.com> wrote:
>
> 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
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at nongnu.org
> http://lists.nongnu.org/mailman/listinfo/koha-devel
>



-- 
IT Tech
Crawford County Federated Library System
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20070316/5af4df30/attachment-0002.htm>