Bryan Donlan wrote:

quoted text
> 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.

quoted text
> * 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.

quoted text
>   = 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?

quoted text
> * 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.

quoted text
> * 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.

quoted text
> === 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html