bzr branch or checkout --hardlink has no effect in 2a format

This behaviour is explained by this comment by Ian in workingtree_4.py:

   1416 # If content filtering is supported, do not use the accelerator
   1417 # tree - the cost of transforming the content both ways and
   1418 # checking for changed content can outweight the gains it gives.
   1419 # Note: do NOT move this logic up higher - using the basis from
   1420 # the accelerator tree is still desirable because that can save
   1421 # a minute or more of processing on large trees!
   1422 # The original tree may not have the same content filters
   1423 # applied so we can't safely build the inventory delta from
   1424 # the source tree.
   1425 if wt.supports_content_filtering():
   1426 accelerator_tree = None
   1427 delta_from_tree = False
   1428 else:
   1429 delta_from_tree = True
   1430 # delta_from_tree is safe even for DirStateRevisionTrees,
   1431 # because wt4.apply_inventory_delta does not mutate the input
   1432 # inventory entries.
   1433 transform.build_tree(basis, wt, accelerator_tree,
   1434 hardlink=hardlink,
   1435 delta_from_tree=delta_from_tree)

I'll change the test to expect failure here, and I think we should at least give a message to the user explaining why their request was not followed.

It seems like Ian's saying that we *could* hardlink them, it just might be slow. I think we should still give the user the option to do it if it's safe: they may care about disk space more than they care about speed, or they may not actually have any content filters configured.

The attached branch https://code.launchpad.net/~mbp/bzr/408193-hardlink

 * gives a warning if hardlinking won't be done
 * turns the tests into KnownFailure if they see this message and hardlinking fails

Before actually reenabling the feature I'd like to talk to Ian and/or measure this possible performance loss.

Not doing what I request is a bug. I don't use content filtering, so I shouldn't have to pay for it.

Does this need to be a 2.0 blocker?

FWIW, my changes to make content filtering work/faster were just that. At no stage did I intend --hardlink to stop working. If it turns out that the two are incompatible for some technical reason, then we ought to trap that fact up-front and tell the user immediately when they specify --hardlink as an option, not fail silently.

2009/8/12 Ian Clatworthy <email address hidden>:
> FWIW, my changes to make content filtering work/faster were just that.
> At no stage did I intend --hardlink to stop working. If it turns out
> that the two are incompatible for some technical reason, then we ought
> to trap that fact up-front and tell the user immediately when they
> specify --hardlink as an option, not fail silently.

That's what my patch does.

There's a comment block, I think mentioned in this bug or touched by
my patch, from you, that disables it but isn't quite clear about
whether it would be safe or just slow to turn it back on.

--
Martin <http://launchpad.net/~mbp/>

Untargeting and unassigning: I've merged my patch to give a warning, and the tests pass. I agree with Aaron it is still a bug.

To fix it probably requires writing some smoke tests for use of --hardlink with content filtering. I'm a bit concerned that we'll hardlink files that aren't actually meant to be the same. (But maybe not, the design may have enough inherent protection against it.)

This bugged me enough that I've taken a stab at fixing it in <lp:~spiv/bzr/hardlink-2a-408193>. It doesn't appear to fail any tests, and performance seems reasonable, but it probably deserves some new tests to make sure that hardlinks and content filtering interact safely.