|
Replies:
16
-
Last Post:
Apr 5, 2006 8:53 PM
by: Bryan O'Sullivan
|
|
|
Posts:
824
From:
US
Registered:
3/9/05
|
|
|
|
Stephen Hahn
sch@eng.sun.com
|
|
|
|
Re: Mercurial evaluation (interim) report
Posted:
Mar 31, 2006 4:20 PM
in response to: kupfer
|
|
* Mike Kupfer <mike dot kupfer at sun dot com> [2006-03-31 15:23]:
> I've posted an interim evalution report for Mercurial at
>
> http://www.opensolaris.org/os/community/tools/scm/mercurial-eval.html
>
> Please send me any corrections, questions, or comments that you might
> have.
I skimmed it: the sentence after the heading "mismerges" is
incomplete, so I don't know how much of the document might be missing.
It looks reasonable so far, as does Frank's.
Cheers
Stephen
--
Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems
stephen dot hahn at sun dot com http://blogs.sun.com/sch/
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Bryan O'Sullivan
bos@serpentine.com
|
|
|
|
Re: Mercurial evaluation (interim) report
Posted:
Mar 31, 2006 5:15 PM
in response to: kupfer
|
|
On Fri, 2006-03-31 at 15:23 -0800, Mike Kupfer wrote:
> I've posted an interim evalution report for Mercurial at
>
> http://www.opensolaris.org/os/community/tools/scm/mercurial-eval.html
Thanks. I have some comments and observations to offer; please see
below. Please pardon me if I repeat things I've said in earlier
discussions.
> Mercurial implements a model of independent repositories, though a
> repository can be configured to have a de-facto parent.
A repository can be configured to pull from/push to a default repository
when a location is not explicitly provided. The pull and push defaults
can be independent or "wired together".
> The preferred model for propagating changes is to pull them from the
> child, rather than pushing them to the parent.
I would say this is not true. Both operations work perfectly well,
and are considered normal.
> I believe that Mercurial supports updates between two repositories
> with a common ancestor, but I haven't tested this (TBD).
This is true. It is also possible to push or pull changes to and from
completely unrelated repositories, though you have to tell Mercurial to
do this with "--force" (since it's not usually what you want to do).
This can be useful if you need to merge repositories for different
projects while preserving history, for example.
> I believe that the "disconnected-use" requirements are all satisfied,
> though I haven't tested them (TBD).
I'm pretty sure they are :-)
> As mentioned in the requirements document, Mercurial supports remote
> access via |ssh|.
And pull over http. Pull and push also work over network filesystems.
> At least one storage representation change is planned: "RevlogNG",
> which is planned for Mercurial 0.9
Just for completeness: as I've mentioned before, RevlogNG is
completely interoperable with existing repositories. This will always
be the case.
In other words, a pre-RevlogNG Mercurial cannot read a RevlogNG
repository, but a new Mercurial can read and write both, and can pull
and push to and from an older Mercurial.
> Binary files give improved performance, but if manual repairs are
> needed, we'll need a binary editing program.
Mercurial provides an automated "recover" program that does the equivalent of an
"fsck". In practice, I've never had to use it once in a year of heavy
use.
> Mercurial does not provide its own access control mechanism for
> controlling access to subtrees within a repository. While it might
> be possible to restrict user access to certain subtrees using
> filesystem ACLs, it would probably be better to use various
> pre-operation hooks (e.g., |pretxnchangegroup|) to implement that
> sort of control.
Correct. It's also possible to do the same kind of access control via
ssh without needing to create a pile of user accounts. There's a
recipe for doing this in the contrib directory of the source tree.
> One nit: the current documentation appears to reflect the current
> development version of the code, rather than the most recent release[1]
> <#docexample>; there is nothing in the documentation to clarify what
> version it applies to.
Are you referring to the documentation in the wiki? That's a good
point, and would bear clarification.
> The hook infrastructure invokes the named hook(s) with a few tokens
> such as the changeset ID passed in via the environment. This means
> that the hook may need to invoke various Mercurial commands to find
> out more about the changeset.
It is possible to do that, yes. We are also looking at providing a hook
mechanism that can run in-process, as Python code, so that your hooks
can either shell out or write a Python module, depending on your needs
and level of comfort.
> Presumably Mercurial's designers have thought about lock re-entrancy
> issues, but this should be verified.
Mercurial only uses write locks; readers are lock-free. Since hooks
should only be reading the repository contents at present, there are
no re-entrancy issues with the current design.
> For example, "hg log" gives the old and new names of a renamed file,
> along with the names of any other files involved in the changeset,
> but it can't tell you that file "foo" was renamed to "bar".
This is a known issue, and we plan to fix it within the next week or
two.
> At least one unexpected behavior was noted while testing: pushing a
> changeset from repository A to repository B caused A's |commit| hook
> to fire.
It's possible that you tripped over a bug that was fixed about two
weeks ago: http://www.selenic.com/mercurial/bts/issue113
That fix will be in Mercurial 0.8.1.
> There is some documentation on the network protocol
> <http://, though
> it's a bit sketchy.
It's very simple :-) There are only about 7 commands in the wire
protocol. We can document it more extensively if needed.
> Mercurial associates a text comment with each changeset; this is
> added as part of the |commit| operation. The first line of the
> comment is displayed as a summary of the changeset for operations
> like "log", though the full comment can be displayed with the "-v"
> option. This is somewhat inconsistent with the current conventions
> for putbacks into ON; we'll want to think about what we want to do.
I don't know what the ON standards are for this, but Mercurial now
includes style and template options for customising the display of the
"log" command and other commands that print similar information. It
should be simple to extend those to support whatever the ON
conventions are; for example, there's a style that produces output in
GNU ChangeLog format, which is very different from the default.
> Although I haven't built Mercurial from source, my understanding is
> that it's pretty straightforward. It requires Python, but I don't
> believe it requires anything beyond a normal Python distribution.
It builds out of the box on Solaris 10, once the system Python's
Makefile is fixed to use gcc.
> Note that pushing a changset updates the target repository, but
> updating the target's source tree is a separate step ("hg update").
This is true for pulls, too.
> Backing out a changeset after the files have been subsequently
> modified is less straightforward.
There's a bug filed that should automate this:
http://www.selenic.com/mercurial/bts/issue146
> By default, "hg status" lists files that aren't tracked in the
> repository (e.g., compiled binaries, editor backup files).
This is normal behaviour for SCM tools. You can configure Mercurial
to ignore files either by putting a .hgignore file in the repository,
or adding a global or per-user config option that tells it where to
find other files that contain ignore directives.
> The |status| subcommand does offer options to filter out noise, but
> it's not clear they can be used to give the desired results (show
> untracked source files and makefiles, but ignore all other untracked
> files).
The ignore mechanism is appropriate for this. It's also used by other
commands, such as commit.
> Mercurial's default for resolving conflicts is the |hgmerge| script.
> This script checks for the presence of various third-party conflict
> resolver programs, such as |tkdiff|. At least some of these programs
> (e.g., |tkdiff|) offer functionality that is comparable to what is
> available with Teamware and Filemerge.
I'd recommend taking a look at kdiff3. In my experience, it's both
more powerful and easier to use than tkdiff. The downside from a
Solaris perspective is that it requires KDE libraries to build. Some
people are very fond of meld, which as a GNOME program might better
suit the Sun development environment.
> We'll want to think about possible changes to |hgmerge| to reduce
> the likelihood of mismerges.
A Mercurial developer is working on a history-sensitive merge
extension that ought to reduce the likelihood of automated mismerges,
and should also eliminate the need to have RCS merge or diff3
installed.
> First, if |hgmerge| uses |patch|, we may want to force a review of
> the changes, even if the patch applies cl
Something apparently got dropped here. This is the end of your review.
Regards,
<b
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
824
From:
US
Registered:
3/9/05
|
|
|
|
Re: Mercurial evaluation (interim) report
Posted:
Apr 2, 2006 9:28 PM
in response to: Bryan O'Sullivan
|
|
Hi Bryan, thanks for the prompt review. I took a quick look at
your responses, and I've got a couple questions which I'll send
tomorrow.
>>>>> "bos" == Bryan O'Sullivan <bos at serpentine dot com> writes:
>> First, if |hgmerge| uses |patch|, we may want to force a review of
>> the changes, even if the patch applies cl
bos> Something apparently got dropped here. This is the end of your
bos> review.
Hmm. Stephen Hahn reported seeing a truncated report, too. But I've
had no problems viewing it, either from the office or at home. Sounds
like a web site problem, so I'm cc'ing website-discuss in case anyone
else has seen problems like this. (For the website-discuss folks, the
page that is apparently getting truncated randomly is
http://www.opensolaris.org/os/community/tools/scm/mercurial-eval.html.)
mike
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
293
From:
US
Registered:
4/26/05
|
|
|
|
Re: Mercurial evaluation (interim) report
Posted:
Apr 3, 2006 8:41 AM
in response to: kupfer
|
|
Hi Mike,
I see your whole page without any problems. Section D "Changes/Features
Required/Desired" is the last section, followed by "Notes" (4 notes are
listed).
Bonnie
Mike Kupfer wrote On 04/02/06 22:28,:
> Hi Bryan, thanks for the prompt review. I took a quick look at
> your responses, and I've got a couple questions which I'll send
> tomorrow.
>
>
>>>>>>"bos" == Bryan O'Sullivan <bos at serpentine dot com> writes:
>
>
>>>First, if |hgmerge| uses |patch|, we may want to force a review of
>>>the changes, even if the patch applies cl
>
>
> bos> Something apparently got dropped here. This is the end of your
> bos> review.
>
> Hmm. Stephen Hahn reported seeing a truncated report, too. But I've
> had no problems viewing it, either from the office or at home. Sounds
> like a web site problem, so I'm cc'ing website-discuss in case anyone
> else has seen problems like this. (For the website-discuss folks, the
> page that is apparently getting truncated randomly is
> http://www.opensolaris.org/os/community/tools/scm/mercurial-eval.html.)
>
> mike
> _______________________________________________
> tools-discuss mailing list
> tools-discuss at opensolaris dot org
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
941
From:
Redwood City, CA
Registered:
3/9/05
|
|
|
|
Re: Mercurial evaluation (interim) report
Posted:
Apr 3, 2006 1:32 PM
in response to: kupfer
|
|
Quoth Mike Kupfer on Sun, Apr 02, 2006 at 09:28:09PM -0700:
> Hi Bryan, thanks for the prompt review. I took a quick look at
> your responses, and I've got a couple questions which I'll send
> tomorrow.
>
> >>>>> "bos" == Bryan O'Sullivan <bos at serpentine dot com> writes:
>
> >> First, if |hgmerge| uses |patch|, we may want to force a review of
> >> the changes, even if the patch applies cl
>
> bos> Something apparently got dropped here. This is the end of your
> bos> review.
>
> Hmm. Stephen Hahn reported seeing a truncated report, too. But I've
> had no problems viewing it, either from the office or at home. Sounds
> like a web site problem, so I'm cc'ing website-discuss in case anyone
> else has seen problems like this. (For the website-discuss folks, the
> page that is apparently getting truncated randomly is
> http://www.opensolaris.org/os/community/tools/scm/mercurial-eval.html.)
It's pretty consistent for me. In fact, the page is missing closing
body & html tags. This is the case through crowroad.eng:8000,
crowroad.eng:8080, and webcache.sfbay:8080.
David
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Derek Cicero
derek.cicero@sun.com
|
|
|
|
Re: [website-discuss] Re: Mercurial
evaluation (interim) report
Posted:
Apr 4, 2006 3:44 PM
in response to: bustos
|
|
David Bustos wrote:
> Quoth Mike Kupfer on Sun, Apr 02, 2006 at 09:28:09PM -0700:
>
>> Hi Bryan, thanks for the prompt review. I took a quick look at
>> your responses, and I've got a couple questions which I'll send
>> tomorrow.
>>
>>>>>>> "bos" == Bryan O'Sullivan <bos at serpentine dot com> writes:
>>>>>>
>>>> First, if |hgmerge| uses |patch|, we may want to force a review of
>>>> the changes, even if the patch applies cl
>>>
>> bos> Something apparently got dropped here. This is the end of your
>> bos> review.
>>
>> Hmm. Stephen Hahn reported seeing a truncated report, too. But I've
>> had no problems viewing it, either from the office or at home. Sounds
>> like a web site problem, so I'm cc'ing website-discuss in case anyone
>> else has seen problems like this. (For the website-discuss folks, the
>> page that is apparently getting truncated randomly is
>> http://www.opensolaris.org/os/community/tools/scm/mercurial-eval.html.)
>
>
> It's pretty consistent for me. In fact, the page is missing closing
> body & html tags. This is the case through crowroad.eng:8000,
> crowroad.eng:8080, and webcache.sfbay:8080.
I can see the entire page and the proper closing tags are present, but
something is amiss b/c it is not showing up in the navigation. I will
look into it.
Derek
>
>
> David
> _______________________________________________
> website-discuss mailing list
> website-discuss at opensolaris dot org
>
--
Derek Cicero
Program Manager
Solaris Kernel Group, Software Division
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Derek Cicero
derek.cicero@sun.com
|
|
|
|
Re: [website-discuss] Re: Mercurial evaluation
(interim) report
Posted:
Apr 4, 2006 5:31 PM
in response to: Derek Cicero
|
|
Derek Cicero wrote:
> David Bustos wrote:
>
>> Quoth Mike Kupfer on Sun, Apr 02, 2006 at 09:28:09PM -0700:
>>
>>> Hi Bryan, thanks for the prompt review. I took a quick look at
>>> your responses, and I've got a couple questions which I'll send
>>> tomorrow.
>>>
>>>>>>>> "bos" == Bryan O'Sullivan <bos at serpentine dot com> writes:
>>>>>>>
>>>>>>>
>>>>> First, if |hgmerge| uses |patch|, we may want to force a review of
>>>>> the changes, even if the patch applies cl
>>>>
>>>>
>>> bos> Something apparently got dropped here. This is the end of your
>>> bos> review.
>>>
>>> Hmm. Stephen Hahn reported seeing a truncated report, too. But I've
>>> had no problems viewing it, either from the office or at home. Sounds
>>> like a web site problem, so I'm cc'ing website-discuss in case anyone
>>> else has seen problems like this. (For the website-discuss folks, the
>>> page that is apparently getting truncated randomly is
>>> http://www.opensolaris.org/os/community/tools/scm/mercurial-eval.html.)
>>
>>
>>
>> It's pretty consistent for me. In fact, the page is missing closing
>> body & html tags. This is the case through crowroad.eng:8000,
>> crowroad.eng:8080, and webcache.sfbay:8080.
>
>
> I can see the entire page and the proper closing tags are present, but
> something is amiss b/c it is not showing up in the navigation. I will
> look into it.
The problem appears to be that the page was uploaded as an HTML
attachment rather than added as an actual page in the Tools hierarchy,
which resulted in the app trying to add the template wrapper onto the
source HTML.
This should work now, so let me know:
http://www.opensolaris.org/os/community/tools/scm/dcm_evaluation_mercurial/
Assuming this solves the problem at hand, I will open two RFEs related
to this issue:
1) Allow users to add a page that does not have a left-nav element
(which is what Mike was trying to do in the first place).
2) Handle HTML attachments differently.
Derek
>
> Derek
>
>>
>>
>> David
>> _______________________________________________
>> website-discuss mailing list
>> website-discuss at opensolaris dot org
>>
>
>
>
--
Derek Cicero
Program Manager
Solaris Kernel Group, Software Division
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
941
From:
Redwood City, CA
Registered:
3/9/05
|
|
|
|
Re: [website-discuss] Re: Mercurial evaluation
(interim) report
Posted:
Apr 5, 2006 10:15 AM
in response to: Derek Cicero
|
|
Quoth Derek Cicero on Tue, Apr 04, 2006 at 05:31:21PM -0700:
> The problem appears to be that the page was uploaded as an HTML
> attachment rather than added as an actual page in the Tools hierarchy,
> which resulted in the app trying to add the template wrapper onto the
> source HTML.
>
> This should work now, so let me know:
>
> http://www.opensolaris.org/os/community/tools/scm/dcm_evaluation_mercurial/
Looks good.
David
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Bryan O'Sullivan
bos@serpentine.com
|
|
|
|
Re: Mercurial evaluation (interim) report
Posted:
Apr 3, 2006 10:38 AM
in response to: Bryan O'Sullivan
|
|
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
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
852
From:
GB
Registered:
3/9/05
|
|
|
|
Re: Mercurial evaluation (interim) report
Posted:
Apr 3, 2006 11:23 AM
in response to: Bryan O'Sullivan
|
|
On Mon, Apr 03, 2006 at 10:38:45AM -0700, Bryan O'Sullivan wrote:
> 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 was almost obscenely helpful... I've had great help with other
problems I've had previously too, but Vadim really went above and beyond the
call of duty to help out here. And as it turns out, the problem probably
happens on FreeBSD too; there's already a bug fix to Python knocking about
after I reported it upstream.
regards
john
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
824
From:
US
Registered:
3/9/05
|
|
|
|
Re: Mercurial evaluation (interim) report
Posted:
Apr 3, 2006 3:37 PM
in response to: Bryan O'Sullivan
|
|
Thanks for your detailed responses!
>>>>> "bos" == Bryan O'Sullivan <bos at serpentine dot com> writes:
>> The preferred model for propagating changes is to pull them from the
>> child, rather than pushing them to the parent.
bos> I would say this is not true. Both operations work perfectly well,
bos> and are considered normal.
Ah, okay. I'll take that out.
bos> a pre-RevlogNG Mercurial cannot read a RevlogNG repository, but a
bos> new Mercurial can read and write both, and can pull and push to and
bos> from an older Mercurial.
I saw in this morning's mail (on the Mercurial list) that the format is
controlled by a switch in hgrc. That answers one of my questions. :-)
I've got a couple more questions:
First, what happens when a pre-RevlogNG Mercurial reads a RevlogNG
repository? What is the mechanism that ensures that the old Mercurial
will quickly give up and not do anything that could corrupt the
repository?
Second, does the revlog format change impact network operations? For
example, can a pre-RevlogNG Mercurial pull from a RevlogNG repository
using HTTP or ssh?
Third, what happens if the revlog format entry in hgrc is changed back
from 1 (RevlogNG) to 0 (classic revlog)?
>> Binary files give improved performance, but if manual repairs are
>> needed, we'll need a binary editing program.
bos> Mercurial provides an automated "recover" program that does the
bos> equivalent of an "fsck". In practice, I've never had to use it
bos> once in a year of heavy use.
Yes, my original remarks were perhaps a little terse. I don't expect
the repository to get corrupted under normal circumstances, and I expect
that the automatic recovery tools will handle most of the corruption
cases.
But don't forget that there will be people running Mercurial on
pre-release kernels. Our internal gate machine runs the most recent
nightly snapshot. And a couple years ago we had a flurry of corrupted
SCCS files, which we eventually traced to a flakey network switch. So
given enough time and usage, I expect we *will* see repository
corruption that the automated tools cannot handle.
I think the current engineering tradeoff is the right one. I'm just
calling out the need for a binary editor as input for the migration
plan, assuming we go with Mercurial.
bos> It's also possible to do the same kind of access control via ssh
bos> without needing to create a pile of user accounts. There's a
bos> recipe for doing this in the contrib directory of the source tree.
Cool. You're talking about the SharedSSH page on the wiki, yes?
>> One nit: the current documentation appears to reflect the current
>> development version of the code, rather than the most recent
>> release[1] <#docexample>; there is nothing in the documentation to
>> clarify what version it applies to.
bos> Are you referring to the documentation in the wiki?
Right.
>> For example, "hg log" gives the old and new names of a renamed file,
>> along with the names of any other files involved in the changeset,
>> but it can't tell you that file "foo" was renamed to "bar".
bos> This is a known issue, and we plan to fix it within the next week
bos> or two.
Great, thanks.
>> At least one unexpected behavior was noted while testing: pushing a
>> changeset from repository A to repository B caused A's |commit| hook
>> to fire.
bos> It's possible that you tripped over a bug that was fixed about two
bos> weeks ago: http://www.selenic.com/mercurial/bts/issue113
Yeah, that looks like the culprit. Thanks.
>> Backing out a changeset after the files have been subsequently
>> modified is less straightforward.
bos> There's a bug filed that should automate this:
bos> http://www.selenic.com/mercurial/bts/issue146
Noted; thanks.
>> By default, "hg status" lists files that aren't tracked in the
>> repository (e.g., compiled binaries, editor backup files).
bos> This is normal behaviour for SCM tools.
Yeah, I should have noted that it's not just Mercurial. I don't object
to the behavior, but it's different from Teamware, so it's something to
consider in any migration plan.
bos> You can configure Mercurial to ignore files either by putting a
bos> .hgignore file in the repository, or adding a global or per-user
bos> config option that tells it where to find other files that contain
bos> ignore directives.
Do the ignore directives only consider the file name, or do they look at
the path?
>> We'll want to think about possible changes to |hgmerge| to reduce the
>> likelihood of mismerges.
bos> A Mercurial developer is working on a history-sensitive merge
bos> extension that ought to reduce the likelihood of automated
bos> mismerges, and should also eliminate the need to have RCS merge or
bos> diff3 installed.
That's good to know; thanks. Is this covered by issue12, or is that
something else?
bos> The point of this anecdote is to illustrate that Mercurial
bos> developers are responsive to Sun-specific concerns.
Indeed. I've been pleased with the responsiveness, and I apologize for
not saying that clearly in the report.
bos> Mercurial has been modified since 0.8 to automatically detect and
bos> break locks left behind by processes that were running during a
bos> system crash or other catastrophe.
Does it store more than just the pid? (How does it ensure safety when
NFS is used?)
>> * Mercurial seemed confused by the contents of the child.
bos> Since there were two lock files left behind, Mercurial got killed
bos> while populating the working directory. The state of the working
bos> directory is trivial to fix by running the "update -C" command.
Is this scriptable? That is, if both lock files are present, is "update
-C" always a good thing to do? And can this be tied into the automatic
breaking of locks that you mentioned?
>> However, the merge code appears to assume text files.
bos> Are you referring to the hgmerge script?
Yes.
bos> It should be simple enough to modify hgmerge to detect a binary
bos> file and ask you to choose a winner instead of trying a merge,
bos> particularly once it gets rewritten in Python.
Okay. I'll just flag this as something that needs more thought for the
potential migration plan.
bos> The RevlogNG work implements version numbers in revlogs, and
bos> revlogs are used for all persistent storage, so this should be a
bos> non-issue.
Excellent.
>> * a reliable mechanism for checking a tree after a crash and making
>> any necessary repairs (see [42]Section c11 above)
bos> Already implemented:
bos> hg verify - verify the integrity of the repository hg recover -
bos> roll back an interrupted transaction
Okay, that takes care of the repository. But I meant both the
repository and working directory. (This goes back to my question above
about whether "update -C" is always safe. If it is, then I'm happy. If
not, then I think it would be something to investigate for the migration
plan.)
cheers
mike
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Bryan O'Sullivan
bos@serpentine.com
|
|
|
|
Re: Mercurial evaluation (interim) report
Posted:
Apr 3, 2006 4:19 PM
in response to: kupfer
|
|
On Mon, 2006-04-03 at 15:37 -0700, Mike Kupfer wrote:
> First, what happens when a pre-RevlogNG Mercurial reads a RevlogNG
> repository? What is the mechanism that ensures that the old Mercurial
> will quickly give up and not do anything that could corrupt the
> repository?
The signature on the revlog files won't check out, and Mercurial will
immediately abort.
> Second, does the revlog format change impact network operations?
No.
> For
> example, can a pre-RevlogNG Mercurial pull from a RevlogNG repository
> using HTTP or ssh?
Yes.
> Third, what happens if the revlog format entry in hgrc is changed back
> from 1 (RevlogNG) to 0 (classic revlog)?
The format entry in hgrc only affects the creation of new repositories.
So any repositories created with the flag set to 1 will be in the new
format, while any created with the flag unset or set to 0 will use the
current format.
> So
> given enough time and usage, I expect we *will* see repository
> corruption that the automated tools cannot handle.
We've already seen this happen with some people using bleeding-edge
Xen-based kernels :-) Quite often, the easiest thing to do is just drop
the corrupted repository and pick up again with another clone.
> bos> It's also possible to do the same kind of access control via ssh
> bos> without needing to create a pile of user accounts. There's a
> bos> recipe for doing this in the contrib directory of the source tree.
>
> Cool. You're talking about the SharedSSH page on the wiki, yes?
Yes.
> bos> You can configure Mercurial to ignore files either by putting a
> bos> .hgignore file in the repository, or adding a global or per-user
> bos> config option that tells it where to find other files that contain
> bos> ignore directives.
>
> Do the ignore directives only consider the file name, or do they look at
> the path?
Ignore and command line pattern options are very flexible. You can use
regular exprssions, shell-style globs, directory names (the implication
being that everything under the directory is specified in such cases),
or file names.
> bos> A Mercurial developer is working on a history-sensitive merge
> bos> extension that ought to reduce the likelihood of automated
> bos> mismerges, and should also eliminate the need to have RCS merge or
> bos> diff3 installed.
>
> That's good to know; thanks. Is this covered by issue12, or is that
> something else?
No, those are unrelated. I don't think we have a completely clean
solution to issue12 at hand, but that's probably due to developer
distraction rather than any inherent difficulty :-)
> bos> Mercurial has been modified since 0.8 to automatically detect and
> bos> break locks left behind by processes that were running during a
> bos> system crash or other catastrophe.
>
> Does it store more than just the pid? (How does it ensure safety when
> NFS is used?)
It used to store just the pid, but now it stores the hostname, too. It
fails conservatively (assuming the lock is valid) if it finds an
old-style lock that just contains the pid, so interoperability is
rpeserved.
> bos> Since there were two lock files left behind, Mercurial got killed
> bos> while populating the working directory. The state of the working
> bos> directory is trivial to fix by running the "update -C" command.
>
> Is this scriptable? That is, if both lock files are present, is "update
> -C" always a good thing to do?
That might make some sense. We should have a better way to detect and
recover from a corrupted dirstate file (the file that lets Mercurial
know what's in the working directory). I just filed issue199 against
this: http://www.selenic.com/mercurial/bts/issue199
> And can this be tied into the automatic
> breaking of locks that you mentioned?
Locks are always broken if it can be determined for sure that the locker
is dead, so there's no need to do anything there.
> Okay, that takes care of the repository. But I meant both the
> repository and working directory.
Yes, this should be covered by issue199.
<b
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
824
From:
US
Registered:
3/9/05
|
|
|
|
Re: Mercurial evaluation (interim) report
Posted:
Apr 5, 2006 4:29 PM
in response to: Bryan O'Sullivan
|
|
>>>>> "bos" == Bryan O'Sullivan <bos at serpentine dot com> writes:
bos> A Mercurial developer is working on a history-sensitive merge
bos> extension that ought to reduce the likelihood of automated
bos> mismerges, and should also eliminate the need to have RCS merge or
bos> diff3 installed.
Mike> That's good to know; thanks. Is this covered by issue12, or is
Mike> that something else?
bos> No, those are unrelated.
Is it covered by a different entry in the issue database, then? If it
is, I'd like to add myself to its notification list.
thanks,
mike
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Bryan O'Sullivan
bos@serpentine.com
|
|
|
|
Re: Mercurial evaluation (interim) report
Posted:
Apr 5, 2006 8:53 PM
in response to: kupfer
|
|
On Apr 5, 2006, at 4:29 PM, Mike Kupfer wrote:
> Is it covered by a different entry in the issue database, then? If it
> is, I'd like to add myself to its notification list.
No, the history-sensitive merge stuff isn't in the issue database.
Vadim (the author) has discussed it on the mailing list.
<b
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
804
From:
Plano, TX
Registered:
4/27/05
|
|
|
|
Re: Mercurial evaluation (interim) report
Posted:
Apr 3, 2006 1:15 AM
in response to: kupfer
|
|
On Fri, 31 Mar 2006, Mike Kupfer wrote:
> I've posted an interim evalution report for Mercurial at
>
> http://www.opensolaris.org/os/community/tools/scm/mercurial-eval.html
>
> Please send me any corrections, questions, or comments that you might
> have.
>
> I also took the liberty of posting Frank's interim git report at
>
> http://www.opensolaris.org/os/community/tools/scm/git-eval.txt
Has anyone followed up on the git list re the issues seen with 1.2.3 and
1.2.4?
Al Hopper Logical Approach Inc, Plano, TX. al@logical-approach.com
Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT
OpenSolaris.Org Community Advisory Board (CAB) Member - Apr 2005
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
107
From:
US
Registered:
12/2/05
|
|
|
|
Re: Mercurial evaluation (interim) report
Posted:
Apr 3, 2006 2:43 AM
in response to: alhopper
|
|
Al Hopper wrote:
> Has anyone followed up on the git list re the issues seen with 1.2.3 and
> 1.2.4?
The git maintainer is aware of the issue and is working on it.
However, for the evaluation, we're now committed to 1.2.2, redoing it
with 1.2.4 isn't feasible at this point.
- Frank
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
