Bryan Donlan wrote: > Here are some tentative milestones: > * Read-only access from SVN to the master branch (no trunk/ etc layout) > = Conversion of git commit information into svn revprops > = git mode/.gitignore -> svn property conversion here? This seems like a large milestone. Can you break this up any more? For instance, your design notes on storing the necessary mapping information are good. How about a separate milestone of having a test suite for the library functions you make for accessing that information. I would be tempted to check the protocol - http://svn.collab.net/repos/svn/trunk/subversion/libsvn_ra_svn/protocol - and make milestones for each request type that the protocol allows for. Perhaps there is a more relevant list that you can find, such as groups of tests in the back-end test suite that ships with Subversion. Even taking the list of svn sub-commands, and deciding which fit into each category would be a good enhancement. > * Read-write access from SVN to the master branch > = Map svn usernames to git full name/email according to a configuration map > - how should git commits with names unknown to svn be handled? Just pass > them through, spaces and <@> as well? Meh. Just ignore them, and set revprops with all of the git committer information. > = Bidirectional svn:execute and svn:ignore conversion. > = Copyfrom and file property information needs to be recorded > = Test importing a largish repository (without converting merge information) > to git (the svn toplevel stuff would be left as-is in the git tree) > = Consider developing git-svn-fs on a git-svn-fs repository itself for > testing purposes An honourable notion, but I'd steer away from worrying about self-hosting, if it is irrelevant to the task at hand. Focus more on a finding a good test suite to check you supported all the operations. Eg, can the test suite bundled with the Subversion project run against your back-end? > * Standard toplevel SVN layout (trunk/ tags/ branches/) > = SVN branch creation might come a bit later > = Test importing a largish repository with tags and branches carried across > (might not efficiently support copy-from information) > * Merge information annotation (git->svn) > = Try to guess the copy source for a new tag or branch - and for merges I don't like this word "guess". It might be dangerous to not deterministically or repeatably answer a request. If any random decisions were made, or information derived based on things that might change, then it should be stored in your mapping information branch. In this instance, we didn't 'guess', we decided. > * Merge information annotation (svn->git) > * Import of a largish repository with svk or similar merge information into git, > and vice versa (eg, exporting git.git with merge tracking as a subversion > repo) Whew! That's a lot of big milestones, but it's your summer ... :) I think the merging thing is a nice-to-have, and doing it would just prove that you can use the metadata that you have collected well. One thing I like about your approach is that the tracking branch itself could be replicated, leaving an audit of what happened. > === Interfaces === > > As mentioned before, this driver will plug into the existing subversion stack > as a filesystem driver. This immediately allows access using any of subversion's > access methods (direct filesystem access, mod_dav_svn, svnserve). > > On the git side I intend to use libgit for all git repository access. If I find > it lacking a necessary feature, I will attempt to add the missing interfaces > to libgit if at all feasable. AFAIK the interface for libgit is not yet finalized, so bear in mind the application will possibly need porting work for each release. Sam. -- 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
