Re: GSOC remote-svn

[Florian Achleitner <florian.achleitner2.6.31@gmail.com>]

On Sunday 22 July 2012 16:43:33 Jonathan Nieder wrote:
> Hi,
> 
> Florian Achleitner wrote:
> > 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.
> 
> Right, that's fine.  And you did a fine job of navigating the existing
> documentation (which could be improved, hint hint).
> 
> What I am more concerned about is that you had code you sent a while
> ago for review, that this would have been obvious to David, Ram,
> Dmitry, or me if we had seen it, and yet none of us gave you that
> help.  We are failing at _our_ job of giving you prompt advice and
> instead you have had to work on your own.
> 
> Isn't it likely that there are multiple other bugs like that which
> still haven't been fixed?
> 
> That's why I think we need to get into a habit of giving and getting
> feedback quickly and incrementally improving work.  Soon, before the
> summer ends.
> 
> [...]
> 
> >> [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 fid it as a helper for the 'svn' protocol.
> 
> It finds it as a helper for the 'svn-alpha' protocol instead.
> 
> The point is that when I perform the following steps:
> 
> 	git clone svn://path/to/remote/repo
> 
> 	... wait a day, update git
> 
> 	cd repo
> 	git pull
> 
> nobody would expect the result to be a non-fast-forward update caused
> by the details of svn-to-git conversion changing.  Using a name like
> testsvn or svn-alpha would help in managing expectations --- the
> remote helper is meant for experimentation for now and not meant to be
> something people can rely on for collaboration.

Ok, that makes sense. Renaming is easily done!

> 
> > 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.
> 
> Sounds neat --- how can one try it out?

I'll send a patch ...

> 
> > Incremental import:
> > 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.
> 
> The marks are used to handle copyfrom operations referring to older
> revisions.  Are you sure you want to abandon them?  Can you explain a
> little more about your plan?

Ok, that makes sense. I didn't need the marks for incremental import. But to 
evaluate the copyfrom props we need some revision->sha1 mapping.
I just added the options to save and import marks to fast-import's command 
line. 
If the file is missing, it will need to be generated from the notes, or the 
whole history will be reimported.

But when I fetch from a git repo that imported from svn, the notes are not 
fetched automatically. In this case I currently loose marks and notes.
What can I do?

Florian