[issue413] hg add mishandles subprojects

[Jonathan Shapiro]

New submission from Jonathan Shapiro <shap at eros-os.com>:

This is marked critical because it involves workspace corruption. Apologies if
that is too high -- I don't know the project conventions yet.

Command sequence from asak that illustrates misbehavior:

  hg init a; cd a; hg init b; echo foo > b/foo; hg add; hg status; hg add b/foo;
hg status

Problem: this sequence results in a file, b/foo, s.t. two repositories believe
they own it. The only possible outcome of this is workspace corruption. There
are only two reasonable behaviors here:

  1. Reject the second add, because subtree not part of "current" project.
  2. Notice that b is a sub-project, and treat this as
       (cd b; hg add foo)

The second is more graceful, but hard to generalize. Consider a variant

  hg init a; cd a
  hg init b; hg init c
  touch b/foo c/bar
  hg add b/foo c/bar

Following model (2), the last command would need to subtraverse into multiple
projects. This is actually very sensible behavior, but implementing it almost
certainly is not straightforward in the general case. Consider:

  hg update a/foo b/bar a/baz

What are the rules about which updates happen in which steps?

For the moment, as a guarantee of sanity, the tool should ensure that no mutate
is ever performed in the workspace to a file that is not part of the current
project. This guarantees near-term sanity while remaining backwards compatible
if the handling is later generalized.

Caveat: I have not checked the impact this might have on the forest extension.

Comment: We hit this in OpenCM by accident, and it created tremendous confusion.

----------
messages: 2326
nosy: shap
priority: critical
status: unread
title: hg add mishandles subprojects

____________________________________________________
Mercurial issue tracker <mercurial-bugs at selenic.com>
<http://www.selenic.com/mercurial/bts/issue413>
____________________________________________________