RFC: faster check

[Martin Albisetti]

On Wed, Jan 14, 2009 at 12:24 AM, Robert Collins
<robertc at robertcollins.net> wrote:
> I'm not sure I see the connection. check is always going to be at least
> as slow as making a full clone(). And clearly, check() can only check
> for problems we anticipate, so its almost always possible for a new form
> of error to occur. I don't think getting rid of the backup during
> upgrade is a good idea whether or not check() works. There may be
> multiple reasons folk want to rollback (not the least of which is
> upgrades past trapdoors).

Well, there are use cases like "I know what I'm doing, I just don't
have another 120gb of free space to upgrade everything". That has kept
me from upgrading all the branches I have at the office (and I ended
up tweaking a plugin to do it).


> And it doesn't seem related to check speed at
> all, or am I missing something?

Yes and no. If it's faster and uses less memory, I'm inclined to work
on something that can be added to the core. If it's painful, then it's
probably best kept as a plugin for people with, well, specific use
cases.
The question of what check was suppose to guarantee caught my
attention, so don't let me hijack the thread, I was mainly wondering
if it could be considered that "if check ran without failures, we
guarantee the branch is usable" or not.


-- 
Martin