James Carlson <james.d.carlson at sun.com> writes: > Richard Lowe writes: >> - The internals changed a little more than they have in the past, so >> catching cdm up is not as easy as it was previously, especially >> given that we're going to need to support 1.0.x with some overlap. > > It would be really nice to be able to base cdm on some stable > interfaces, so that we don't need new work every time there's a minor > (?) upgrade like this.
The simple answer is "Not really". The longer answer is that Mercurial have a page: http://www.selenic.com/mercurial/wiki/index.cgi/MercurialApi Which didn't exist at the time much of this was done. We don't stray *that* far outside of it, in general, but as the note at the top says, it is not really a *stable* API, and, in fact, that page documents 1.0, and two of the things there documented are things that changed in 1.1, that we have to adapt for (out of 4-ish). >> - Hg 1.0.2 cannot read a workspace created by Hg 1.1 via the local >> filesystem (over ssh it works, as long as 'hg' on the remote is 1.1, >> or --remotecmd is used). >> This would effectively mean that every machine you may access a >> given workspace from needs to get hg-1.1 at the same time. > > Can 1.1 read from 1.0.2 without trouble? Yes, at least in my experience. More thorough checking should, of course, be done before any upgrade happens. > As long as it can do that, this change just means that we need to > upgrade all the clients before we switch over the gates. It sounds > like a fairly run-of-the-mill internal ON flag day to me -- "make > sure you upgrade your hg client before XX/YY/ZZZZ, or you may lose > access to the gate via NFS." I was thinking of projects, whereby the machine holding their project gate may pickup Mercurial from SFW on the build it integrates, whereas consumers may not. But yes, it comes down to the same issue, loud, noticeable announcement. Thanks, -- Rich
