2

I've thought this through and I think I understand the implications, but I wanted to get a sanity check because the caveats on https://www.mercurial-scm.org/wiki/ShareExtension are pretty general.

Specifically, the warning is "It's probably not a good idea to mix MQ and shared clones; if you do so, you should definitely avoid pushing/popping patches in one clone while another clone has patches applied."

However based on my understanding of how Mq works, it's only unsafe to push/pop patches (create/destroy history) if you have two shares whose working directory parent would be affected by such changes. That is, if you have two shares that are updated to separate named branches, pushing/popping patches from one should only have the effect on the other of creating/destroying history that is unrelated to the working directory and thus should NOT have any undesirable side-effects.

There will be small side effects, such as revision sequence number changes in some situations, but nothing that should jeopardize correctness or cause problems with the working directory.

Is this correct or am I missing something?

Vadim Kotov
  • 8,084
  • 8
  • 48
  • 62
rationull
  • 465
  • 4
  • 9

2 Answers2

0

I'm not sure about this, but AFAIK if you end up having the exact same file content in both branches (repos), this might still wind up as shared storage and wreak havoc.

Ringding
  • 2,856
  • 17
  • 10
  • Applied patches DO wind up in shared storage (and they are pulled back out when you unapply/qpop them) but from another share's perspective this is just creating and destroying history on a branch that's not convergent with the working directory, and I'm not aware that causes any problems. Patches in the queue but not applies to the repro are not real changesets and are not in shared storage. – rationull Oct 28 '13 at 16:04
  • Thinking about this further: if matching file content in a revision/branch that is NOT an ancestor of the working directory were a problem with history modification, then that would imply that stripping an unrelated revision from a repository that happened to share file content with the parent of the working directory could screw something up. That doesn't sound correct to me. – rationull Feb 05 '14 at 21:00
0

This is obviously not a definitive answer, but I just wanted to report back in case anyone else is interested in this situation. I've been running for several months now with multiple shares on a "central copy" of a large repo, with each share being dedicated to its own branch, and using MQ freely within each share. I have not hit any problems. History changes on other branches just look the same as pulls/strips would -- unrelated changesets being added, modified, and removed.

rationull
  • 465
  • 4
  • 9