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

From: Eric Wong <normalperson@yhbt.net>
Date: Aug 3, 2008, 23:36 UTC
Message-ID: <20080803233619.GC5435@hand.yhbt.net>
In-Reply-To: <alpine.DEB.1.00.0808040113150.9611@pacific.mpi-cbg.de.mpi-cbg.de>

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

Show 17 quoted lines

> Hi,
> 
> On Sun, 3 Aug 2008, Eric Wong wrote:
> 
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > > 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.
> 
> I was talking about the svn -> git direction.

Likewise.

> And Git does not peg revisions because of the cost of traversing history 
> to DTRT.

I was saying SVN uses peg revisions because of the cost. Also, there may be a misunderstanding as to what peg revisions are (in SVN) and how they relate to git.

Here's an example svn:external definition with a peg revision:

  -r 1234 http://foo/bar.c@5233

"@5233" is the peg revision, and (as I understand it, just a hint) and "-r 1234" is the actual revision we want from SVN (and what git-svn should fetch). Confusing? Yes.

> Git pegs revisions of submodules, because it is the right thing to do.  
> Subversion just got it wrong to begin with.  After all, we are going 
> through a lot to make defined revisions, and we do not want to throw that 
> out by allowing an unversioned submodule.

Yes, most repositories I've seen don't even use "-r 1234" (which has always been supported by SVN). This is the problem git will have to deal with.

> So, importing a svn:external with git-svn has to undo that error somehow 
> (which might be helped by the linearity of subversion, but might be tricky 
> because of possible clock skews between the two subversion repositories).

Yes. This is why I'm leaning towards /not/ using git submodules for this because svn:externals are rarely defined with -r <revno>.

-- 
Eric Wong