On 11/04/12 20:53, Jonathan Nieder wrote: > [...] >> Additionally the remote-helper will read a configuration file containing >> additional information about branch-mapping, this should be closely related to >> Andrew's SBL. > > That sounds reasonable to me. I am somewhat unconvinced (but > convinceable) about the need to use a configuration scheme that > handles all the edge cases right away. Shouldn't it be enough to tell > the importer the following? > > - the path to the repository (from which it can deduce $SVNROOT > and the path within there to the subproject of interest) > > - a single bit of information on top of that: "this repository uses > the standard layout" > > Once that works, the tools could easily be tweaked to respect a > configuration file that describes more complex situations, and as a > bonus the SBL tools for making sense of those situations would have > time to become more mature in the meantime. SBL itself is just a plain text description of which directories are branches etc. - there are a handful of tricky bits on Florian's side of the fence, but it shouldn't be that hard to add everything necessary to parse any arbitrary SBL file. For example, if he gets an SBL action that looks like this: In r105, create branch "/foo" as "foo-bar" from "/bar/baz" r25 ... then the logic that produced that line doesn't really matter, so long as he can convert it to a series of fast-import commands. I started work on exporting branches from SVN a few months ago, and happened to be polishing off SBL when GSoC got going, so my work ties nicely into Florian's. I've been keen to talk about edge cases lately because that's the point I'm at in my work - to make a long story short, I know how to do the easy cases now, and need to veer off into some weird edge cases for a month or two, before swinging back by the standard layout and optimising for that. If Florian needs something that generates SBL before I'm ready, I'd be happy to cobble a basic "standard layout only" script from the modules I've got. - Andrew -- 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