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

Johannes Schindelin [off-list ref] wrote:

Hi,

On Sun, 3 Aug 2008, Eric Wong wrote:

quoted

Johannes Schindelin [off-list ref] wrote:

quoted

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