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@xxxxxxxxxxx> wrote:
Uwe Kleine-K??nig <ukleinek@xxxxxxxxxxxxxxxxxxxxxxxxxx> 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
