Thanks for your detailed responses! >>>>> "bos" == Bryan O'Sullivan <[EMAIL PROTECTED]> 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 [email protected]
