From: Sam Vilain <sam@vilain.net>
Date: Wed, 01 Feb 2006 22:51:40 GMT
Subject: Tracking and committing back to Subversion?
Message-ID: <1138834301.21899.40.camel@wilber.wgtn.cat-it.co.nz>

Hi all,

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

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 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;

     /
      trunk/       # after all, we're tracking an SVN repo ;)
        MyModule/
          Makefile.PL
          MyModule.pm
          <prop-dir>/
            svn:ignore

     <prop-dir> is a directory object, with one file in this example;
     called svn:ignore.  The contents of this file would be something
     like the .gitignore;

          Makefile
          Makefile.old
          blib
          ...etc...

     This configures the directory "/trunk/MyModule" to have a property
     "svn:ignore", which makes SVN ignore those files.

  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.

     So, then, git could support these three methods of finding
     revision history;

        1. automatic/analytical, as at present.  Cachable information,
           and such a cache would not form part of the revision history.

        2. forensic, if using porcelain that supports it; this would
           form part of the revision history, but be out of band to the
           content.

        3. (potentially) retrospective, for instance, somebody studying
           an old code base and tracking history for some reason - or
           even 'correcting' forensic revision history that is causing
           their advanced patch calculus algorithm to trip up (should
           someone be using git as a storage back-end for darcs, for
           instance)

     Ideally, it would be possible to distinguish between 2 and 3, of
     course this would require two head identifiers; the content head,
     and the revision history head.

This might seem like functionality not needed for merging kernel
trees ;) but I think it would add value to be able to make git truly
join the trump suit in the VCS deck (along with SVK, which can, for
instance, track Perforce and even git repositories).

Sam.