axiom-developer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Bill Page
Subject: RE: [Axiom-developer] RE: [M#73697383] Re: Disk-quota Request
Date: Wed, 4 Oct 2006 21:26:50 -0400

Gaby,

On October 4, 2006 6:19 PM you wrote:
> 
> "Bill Page" <address@hidden> writes:
> 
> [...]
> 
> | We can either continue debugging this process or wait until
> | someone else does since it seems unlikely that decision to
> | use subversion (and associated tools) will be changed just
> | because two of the Axiom developers can't seem to get it to
> | work. :-(
> 
> I know I should help you here -- but I'm overbooked at the moment,
> plus a sick baby, I've got only that much time left.  :-( Sorry.
>

Not a problem. Don't worry. I hope your baby is ok. We've got to
take care of reality first - then we play. :-)
 
> I hope this will be resolved soon.  (Could you refresh my memory
> about what was wrong with copying the repo with SVK?)
> 

'svk smerge' worked except the size of the mirror created by
smerge is approximately twice as large as the original archive.
(Over 300 Mbytes while the original is only about 160Mbytes.) I
guess (but I do not know) that this might be because svk does not
preserve the "copy" structure of the original archive and ends
up duplicating a lot more code unnecessarily.

Google has set our space quota at 250 Mbytes, so the 'svk smerge'
job failed with an "over the quota" error message without even
creating the build-improvements branch.

'svnsync' works with the Axiom repository locally and produces
a mirror that is the same size as the original.

(Of course, on compatibility architectures rsync does the same
thing and faster, so that isn't such an incredible result. :)

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.

  -- just my two-bytes.

Bill Page.


Regards,
Bill Page.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]