On Sunday 22 July 2012 16:43:33 Jonathan Nieder wrote:
> 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
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?
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