Re: [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 <address@hidden> 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
address@hidden
http://lists.nongnu.org/mailman/listinfo/koha-devel

-- 
IT Tech
Crawford County Federated Library System