www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Querna <p...@querna.org>
Subject Re: Subversion Server Plan
Date Mon, 30 Mar 2009 22:44:50 GMT
On Mon, Mar 30, 2009 at 10:39 PM, Santiago Gala <santiago.gala@gmail.com> wrote:
> 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.
>

It is possible to make replication somewhat-blocking to the origin
slave, although it would mean some commits would take a very long
time, but any incentive for people to make smaller commits might be
good :P

(blocking in the post-commit hook for it to finish, as the svn client
doesn't get the okay until post-commit finishes)

Mime
View raw message