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

[Jerry Van Baren]

Yes, for a pull to happen, the repository must be publicly accessible 
(i.e. on the internet).  The best way is via the git port 9418, the 
other way is via port 80 using http: (I presume 443 https: works too, 
have not tried).  Unfortunately, many IT departments block all ports 
except 80 and 443 (including ssh, grrrrr).  Depending on what an 
individual developer has to work with (what the IT department provides 
for access), publishing a local repository can be difficult or 
impossible.  Pushing is generally (exclusively?) done via ssh so 
unenlightened/uncooperative IT departments can be a problem for pushing 
as well (cvs/svn have the same problem).

What Wolfgang Denk did for u-boot is to set up a bunch of feeder 
repositories on his company's server and give the feeder developers ssh 
access so that they could push their local repositories to the main 
server, at which point the world can pull from the main repository and 
any feeder repositories that they need.
   <http://www.denx.de/wiki/UBoot/Custodians>
I presume that is similar to what the primary linux kernel developers 
have on <http://git.kernel.org/>, but better organized.  The u-boot 
feeder repositories is a fairly new development.  It has been working 
well so far...

Having all the feeder repositories collected in one place for ease of 
reference is ideal.  Since git is a distributed SCM, all your eggs are 
in everybodys' baskets (repo clones) so this is not a problem.

Obviously, this takes some effort to set up and a host (like koha.org) 
to run it on.

HTH,
gvb


Kyle Hall wrote:
> Thanks for the extra information. Just on a technical note, let's say I 
> e-mail you and say 'pull the changes I've made from my local repository 
> into yours', this means that I have to have my work pc publicly 
> available. I assume that git has a certain port it works on. Is that 
> correct?
> 
> Kyle
> 
> On 3/19/07, *Jerry Van Baren* <gerald.vanbaren at smiths-aerospace.com 
> <mailto:gerald.vanbaren at smiths-aerospace.com>> wrote:
> 
>     Well, it is hard to be definitive without a clue of your current
>     development methodologies, but I would speculate that it will take
>     somewhere from little more to a lot less time than CVS/SVN with multiple
>     writers (note that you can still have multiple writers with git, it just
>     is not generally useful since everybody has their own copy of the
>     repository).
> 
>     If the code in CVS never gets messed up because of multiple people
>     committing incompatible changes, it will take minimal extra time for
>     everybody upstream to pull changes.
> 
>     On the other hand, if ever you get a mess due to multiple people
>     committing incompatible stuff in CVS, you've just saved every bit of
>     time that the extra pulling cost.  I suspect this has already happened
>     at least once. :-/
> 
>     I tried to outline a "pull" scenario in a previous email to illustrate
>     that it is NOT painful.  Doing a pull is a single command you run that
>     takes seconds to run and you do it occasionally (on demand, when you
>     feel like it, once a day, once a week, whatever makes sense).  It is
>     the
>     same level of effort as doing a "svn update".  In addition, if you use
>     local source control (maintaining a local copy of the cvs/svn repository
>     to track local changes or using RCS locally) *which all developers
>     should do*, git is a huge improvement.
> 
>     All of the developers will benefit (save time) with git, so the net time
>     savings equation is positive, regardless.  There is a learning curve to
>     climb, but it isn't very steep and the rewards are pretty good.
>     RCS - gets the job done but cannot share the changes
>     CVS - gets the job done over the wire, allowing sharing (Pinto)
>     SVN - puts a turbocharger in the Pinto (Pangra)
>     git - everybody makes their own clone of the Lamborghini
> 
>     Reference pointers for the non-US residents (and youngsters ;-):
>     <http://en.wikipedia.org/wiki/Ford_Pinto>
>     < http://en.wikipedia.org/wiki/Supercar>
> 
>     Best regards,
>     gvb
> 
> 
>     Kyle Hall wrote:
>      > I think everyone would agree that more checking of code is good.
>     As long
>      > as you and Paul and Josh are willing to put in a bit more time, I
>      > imagine everyone will be all for it. I think the big question is *how
>      > much* more time will it require from you guys. I think only the
>     people
>      > currently using git will be able to help us answer us.
>      >
>      > Kyle
>      >
>      > On 3/16/07, *Chris Cormack* <chris at katipo.co.nz
>     <mailto:chris at katipo.co.nz>
>      > <mailto:chris at katipo.co.nz <mailto:chris at katipo.co.nz>>> wrote:
>      >
>      >     On Fri, Mar 16, 2007 at 03:04:30PM -0400, Kyle Hall said:
>      >      > 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.
>      >      >
>      >     Speaking as Chris
>      >
>      >     I don't think this is nessecarily a bad thing, a bit more
>     checking as
>      >     code comes in can save a bunch of time in the future. I guess
>     what I'm
>      >     saying is we should be doing something like this currently
>     anyway, at
>      >     least we should be sanity checking code as its committed. We
>     wouldnt
>      >     end up with dual implementation of the same feature, and some
>     of the
>      >     duplicate code we now have.
>      >
>      >     Chris
>      >
>      >
>      >     --
>      >     Chris Cormack
>      >     Programmer
>      >     027 4500 789                                       Katipo
>      >     Communications Ltd
>      >     chris at katipo.co.nz <mailto:chris at katipo.co.nz>
>      >     <mailto:chris at katipo.co.nz
>     <mailto:chris at katipo.co.nz>>                                          www.katipo.co.nz
>     <http://www.katipo.co.nz>
>      >     < http://www.katipo.co.nz>
>      >
>      >
>      >
>      >
>      > --
>      > 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
> ______________________________________________________________________
> CAUTION: This message was sent via the Public Internet and its 
> authenticity cannot be guaranteed.
> 
> ______________________________________________________