On Tuesday, November 28, 2006 5:30 PM Ben Collins-Sussman wrote: > > On 28 Nov 2006 23:16:38 +0100, Gabriel Dos Reis > <[EMAIL PROTECTED]> wrote: > > "Page, Bill" <[EMAIL PROTECTED]> writes: > > > > [...] > > > > | Up to revision 199 (October 26), the 'svk smerge' > > | transactions from the axiom-developer.org server that are > > | intended to synchronize the Google repository with the > > | SourceForge repository were properly processed by Google. > > | For reasons that I don't understand, the svk smerge process > > | did not automatically create the correct branch structure > > at Google when we created 'silver' on SVN SourceForge. > > > > I believe 'silver' was created from "scratch", so has not > > ancestry in common with any other branch in the repository -- > > if my understand of your famous picture is correct. It > > effectively is a "repository" within the repository -- > > essentially, files are _duplicated_ as opposed to being shared. > > For me, that explains the sudden surge. > >
I don't understand "repository within repository" comment but yes I agree that the large increase in size in not unexpected. In fact we discussed exactly this before the creation of 'silver' back in October. Do you recall our discuss of the consequences of having two roots in the repository? For me, the mystery is why 'svk smerge' did not successfully mirror our creation of this new branch. > > Yep, that would explain it. Branches are supposed to be cheap > copies; they're just a hardlink within the repository, so they're > nearly instantaneous to create and take essentially zero space > when they're first made. I don't know what you did on > sourceforge, but it sure wasn't a normal subversion branch! > No it was not a normal subversion branch. Our problem has a long history connected with different major Axiom developers using different source code repository systems (arch, cvs and svn). The original trunk in svn at SourceForge was created by the SourceForge tool for converting cvs to svn. The contents of cvs at SourceForge was obtained from a series of snapshots from the arch master repository. Because of improperly flagged binary files, the resulting svn repository was a bit of mess but that was eventually corrected. Meanwhile for a variety of reasons development continued on both arch and svn independently with commits to both svn trunk and to several svn branches as well as the original arch "silver". In October we decided to try to merge the changes to svn trunk and arch silver. My proposal was to automatically mirror the arch silver repository as a new "trunk" on svn so that both sets of developers could continue using their own repository systems. This resulted in the duplication of files mentioned by Gaby. To understand my motivation it is important to note that the svn mirror of the silver repository contains the history of the development in arch. While the existing trunk contains only the snapshot history from cvs. In mean time, we also implemented an automatic mirror process that is supposed to keep the Axiom Google Code repository in sync with the SourceForge repository. I guess in retrospect creating 'silver' at SourceForge after implemented the automatic mirror was a bad idea given that we are so severely limited in disk quota at Google. What I would really like to be able to do is "re-base" all of the existing branches on svn on this new 'silver' so that they are deltas of it instead of trunk. Then commits to the arch silver master would still be properly reflected at SourceForge and Google. But maybe this is a vane hope. And maybe the long term continued use of arch is in doubt anyway. To move forward, I think what we probably need to do is to replace the trunk at SourceForge with the current contents of 'silver' at SourceForge. I.e. compute the minimum delta from trunk to silver and then apply it to trunk. And then scrap all of the history related to 'silver' even though 'silver' actually has the more complete history. I think we *might* be able to do this via svnadmin at SourceForge... but I really need the help of someone more knowledgeable than me in order to avoid yet another disk space catastrophe. > I can reset the google repository to revision 0 if you'd like. > You may recall that more than this was necessary since the way the svk smerge mirror synchronization process works it seems to result in much greater disk space ussage then just 'svnadmin load'. So just reseting it to 0 may not be enough. We went around this problem several times before until you decided to use svnadmin. Regards, Bill Page. _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
