Refering to Jonathan's concerns in Saturday night's IRC log:
> [22:59:34] <jrnieder> barrbrain, flyingflo: I'm worried about the remote
> [23:00:05] <jrnieder> someone needs to review remote-svn.c to catch things
like that refspec issue which should be straightforward to an experienced eye
Let me explain the refspec issue:
In the the exisiting code in contrib/svn-fe commits are always imported to
refs/heads/master, that was hardcoded. So I thought that couldn't be it.
I made the name of the branch to import variable, depending on the name of
But my remote-helper didn't advertise the refspec capability, so transport-
helper assumed it imports to refs/heads/master, which is the default import
refspec. The subsequent update of references in store_updated_refs lead to
wrong values after the fetch, which I considered a bug and tried to fix.
In fact I didn't realize that the actual updating of references is not done by
the remote-helper. I thought the remote-helper would have to evaluate the
fetch refspec and tell fast-import the correct target branch.
Furthermore I confused 'private namespace' with refs/remotes/<remote's name>/,
which I considered somehow private too.
After several mailing iterations, showing me that I was wrong, I found what
the right point is, namely that the remote helper writes references to a
really private dir in refs/<remote name>/, it doesn't touch anything else, and
by advertising the 'refspec' capability, git-fetch knows where the private
refs are and updates non-private references according to the fetch refspec in
some post-processing in store_updated_refs. (Ok, you will say "of course!",
but I didn't know that I was wrong and it's hidden in some 1000 lines of
For me that was not very easy to figure out, and it took a lot of time, but I
think now remote-svn does it right.
> [23:00:38] <jrnieder> (also, remote-svn.c should be at the toplevel so it
can be tested more easily with tests in t/
> [23:01:10] <jrnieder> and it should not be named remote-svn, since we
haven't pinned down details about the svn:: conversion yet. That's why
Dmitry's was called git-remote-svn-alpha)
Ok. Why is that important? I think if it's not called remote-svn git doesn't
find it as a helper for the 'svn' protocol. Actually in my local git tree, I
have a symlink in the toplevel (to simpify PATH).
> [23:01:45] <jrnieder> I'm happy to review patches but I don't have a lot of
time for it, which has been a problem:
> [23:02:11] <jrnieder> * I think I wasn't cc-ed on earlier discussion so
they seem to come out of the blue. That's fine, but
> [23:03:05] <jrnieder> * I really rely on patches that do one logical thing
with a commit message describing the context and what the patch is trying to
accomplish. That makes review way, way easier when it is happening.
Probably I should stop sending proposals or incomplete stuff to the list/you.
The current state may probably be viewed easier in my github repo.
I think for creating patches that are acceptable I will need to squash and
split a lot of my development commits after the code is somehow finished and
no longer experimental.
> [23:04:42] <jrnieder> Also it seems very chaotic: there are basic things
about remote-svn.c that need fixing, and then patches for other things are
appearing on top of that.
> [23:04:49] <jrnieder> Help?
> [23:05:26] <jrnieder> thanks, and hope that helps
About the current state:
I wrote a small simulation script in python that mimics svnrdumps behaviour by
replaying an existing svn dump file from a start rev up to an end rev to test
incremental imports. I use it together with a little testrepo shell script.
Will need to bring that into t/ later, after figuring out how the test
framework works. As it's not finished it's not published.
By reading the latest svn revision number from a note attached to the private
master ref, it starts future imports from the next svn revision. That
basically works well.
It doesn't reuse mark files. What's the point of reusing them? Dmitry's svn-
alpha did that.
All I need to know is the revision to start from and the branch i want to add
commits to, right? It now simply reads that from the note.
This got stuck on another problem:
Incremental update of the note tree doesn't work. fast-import refuses to
update the notes tree: '<newsha1> doesn't contain <oldsha1>'.
I don't yet know what's the reason for this.
I'm digging into the internals of notes to find out why..
(no problem with the file tree).
This state hasn't hit the list of course, as it's in no way useful nor
I often get caught in the traingle of those three processes (git transport-
helper, fast-import, remote-svn) needing to understand a lot about the
existing two to understand why things don't work and why they need to work
like they do.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html