The separate Hg repositories could go into separate sub-project branches if that is more convenient for bringing them over. My sense is that once they are in Subversion, it is relatively easy to massage them or consolidate into a composite project tree (by SVN copying) that is where any further adaptation and use occurs - I am assuming there are no collisions between Hg subprojects.
I think the bigger issue is preserving the Hg history and the different revisions. Is there any agreement on how deeply we need history, is the full history essential for provenance reasons? - Dennis PS: I wonder, was there history lost as part of the past move to Hg? I had the sense it was preserved, but am now unsure. -----Original Message----- From: Greg Stein [mailto:[email protected]] Sent: Thursday, June 23, 2011 12:18 To: [email protected] Subject: Re: An svn question On Thu, Jun 23, 2011 at 14:02, Pedro F. Giffuni <[email protected]> wrote: > Disclaimer: I am no SVN expert but I play a lot with > FreeBSD's SVN repository. > > --- On Thu, 6/23/11, Mathias Bauer <[email protected]> wrote: > >> Hi, >> >> I'm no svn expert, but I hope to find some here. >> >> We still have a lot of work in so called child workspaces >> (in Mercurial they are just an own repository that >> originates from the "main" repository). > > In subversion those are "branches", so you create a branch > everytime there is a release or if you want to create a > your own custom project with experimental changes that will > be merged later on. Yup. Here is how the Subversion project itself uses branches: http://subversion.apache.org/docs/community-guide/general.html#branch-policy Regarding the existing CWSs, those repositories "should be" imported as branches here at the ASF. I'm not entirely sure how to gather up a bunch of Hg repositories and blend them into a single repository, but that would be best. We can then convert that single Hg repository to Subversion and load the sucker onto svn.apache.org. Cheers, -g
