http://bugs.grommit.com/show_bug.cgi?id=244
mike.kupfer at sun.com changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|mike.kupfer at sun.com |scm-migration-
| |dev at opensolaris.org
Severity|critical |normal
Status|ASSIGNED |NEW
Priority|P3 |P5
Target Milestone|tools putback |ON migration
------- Comment #4 from mike.kupfer at sun.com 2008-03-10 16:15 PDT -------
I looked at a couple different types of corruption:
- .hg/dirstate completely missing
- .hg/dirstate a zero-length file
- last entry missing from dirstate
- 2nd 8KB block of dirstate replaced with 8KB from another file
- 2nd 8KB block of dirstate replaced with nulls
The first 3 cases all end up with Mercurial getting somewhat confused
about what's already being tracked by the repo. If you "hg add" a
file that's already tracked, Mercurial (0.9.5) notices it at commit
time. If you didn't edit the file, you apparently get a do-nothing
changeset. If you did edit the file, you apparently get a normal
changeset with your edits. (I say "apparently" because I just tested
using "hg log" and "hg diff". I didn't actually look at the on-disk
repo storage.)
It doesn't look like any of this can lead to corruption of what's
actually committed to the changeset. It's possible that the user will
forget to inform Mercurial about changes after rebuilding the dirstate
(hg debugrebuildstate), but that's no worse than forgetting to inform
Mercurial of the change in the first place.
And since there's no corruption to the committed data, the corruption
won't spread.
The last two cases cause Mercurial to abort while reading the
dirstate. For "hg stat" or "hg recommit" we get a Python backtrace.
That's not pretty, but it gives a pretty strong clue as to what the
problem is. For "hg commit" we just get "abort: too many values to
unpack", which isn't particularly helpful.
So this appears to be primarily a user interface issue. Changing
pri/sev to P5/normal, changing milestone to "ON migration".
--
Configure bugmail: http://bugs.grommit.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
