On Fri, 2006-03-31 at 17:15 -0800, Bryan O'Sullivan wrote:
> Something apparently got dropped here. This is the end of your review.
I managed to get the rest of your report, so here's the rest of my
response :-)
> c8. tool community health
>
> There have been a few problems with hgmerge, due to the age of
> Solaris's /bin/sh. These have typically been detected and
> repaired within a couple weeks. Also, at least one community
> member has noticed this pattern and suggested a more fundamental
> fix (rewriting hgmerge in Python).
I see in my IRC logs that a Mercurial developer (Vadim Gelfer) spent a
good portion of Friday helping a Sun employee (John Levon) track down a
Solaris-specific bug. Vadim installed Solaris specifically to reproduce
and fix the bug. As it turned out, the bug lay with Solaris not
following a POSIX recommendation w.r.t. the implementation of fdopen(3).
The point of this anecdote is to illustrate that Mercurial developers
are responsive to Sun-specific concerns. John reported the problem on
Friday morning, and Vadim had it fixed by that evening. You can't get
much faster response :-)
It's also worth noting that Mercurial already has users within Sun
(since someone mentioned this with respect to git), and external users
are running Mercurial on Solaris releases as old as Solaris 2.6.
> c11. transactional operations and corruption recovery
>
> Mercurial's state files are updating by appending. So presumably
> corrupted files can be repaired by rolling back to a consistent
> set of files.
Yes, this is what the "recover" command does.
> Signal handling (e.g., SIGINT) appears sensible.
>
> I simulated a crash using SIGKILL during a clone [...]
> * the child repository was left with two lock files which would
> block some operations but not others. A push to the parent
> was not blocked. Either this is a bug or we need to
> understand Mercurial's use of locks better.
Mercurial has been modified since 0.8 to automatically detect and
break locks left behind by processes that were running during a system
crash or other catastrophe. So this problem should no longer occur.
> * Mercurial seemed confused by the contents of the child.
Since there were two lock files left behind, Mercurial got killed
while populating the working directory. The state of the working
directory is trivial to fix by running the "update -C" command.
> c12. content generality
>
> Email discussions have indicated that Mercurial is supposed to
> support binary files as well as text.
It does indeed.
> However, the merge code appears to assume text files.
Are you referring to the hgmerge script? It should be simple enough to
modify hgmerge to detect a binary file and ask you to choose a winner
instead of trying a merge, particularly once it gets rewritten in
Python.
> o13. partial trees
>
> Not supported.
There is a plan to support this, by the way. I think it got discussed
on IRC, so I don't have a reference to hand.
> Must Have Initially
>
> * rename/merge integration
You're not the only ones wanting this :-)
> * versioning of on-disk data structures, or at least a
> convincing story for how format changes will be handled
The RevlogNG work implements version numbers in revlogs, and revlogs
are used for all persistent storage, so this should be a non-issue.
> * a reliable mechanism for checking a tree after a crash and making
> any necessary repairs (see [42]Section c11 above)
Already implemented:
hg verify - verify the integrity of the repository
hg recover - roll back an interrupted transaction
<b
_______________________________________________
tools-discuss mailing list
[email protected]
