Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > Hi, > > On Sun, 3 Aug 2008, Eric Wong wrote: > > > Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
