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

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Eric Wong
Johannes Schindelin <[hidden email]> wrote:
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

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

Johannes Schindelin
Hi,

On Sun, 3 Aug 2008, Eric Wong wrote:

> Johannes Schindelin <[hidden email]> 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.

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

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.

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).

Ciao,
Dscho

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

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

Eric Wong
Johannes Schindelin <[hidden email]> wrote:

> Hi,
>
> On Sun, 3 Aug 2008, Eric Wong wrote:
>
> > Johannes Schindelin <[hidden email]> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html