www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <santiago.g...@gmail.com>
Subject Re: Subversion Server Plan
Date Mon, 30 Mar 2009 20:39:37 GMT
El lun, 30-03-2009 a las 12:49 +0100, sebb escribió:
> On 30/03/2009, Paul Querna <paul@querna.org> wrote:
> > On Mon, Mar 30, 2009 at 6:55 AM, Sander Temme <sctemme@apache.org> wrote:
> >  >
> >  > On Mar 29, 2009, at 3:24 PM, Paul Querna wrote:
> >  >
> >  >> - Setup svn.apache.org with GeoIP based resolving:
> >  >>  - svn.us.apache.org and svn.eu.apache.org
> >  >>
> >  >> - For git-svn / dcommit, have it hit git-master.apache.org directly,
> >  >> but try to avoid publishing this URL for most users. (thoughts?)
> >  >
> >  >
> >  > Reverse proxy it from the above?  How would Git be told to behave
> >  > differently?
> >
> >
> > Joe explained it much better than I could:
> >  """" The problem appears whenever someone wants to check-in a sequence
> >  of commits made with git and they're using a mirror for that purpose.
> >  They run git dcommit and that generates a bunch of svn transactions
> >  that basically look like svn commit, svn up, svn commit, svn up, etc.
> >  The svn up part chokes of course, because the mirror hasn't picked up
> >  the commit yet, causing git to throw an error and tell the user to
> >  "rebase".
> >  """"
> >
> 
> Git should be more patient with proxies - it's not yet an old dog, so
> can perhaps be taught some new tricks ;-)

Subversion was sold to us (and probably to the git-svn developers) as
something with a feature called "atomic commits"... if git-svn commits
and updates what it committed later on, as sanity check (and maybe
because of keyword expansion or other nasty tricks that can spoil the
crypto hash), and the reload does not contain the commit it just did, I
think panicking is the only reasonable behaviour.

If the mirroring of svn leaks [1], and we all know in network
programming that all abstractions do leak, I don't think it will be easy
to work around it in git-svn.

A svn mirror should not return a revision as committed until it can
provide it to clients, or else should block on updates to "hot"
revisions (those committed through it) until they become available. I
mean, a HTTP proxy passing POSTs through, while allowing GETs of the
stale resources would be considered as broken, I think.

[1] http://www.joelonsoftware.com/articles/LeakyAbstractions.html

Regards
Santiago


Mime
View raw message