[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 <gerald.vanbaren at smiths-aerospace.com> 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).
>
> Kyle at kyle.com 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".
>
> Chris at chris.com 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".
>
> Josh at koha.org 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* <gerald.vanbaren at smiths-aerospace.com
> > <mailto: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 <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
> >     Koha-devel at nongnu.org <mailto:Koha-devel at nongnu.org>
> >     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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20070316/f065e926/attachment-0002.htm>