Converting big files

[Benjamin Pollack]

On Apr 11, 2010, at 4:32 PM, Greg Ward wrote:

> Idea #2: implement something separate from 'hg convert'
>  2a: new command implemented by bfiles extension (bfconvert?)
>  2b: new extension entirely
>  2c: new standalone script
> pro:
>  - unaffected by API changes in hgext.convert (albeit still subject
> to the whims of hg's and bfiles' APIs)
> con:
>  - risk of reinventing wheels that already exist in hgext.convert
>  - might only work for hg -> hg conversions
> 
> Am I missing any pros or cons for these two ideas?  Or is there
> another way to implement this that I have not thought of?  Other
> thoughts, opinions, ideas?


One thing in this particular case is that there's no reason why you shouldn't be able to losslessly round-trip from Mercurial to bfiles and back and end up with an identical repository.  The only thing the bfiles converter does is change where (some of) the actual file bits are stored; everything else stays the same.  This means that I'd like a system where it's theoretically possible to run a not-yet-written "hg bfunconvert" command after "hg bfconvert" and end up with the original repository.  Extending the convert machinery, for the reasons Dirkjan points out, would make that impossible, whereas a custom solution would make it easy.  While we could modify the convert extension for this use case, that reëmphasizes the weakness of extending convert in the first place: extending an extension is brittle.

--Benjamin