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 [email protected]
