Re: Tracking and committing back to Subversion?

From: Eric Wong <normalperson@yhbt.net>
Date: Feb 4, 2006, 05:40 UTC
Message-ID: <20060204054056.GB24314@Muzzle>
In-Reply-To: <1138834301.21899.40.camel@wilber.wgtn.cat-it.co.nz>

Sam Vilain <sam@vilain.net> wrote:

> Hi all,
> 
> Has anyone done any work on bidirectional access to SVN repositories?
> ie, tracking and committing.

AFAIK, Not yet. But it's something that's been on the back of my mind for a while. I've attempted similar things with Arch <-> SVN in the past but didn't get anything extremely robust going from Arch -> SVN although I'm pretty satisfied with my SVN -> Arch product (svn-arch-mirror).

> That would be porcelain that behaves like SVK (http://svk.elixus.org)
> 
> Ideally it would probably need to link against the Subversion RA (remote
> access) library, neon.

I prefer to use git-svnimport for pulling from svn since it's pretty good at what it does. That already depends on SVN::Core and SVN::Ra. SVK is really nice tool, just a bit slow after I've been using git for a while.

Show 7 quoted lines

> I can see forsee two potential issues;
> 
>   1. file properties - such as mime type, ignores and custom properties.
>      Linus, when I asked you about this in Dunedin, you mentioned that
>      there is a place at the end of the directory entry where this could
>      fit without breaking backwards compatibility.  Perhaps this could
>      be an optional pointer to another directory node;

Mostly ignore-able, imho. svn:executable is the one that makes the most sense (and is easiest) to support.

svn:ignore <-> .gitignore mapping are pretty close (identical, save for recursive properties that svn gets very wrong. I don't think svn:ignore is affected by line order, whereas .gitignore is a plain file and line order does matter.

svn:external is almost definitely better off ignored entirely when interfacing with other RCSes

svn:keywords: I don't think there's a way to disable this like there is with CVS, is there? keywords are evil imho.

I don't use or know much about the other properties...

Show 10 quoted lines

>   2. "forensic" file movement history - as opposed to the uncached,
>      (and unversioned), automatic "analytical" file movement history.
> 
>      It would be easy for a tool to provide 100% interface compatibility
>      with SVN client/SVK using properties, but properties that hang off
>      the head rather than the file itself (so that they don't stuff up
>      the ability to merge identical trees reached via independent
>      paths).  SVN calls these "revision properties".  If a good
>      convention is adopted for this, it could be used as a nice way to
>      supplement git's automatic analysis of the revision history.

Just parsing the output of diff-tree -C and marking them in SVN as copies/renames should be sufficient for letting SVN do its thing.

Doing this kind of file movement history on the git side sounds like overkill to me. I was a _huge_ fan of logical file-identities in GNU Arch in the past, but the complexity destroyed it from both a UI and performance perspective.

-- 
Eric Wong