Re: Git / Subversion Interoperability

["Shawn O. Pearce" <spearce@spearce.org>]

Bruno Cesar Ribas <ribas@c3sl.ufpr.br> 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.