Re: Git / Subversion Interoperability
- From
Julian Phillips <julian@quantumfyre.co.uk>
- Date
- Mar 23, 2007, 01:03 UTC
- Message-ID
- <Pine.LNX.4.64.0703230052570.2746@beast.quantumfyre.co.uk>
- In-Reply-To
- <20070323004335.GA17773@spearce.org>
On Thu, 22 Mar 2007, Shawn O. Pearce wrote:
Show 13 quoted lines
> Bruno Cesar Ribas <ribas@c3sl.ufpr.br> wrote: >> 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.
This might run headlong into some of the issues facing the libification project - in particular the tendancy of git code to die as a primary error handling mechanism. This approach may not viable without access to a libified git?
Show 8 quoted lines
> 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.
You could probably do something similar to the system used by git-svnimport to record the Subversion revision to git SHA1 mapping - perhaps with a hook script to update?
Show 8 quoted lines
> > - 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 would probably be good enough for the majority of one-project-per-repo Subversion projects at least. Though there is still the issue that Subversion will actually let you create a "tag" simply by committing whatever you currently have in your working copy (including localally modified files ... yeuch).
> > That's all I can think of right now. But I'm sure there are more.
Properties are probably the next biggest headache. Subversion allows you to associate arbitrary keyword value pairs with files (which are versioned) and with revisions (which are not versioned). You would need to find someway to support this in git. Since revision properties are disabled by default in Subversion you may be able to simply disallow them permanently - but I don't know anything about the Subversion protocol ...
-- Julian --- Practical politics consists in ignoring facts. -- Henry Adams