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

[Kyle Hall]

Thank you for illuminating us on the ways of git ; )
It seems from you're description if there are lot's of Kyle's, that the likes of Chris and Paul are in for more work that previously. I, on the other hand, would be effected little.

Thanks,
Kyle

On 3/16/07, Jerry Van Baren <address@hidden> wrote:

Yes on the concepts, no on the level of effort.  :-)

I'm not very familiar with koha's current VCS structure and methods
since I'm not actively developing koha code (I installed koha at the
private school that I donate my time too ;-) and only monitor the list
for developments).

It sounds like there are several developers with write access to the
master repo.  This could be carried forward, but isn't the way git is
being used elsewhere.  Git is being used mostly as single-user per repo
with the repos being available via http: or git: (preferably the
latter).  Hierarchy with single developers is an excellent way of
providing scaling and preventing inadvertent interference.

Git background and tutorials:
<http://git.or.cz/ >
<http://www.kernel.org/pub/software/scm/git/docs/tutorial.html>
< http://www.kernel.org/pub/software/scm/git/docs/everyday.html>

The following is the concept, likely not 100% correct since I didn't
actually execute the commands.  It is also just one way of doing it (for
example, pull is a fetch+merge - doing a fetch, inspect the potential
changes, and then merge them has its benefits).

address@hidden would have his repo and create New Code[tm].  He would
either do this development in a new branch in his repo or would create a
new branch for Chris:
   git checkout -b for_chris
   git pull . <commitID>
(where <commitID> is his previously committed changes in his master
branch) and email Chris "hey, pull for_chris".

address@hidden would pull it into his repo by creating a temporary
testing branch "from_kyle" and pulling the changes:
   git checkout -b from_kyle
   git pull git://kyle.com for_chris
Chris tests the updates and likes them.  He merges it into his mainline:
   git checkout master
   git pull . from_kyle
and emails Josh "hey, pull "from_kyle".

address@hidden does the equivalent, but, since he trusts Chris, doesn't
bother creating a temporary branch for testing:
   git pull git://chris.com from_kyle

Some time later Chris and Kyle update their copies from koha.org:
   git pull
at which time the changes that came from Chris will be fast forwarded
and they can delete their respective branches
Kyle:
   git branch -d for_chris
Chris:
   git branch -d from_kyle

It really doesn't take much time because, by the time the changes bubble
to the top, the trust and testing has been performed and the change just
needs to be pulled.  Since the pulls are just the changes, they are very
quick.

Linus is doing this at the top level for linux with a handful of
lieutenants (I don't know the current count, probably under 10).  The
number of active developers and changed lines of code is or should be
way higher than what koha has.  Linus isn't doing it full time, he still
has time to rewrite portions of gnome.
   <http://www.linux.com/article.pl?sid=07/02/16/1937237 >
;-)  The git methodology scales well because it was designed from the
ground up to be robust, efficient, and scalable.

gvb


Kyle Hall wrote:
> 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
> <mailto: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 <http://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 <mailto:address@hidden>
>     http://lists.nongnu.org/mailman/listinfo/koha-devel
>
>
>
>
> --
> IT Tech
> Crawford County Federated Library System
> ______________________________________________________________________
> CAUTION: This message was sent via the Public Internet and its
> authenticity cannot be guaranteed.
>
> ______________________________________________________

-- 
IT Tech
Crawford County Federated Library System