Re: [Axiom-developer] RE: [M#73697383] Re: Disk-quota Request

[Ben Collins-Sussman]

On 10/4/06, Bill Page <address@hidden> wrote:

> The problems that I have been having with svnsync seem more like
> network/webserver issues than archive issues as such. This is the
> same kind of problem that we have been having with SourceForge,
> which makes we wonder about the quality and robustness of the
> svn http/webdav interface. The kind of "tight" integration with
> Apache that subversion uses might sound good at the nuts and
> bolts level, but in practice source code management systems like
> darcs and mercurial seem to do quite well without this and as a
> result are MUCH easier to set up and manage.

Actually, the problem with HTTP/webdav isn't robustness, it's just
speed.  Let's face it:  a stateless protocol is a *bad idea* for
version control.  :-)   The stateful svnserve server/protocol is much,
much faster.  Nevertheless, there are some perks for using Apache:  it
integrates with every authn system out there, it logs things
beautifully, it goes through firewalls, it can do certs, and you can
even mount your repository as a network share.  It's all about
tradeoffs.

Looking at your errors, I'm guessing that revision 3 of your
repository is some monstrously huge thing, and that it's taking hours
to commit... and then poof, you lose the connection or something.
That's not good.  We obviously need to add a --verbose option to
'svnsync' so that we can see what path it's pushing around, much like
one sees with dump/load.

Anyway, yeah, r2 is the latest in the repository, and svnsync left
markers saying what it was doing:

$ svn proplist --verbose --revprop -r0 http://axiom.googlecode.com/svn/
Unversioned properties on revision 0:
 svn:sync-from-uuid : 54bea96e-1511-0410-8851-aaeae44645fa
 svn:sync-currently-copying : 3
 svn:sync-last-merged-rev : 2
 svn:sync-from-url : file:///home/page/axiom-sf
 svn:date : 2006-04-10T15:40:55.446251Z

Because svn has atomic commits, and because svnsync recorded what it
was doing, in *theory* you should just be able to restart the sync,
and have it pick up where it left off.  Sure enough, it seems like you
did that.  So the only remaining mystery is:  why did the http PUT of
that one file give an authz error?   It might be a bug in our custom
authorization module, but I'm not sure.

Can we try two things:

* try running sync a couple more times, see if it ever successfuly commits r3.

* put a tar.gz of the repository somewhere, so I can play with it
myself?  I'd like to try pushing the history into a scratch project
myself, to see if I can reproduce that 403 error.

(As a last ditch thing, i can also manually 'svnadmin load' your
history directly to our servers if we decide to give up on svnsync...
we've already done that for emacspeak and some other projects.)