Any plans/needs to extend the fast-import format?

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


...

> Even considering renames without their interaction with
> delete/add/modify/copy, things are ugly. Consider ...
> 
> R b c
> R a b
> 
> Put those in the opposite order and you have a problem.

And, of course, the supreme edge case:
R a b
R b a

Which can't actually be represented in incremental fashion without an
intermediate step.

> 
> Keep in mind that Bazaar treats directories as first-class objects (they
> can exist without files within them) and tracks history across renames
> by using file-ids (like inodes) under the covers. The net effect is that
> Bazaar repositories tend to have a larger number of renames than in many
> other systems. I therefore get plenty of bugs reported about bzr
> fast-export not doing the right thing in terms of producing something
> git fast-import wants.
> 
> Basically, the current processing rules are a nightmare the moment
> renames and copies are involved. I just happen to see it more than most!
> Nevertheless, the sad reality is that *every* tool generating a
> fast-import stream with renames or copies needs to be mega careful about
> ordering FileCommands currently. I'm still yet to find a set of rules
> for doing that ordering that always works. :-( Life would be *so* much
> simplier for me, and every other fast-export developer, if the semantics
> were 'vs last commit' as opposed to 'incremental'. The code in bzr
> fast-import would half in complexity as well.
> 
> Ian C.
> 
> 


I'm pretty sure that TreeTransform splits renames into add + delete
pairs, then sorts by depth, and applies things as
 delete
then
 add

I don't know if that helps you here or not.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqUxy4ACgkQJdeBCYSNAAM5JgCbBUUUlGSJnVJIUi2fkgaPYWzY
fjoAn2/du0VMM4i0i247R8XxzbwUFnX/
=JV+L
-----END PGP SIGNATURE-----