On Thu, 22 Mar 2007, Shawn O. Pearce wrote:
Bruno Cesar Ribas <ribas@xxxxxxxxxxxx> 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?
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?
- 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
-
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