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://www.selenic.com/mercurial/wiki/index.cgi/WireProtocol>, 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 [email protected]
