Re: [PATCH] Support wholesale directory renames in fast-import

["David Frech" <david@nimblemachines.com>]

Hmm. I think Uwe is right. Copy is probably the "right" primitive, and
rename can always be synthesized from copy+delete.

Since Subversion is built around the idea of "cheap copies" there is
no incentive for them to represent renames other than as "copy, then
delete".

But isn't the same true in a way of git? If I copy a directory (a
tree), then the new tree is the same tree - it has the same SHA-1
hash, so I can simply refer to the existing object. Same for file
blobs.

Subversion dump files have *lots* of copies. Might be nice to be able
to feed these directly into fast-import and have it DTRT, esp if it
was smart about sharing identical data structures.

- David

On 7/10/07, Shawn O. Pearce <spearce@spearce.org> wrote:
> Uwe Kleine-K??nig <ukleinek@informatik.uni-freiburg.de> wrote:
> > David Frech wrote:
> > > Now my challenge is that the svn dump doesn't *actually* say "rename
> > > a/ to b/"; it says "copy a/ to b/; delete a/", so I have to infer the
> > > rename.
> >
> > I don't know fast-import very well, but why not doing exactly what the
> > dump file suggests:  copy a b; delete a ?
>
> Because there is no copy operator in fast-import.  So you cannot
> do "copy a b".  Apparently that's what I should have implemented,
> as rename in Git really is as simple as the copy/delete pair.  Ugh.
>
> Copy isn't really that hard, it just can't be nearly as efficient as
> rename, as copying a subtree will force me to either duplicate data
> in memory or reload trees from disk to duplicate data in memory.
> But its a copy, so data duplication is expected.  ;-)
>
> I'll implement a copy opertor soon.  Shouldn't be too difficult.
> Maybe someone else would like to take a shot at implementing it...
>
> --
> Shawn.
>


-- 
If I have not seen farther, it is because I have stood in the
footsteps of giants.