Andrew Sayers wrote: > Just to be clear, my understanding is that this project will take SBL > created by another program (that I'm writing) and create branches as > specified. If that seems like the right thing to do for the people involved (Florian and mentor, list consensus) and if that's easy. I'm happy as long as the default configuration works well with sane repositories. [...] > On 10/04/12 18:17, Jonathan Nieder wrote: >> How should the importer handle Subversion copy commands that >> refer to other projects in this case? > > This is a good point. I've just svnadmin and svnrdump, and it turns out > svnadmin doesn't allow you to dump a subtree while svnrdump strips out > the offending copy commands, so either way there's nothing to be done. >From a quick test, it looks like svnrdump converts a directory copy into the addition of its contents. Good. svndumpfilter produces svndumpfilter: E200003: Invalid copy source path '/branches/foo/subdir' and exits with status 1 so it seems like we're ok. [...] >> . tracing history past branch creation events, using the now-saved >> copyfrom information. > > I'm not sure if I understand correctly, but I think you're referring to > this edge case: Nope, I'm talking about the most typical and boring case there is: svn cp <repo>/trunk <repo>/branches/topic When cloning <repo>, it seems reasonable to expect that the ancestry of the trunk and branch would not be shown as disjoint linear histories, but that the revision in which the branch was introduced would be shown as a child of the previous revision of the trunk, like so: o --- o --- o [topic] / o --- o --- o --- o --- o --- o [trunk] This requires paying attention to copyfrom information. [...] > Right now I have a script that first takes an SVN dump and produces > gzipped JSON as output, then takes the gzipped JSON as input and > produces an SBL file as output. The first round will generally only > need to be run once (and is comparable to svn-fe in speed), whereas the > second round might need to be run an arbitrary number of times (but is > very fast). For what it's worth, for importing from repositories that use a nonstandard layout I do think this "start with a quick pass to figure the layout out" approach is a sane one. [...] > I'm currently focussing on bringing all the modules up to release > quality, so that I can have something for Florian to play with in the > near future. This should have an interface that is mature but flexible, > so I can change the interface to make his life easier but won't need to > change the interface because I missed something. After that, I'll > concentrate on improving the quality of the SBL output. Neat. Thanks for some useful clarifications. Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html