Bruno Cesar Ribas <ribas@xxxxxxxxxxxx> wrote: > I'm going to apply for the Git / Subversion Interoperability project. > > I saw that there is no mentor yet assigned for the "job". So i'm sending this > mail to get some help to start the project by submiting to GSOC and begin to > work :) I'll consider being a mentor for this project, but I know very little of the SVN protocol or how its server behaves. I also don't really have the time to learn those nitty-gritty details myself, nor do I have any burning desire to. > My idea on this project is to create: > 1. git-svnserver > 2. write a backend for Subversion These are two different approaches to the same problem. I think what was meant here was: > 1. git-svnserver Here we create a new program that can be invoked via SSH that runs the server-side of the SVN protocol. Or we create a CGI program that acts as the extended-WebDAV server for SVN. Sam Vilain (mugwump on #git) is suggesting using this approach as it probably will be easier to debug. > 2. write a backend for Subversion In this case we try to reuse the existing SVN server code by creating a library module that plugs into that system and uses a Git repository to store data, rather than say the existing bdb or fsfs stores. Git should be much faster than fsfs, use a lot less disk space, and be just as atomic. By using this approach you avoid the need to reimplement their network protocol. Which is a nice part of this approach. But the downside is you have to write code to run within their library and address space, and that conforms to their storage API. But either approach has a few key issues: - Assigning repository-wide revision numbers. Git doesn't have such a concept, but its key to SVN. These would need to be stored in a file so the server can quickly map from revision number to Git commit SHA-1. The reflogs may help here, but currently they also expire. Any reflog that is being used to do this mapping cannot be expired, ever. - Branches. In SVN these are in the repository wide namespace, but in Git they aren't. I imagine we'd want to just enforce the standard layout that the SVN people recommened: /trunk/ --> refs/heads/master /branches/ --> refs/heads/ (minus master) /tags/ --> refs/tags/ That's all I can think of right now. But I'm sure there are more. > And make it easy to work with SSH using those "common" flags in > authorized_keys like: > command="svnserve -t -r /home/svn --tunnel-user=bruno" ssh-dss bla bla Not following you... > And as an idea i would like to make the same funcionality to git, as it is > not as easy today to do something like above :) Again, not following you... -- Shawn. - 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