bfiles: ready for testing!
Greg Ward
greg-hg at gerg.ca
Tue Oct 13 01:40:12 UTC 2009
On Thu, Oct 8, 2009 at 6:25 PM, chadrik <chadrik at gmail.com> wrote:
> 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?
No, not really. I'm not aiming for a completely transparent workflow.
I want my users to be aware that there is such a thing as "big" files
that are treated differently from other files. I'm pretty sure I need
to implement autoupdate, autorefresh, and probably autoput modes to
prevent all the obvious mistakes. But I don't want to go putting lots
and lots of tentacles deep into every aspect of Mercurial.
Here's the funny thing: if you want a file-based centralized version
control system that makes no attempt to compute deltas or do any
compression of binary files, that provides no support for merging
them, and performs tolerably well over a fast LAN, it has been around
for 15 years now: CVS. It may well be to my everlasting shame and
embarassment that Mercurial + bfiles ends up reinventing CVS with a
better UI and some automated tests. Time will tell.
> 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?
Hadn't really thought about it. Sounds like tentacles to me.
> 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").
Hmmm. My plan for "autoupdate" mode is that any command that updates
the working copy (update, pull -u, clone without -U) should
automatically "bfupdate" to download/delete big files.
"revert" is tricky because it updates the working copy but does not
change its parent. I have not yet given much thought to reverting
changes to big files, but I strongly suspect I'll have to implement a
bfrevert command. If I do, making "revert" automatically "bfrevert"
sounds sensible, but I'm not sure if that should be an "autorevert"
mode, or if it should just be implied by "autoupdate" mode. Opinions
welcome.
"merge" is just plain tricky. I have given very little thought to
what bfiles should do at merge time. Since one of the underlying
assumptions is that big files are not mergeable, I might steal
Bazaar's default behaviour: just write <file>.base, <file>.this, and
<file>.other, and let the user sort out the mess. Not sure what to do
with the standin file.
> 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"
Hrrmmm. I think I will play the "I wrote this code so I can define
what's right" card and call that "user error". ;-) Specifically, any
change to a standin file behind bfiles' back is against the rules;
behaviour after that is undefined.
> $ cat .hgbfiles/video.mov
> 970fc20ced0d3c0ce45401bbb01058178b0d183b
> $ hg bfrefresh
> abort: no big files changed
> Exit 255
> $ hg bfstatus
> $ hg bfupdate
> 1 big files updated, 0 removed
See? Classic undefined behaviour! It would be better if bfiles could
detect this "invalid" operation and complain earlier, though.
Hmmmmm.
> 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?
Like I said, I've given very little thought to merging. Ideas
welcome. By "yes" or "no", I assume you mean, "keep my version and
toss the other guy's" or "lose my version and keep the other guy's",
right?
Greg
More information about the Mercurial
mailing list