[gdal-dev] [update] Re: Travis CI continuous integration service for GDAL

[Even Rouault]

Le mercredi 10 octobre 2012 21:49:49, Etienne Tourigny a écrit :
> Hi Even,
> 
> the main advantage of github is that you can manage patches/pull
> requests more easily, and it's easy for someone to setup a fork with
> substantial changes, and anyone can pull that fork and try it without
> much hassle.
> The other way of doing it with trac/svn is to upload patches to
> tickets, and then more patches after review etc.... Which works fine,
> but a bit clumsy compared to github forks and pull requests.

If someone submits a pull requests, and if that submitted code needs to be 
changed due to what is seen during the review, what is the process ? It is 
certainly nice to be able to merge the history of commits (I often wish that 
submitted patches to Trac would be split into more logical smaller changesets 
to make review easier). But that only makes sense when the history is clean 
(you generally don't care about trial-and-errors intermediate commits that 
would pollute the history of the main repository). I believe that it is 
possible to do that with git ("git rewrite history" leads to http://git-
scm.com/book/ch6-4.html), but to my non-git specialists eyes, this looks far 
from being obvious. Do you know how QGIS for example deal with that ?

> 
> I even did some collaborative work last year in gdal using github as
> the shared repos, and pushing to svn but that was a bit clumsy (the
> git-svn part) and I have stopped using that approach.

you mean "git svn dcommit" didn't work as you expected ?

> 
> > But as a SVN committer, my opinion is obviously biased since contributing
> > is of course more straighforward than for a non-GDAL committer. GIT has
> > certainly a more egalitarian approach (everyone can commit or fork),
> > although that someone that hasn't push rights can only send pull
> > requests to the main repository.
> 
> I'd say svn is fine for core devs, not optimal for occasional submitters.
> 
> > My knowledge of GIT is rather limited, but, for a GDAL contributor
> > without commit (SVN)/push(GIT) rights to the main repository, what
> > improvements would a full move to GIT would offer with respect to the
> > current git-svn mirroring ?
> 
> a more seamless flow between the dev's work and pushes to the main source.
> 
> As far as I can tell, the git part of your setup is just for the
> continuous builds right?

Yes mostly, and because it might be more convenient for people prefering GIT 
to do work. This could also be a kind of cheap test bench to assess what 
switching to GIT could bring to GDAL.

> In fact git is used as a read-only, so I
> don't see how having a git mirror helps contributing code.

Can't people fork the git mirror ? My hope was that a GDAL SVN committer could 
use its own git-svn mirror, that has a origin to OSGeo/gdal, and try to merge 
in it pull requests submitted to OSGeo/gdal, and then git svn dcommit. I 
thought this was possible, but I might be wrong. I'm aware that git-svn would 
be more complicated than a pure GIT repository. But, from the side of 
occasional contributors, would that make a difference in their process ?

I'm trying to understand if the git-svn mirror can bring some factual evidence 
that a switch to GIT would be beneficial.

Even