bfiles: ready for testing!

[chadrik]

greg,
this looks really well-thought out.  i think it has a lot of  
potential, but the problem i have with this approach is that for a  
truly transparent workflow you will have to teach every single command  
that accepts a file as an argument to convert to that path to a bfile  
path ( myfile --> .hgbfiles/myfile ).  is that within the scope of the  
project?  perhaps this problem would be more easily solved for bfiles  
and other extensions by modifying the mercurial extension API to  
provide encode_path and decode_path callbacks to give extensions the  
chance to modify file path arguments going to and coming from other  
commands?

also, it seems like many more commands will need special treatment  
than what is listed in your usage.txt: revert and merge should  
probably run bfupdate (not sure if those fall under the category of  
"commands that do an implicit update").

i found one potential bug (or maybe user error?).  after doing a  
revert to a previous revision i could not get bfiles to recognize that  
there was a mismatch, but bfupdate worked as expected:

$ cat .hgbfiles/video.mov
85b50276ab2b37535897e5d7d8b3a29dd322db7f
$ hg revert .hgbfiles/video.mov -r 0
$ hg commit -m "reverted"
$ cat .hgbfiles/video.mov
970fc20ced0d3c0ce45401bbb01058178b0d183b
$ hg bfrefresh
abort: no big files changed
Exit 255
$ hg bfstatus
$ hg bfupdate
1 big files updated, 0 removed

also, one last question. is there the possibility of a simplified mode  
for merging conflicts with bigfiles, since this will always be a  
simple yes or no?

thanks,
chad