Re: git-svn and svn:externals, was Re: Hackontest ideas?

From: Eric Wong <normalperson@yhbt.net>
Date: Aug 3, 2008, 22:48 UTC
Message-ID: <20080803224852.GC3006@untitled>
In-Reply-To: <alpine.DEB.1.00.0807291354130.4631@eeepc-johanness>

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 8 quoted lines

> Hi,
> 
> On Tue, 29 Jul 2008, Jakub Narebski wrote:
> 
> >  * handling of svn:externals using submodules
> 
> I doubt that this is easy.  Otherwise, Eric would have done it a long time 
> ago.

I started working on externals support a long time ago, but got hung up on corner-cases (with .gitmodules and .gitignore being in the tree) and backward-compatibility issues with commiting back to SVN.

The more I think about it, the more I think the worse-is-better approach I used for "git svn show-ignore" is the way to go (using the unversioned .git/info/exclude). That would mean ignoring submodules as implemented by git and just shotgunning another git-svn-created subdirectory into where the external would've been...

> The main concern I have is to get the semantics right: AFAICT 
> svn:externals has _no notion_ of "what is current".  It just _always_ 
> fetches the HEAD.  Even if you check out an ancient revision in the 
> "superproject".

Based on my limited understanding, peg revisions are only needed in SVN because of the cost of traversing history to DTRT. git-svn should be able to just use the -r<rev> syntax that has always been supported without needing peg revisions. On the other hand, implicit rename/copy detection in git may not pick up drastic changes...

-- 
Eric Wong