Hi Jonathan, Jonathan Nieder writes: > Ramkumar Ramachandra wrote: > > > Also, since we're aiming for a two-way mapping, it's going to be > > significantly more challenging: we will need a mapping function that > > can be inverted perfectly. > > Sounds interesting! Let's see how much I can narrow scope/dash hopes. > :) > > First of dreams is the possibility of using git as a replacement for > svnsync, to get semantically identical SVN repositories like so: > > [...] > > SVN repository 1 -> dumpfile -> Git repository > > Git repository -> dumpfile' -> SVN repository 2 > > in a way that svn tools can look at repo 2 as a basically perfect > replacement for repo 1. This means copying svnsync properties, > rename tracking info, svn properties, etc. > > I. Some people might want that, and I wouldn't want to stop them > trying (maybe using notes, perhaps even the mythical tree-based > form) but I'm not interested in it at all. Is it a goal for you? Hm. I didn't imagine that it would be *that* difficult. The challenge is to design an invertible mapping function by encapsulating incompatibilities (or inconsistencies) bit-by-bit using hacks like notes for the additional information. I'll think about this a little more and get back to it in a few days. > Second would be the possibility of using an SVN repository as a > conduit for communication between git repositories: > > Git repository 1 -> fast-export stream -> SVN repository > SVN repository -> dumpfile -> Git repository 2 Interesting, but I don't necessarily see why this is useful. > II. It would be super cool to be able to transport arbitrary git > objects via svn (maybe using custom properties and fabricated > temporary branches named after the first commit after a fork > point). Perhaps some people could host git projects on Google > Code this way. Is that a goal? > > Git 1 -> SVN 1 -> Git 2 -> SVN 2 -> Git 3 Wow. That IS super-cool, but I'd have to stretch my imagination quite a bit to find a usecase for this. I actually find this inelegant (and probably even grotesque) on many levels, so no- absolutely not interested in this. > III. Perhaps only the subset of git objects with certain properties > should be considered safe to transport via an SVN repository > (e.g.: > > - author matches committer > - timestamps are New York time > - author address is of the format username <username> > - filenames are valid UTF-8 > > ). And maybe any existing git repository can be painlessly > transformed to consist only of such commits. Is that a model > to strive for? > > SVN 1 -> Git 1 -> SVN 2 -> Git 2 -> SVN 3 Dunno, and I don't like this. > IV. Maybe only some svn changes would be considered safe to > transport via git: no weird properties, no tracked renames > not involved in branches/merges, all branches named after the > git commit id of the first rev after the fork point, ... > And maybe any existing svn repository can be painlessly > transformed to consist only of such revisions. Is that a goal? Again, no usecase. I'm not looking for making SVN do Git wizardry- there's always Git for that. SVN is a simple book-keeping system, and I want to keep it that way. > (As you might have guessed, my answers are "no, no, no, and no, at > least at first, but it is fun to imagine how a person would go about > achieving these things anyway"). Let me guess: you're targeting git-svn like functionality with all the dcommit/ rebase ugliness? I'm looking for a slightly nicer way, not too much more; (I) is just a sort of "ideal" target- it's just nice to think about it that way. It's needn't be entirely realistic. -- Ram -- 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