Hi On Sat, Apr 9, 2011 at 4:31 AM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > > At the moment I am more concerned with what its guts will look like > than what features it will support. A feature list is just a way to > advertise how good the guts are. ;-) My current view is following: Use svnrdump stream to track / in say svnroot branch. It'll be linear (1), commits will include actual diffs, and some revprops translated to their git counterparts like svn:log,svn:author,svn:date (2). And it'll be a bridge for svn interaction. In git-notes tree store sha1 -> svn rev mapping(3), and also for each svn rev store all it's revprops. Store and maintain /path branches - there we have some freedom of choosing git parents. That's all about fetch. Obviously svnrdump will be used to push fast-forward linear history back to svnroot, or to a /path branch which goes the same way in fast-forward case. And to be somewhat usable we want to be able to rebase-push/dcommit (if there is a dense stream of svn commits going, we don't want the user to type git rebase, git push and fail until he gets a lucky timing). Merges need more thinking, and may be not that necessary for a start. Path ignores, or even revision ignores should be possible to implement in the code, but just an emergency tools for a user (sometimes people (by mistake) commit something enormous or incompatible with filesystems names or like, so that user considers it ok to trash this out of his history), also there could be a need for permanent path filter (like track /projX, not /bin) - just the same, be ready that sometime it'll have to be implemented. [skipped some of svn commit "races" and merge tricks] >> -- if it was, create a svn branch of our parent, commit there, and >> then create a merge commit of these two, commit it and get same merge >> history back > > Yikes. I don't think typical projects would like the resulting > history. Will make them mad, but in some cases it should be ok, if we are pushing a lengthy topic branch they'll sometimes prefer to see it as one commit. > Yes, this is an interesting question. Given a history like this (time > flowing left to right): > > E --- F --- G > / \ > A --- B --- C -- D -- H > > where A is the latest rev of trunk/, how do we push this history to > svn? Where is the name of the side branch recorded in the git > history? Could be either autogenerated with some user pattern, like /branches/user/tmpXX, or specified explicitly in git-notes or somewhere, or maybe we have already pushed a placeholder branch to svn and will commit there. > > On answer is that it's possible to learn the historical branch name by > parsing the commit message for "H". Yuck. > > I'd put off pushing merges to start. It's definitely not in the minimal plan. > I think the cleanest solution is often to reject a push if it is not > obvious how to represent it remotely, just as though the remote server > had a hook that rejected it. Makes sense, after all plain svn users want to see svn-like history, because they still use svn. (1) In theory we could track whole svnroot merges (from svnroot2 on the same repo for example, or hypothetical merge from another repo) but that's hardly used by anyone. (2) The hardest thing is to decide which ones to store in git. Translating more gives a better look and feel, translating less reduces the chances to get the same git objects on another clone. And what should git do if this data changes is not a trivial choice too. (3) And a funny thing is could happen that there are path1@rev1 path2@rev2 that produce the same sha1. That's perfectly fine because they are just refs, care should be taken when choosing a path to commit to though. Also svn will distinguish them, but it's just a corner case. -- 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