Re: [RFC/PATCH 0/3] fast-import: give importers access to the object store

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Sep 5, 2010, 06:08 UTC
Message-ID: <20100905060854.GA15511@kytes>
In-Reply-To: <20100905031528.GA2344@burratino>

Hi Jonathan,

Jonathan Nieder writes:

Show 8 quoted lines

> To recap, because fast-import does not write a pack index until the
> checkpoint, frontends cannot necessarily read back what they have
> written immediately.  The obvious application to allowing that is as a
> sanity check, but more important to us is that it allows the lazy
> frontend to forget previous revisions even if they are required for
> later "file/directory copy" operations in the import.  The frontend
> can be secure in the knowledge that the backend remembers everything
> now.

Excellent timing! I finished writing tests for the svndiff0 applier and started modifying svn-fe to use it. I've applied your patches and rebased my work on top of it.

Show 7 quoted lines

> I suspect that these patches are not in their final form.
> In particular, the interface is kind of klunky: to name a
> blob by path, you have to supply a *tree* which contains that
> blob as well as the pathname.  So retrieving, say,
> v1.7.1:Documentation/git-fast-import.txt, would require
> three round-trips: one to dereference the tag, one to dereference
> the commit, and then one to finally retrieve the blob.

Ideally, we'd like to be able to supply a commit and a pathname. I'll look into the difficulties in implementing this interface.

> Another possible concern is that this is very much git specific.
> Other fast-import backends are just not going to be able to do
> it with the same format.  Is there a convention for naming
> options like that?

Why is this a concern? We aren't even breaking backward compatibility. This bidi interface should only be used by SVN-like frontends.

> Still, I hope it is useful to start with.  Thoughts?  Ideas?
> Improvements?

We'll get ideas to improve this as svn-fe gets built up. On a related note, we should probably extend the git-remote-testgit helper to use this feature in future to facilitate writing unittests.

Thanks.

-- Ram