Re: [SoC RFC] libsvn-fs-git: A git backend for the subversion filesystem

From: Julian Phillips <julian@quantumfyre.co.uk>
Date: Mar 20, 2008, 09:22 UTC
Message-ID: <Pine.LNX.4.64.0803200910410.21580@reaper.quantumfyre.co.uk>
In-Reply-To: <20080320045632.GB8410@spearce.org>

On Thu, 20 Mar 2008, Shawn O. Pearce wrote:

Show 11 quoted lines

> Bryan Donlan <bdonlan@gmail.com> wrote:
>> I'm planning to apply for the git summer of code project. My proposal
>> is based on the project idea of a subversion gateway for git,
>> implemented with a new subversion filesystem layer. A draft of my
>> proposal follows; I'd appreciate any comments/questions on it before
>> the application period proper begins.
>
> Very cool.  Have you had a chance to look at the prototype python
> implementation of an SVN server that Julian Phillips started?
>
>  http://git.q42.co.uk/w/git_svn_server.git

(now with partial support for 'svn log' ... ;))

Show 12 quoted lines

>> /props/{trunk/,branches/,tags/} - file properties; props on directories will be
>>   represented with a reserved filename (._GIT-SVN-DIRPROPS perhaps)
>>   copyfrom information might be in /props, or in a seperate tree
>
> How critical are file properties to an SVN client for proper
> functioning?  Given the challenges already in front of you for this
> project I would almost encourage you to avoid dealing with file
> level properties.  Its hard enough to make something that speaks SVN
> on the wire but reads/writes Git on disk, not to mention you have
> to somehow "flatten" the Git DAG down into a sequential revision
> namespace to make the SVN clients happy.  So deferring property
> support until later may be wise.

You might need to get svn:eol-style working to prevent the svn client from munging any binary files? Can't think of any other vital properties atm.

Show 5 quoted lines

>> /revprops/NNN - revision properties for the given revision number
>
> Ditto.  Aside from the special merge properties you mentioned,
> I wonder if you can simply avoid implementing support for these
> early on.

Since you have to explicitly enable revprop editing in the subversion repository by enabling a hook script, I should think that this was definately something that could be left at the bottom of the TODO list ...

Though you do need to be able to convert commit info into the appropriate revprops (e.g. commit msg -> svn:log revprop)

-- 
Julian

  ---
Often statistics are used as a drunken man uses lampposts -- for support
rather than illumination.