Re: Mercurial "r####" numbers are not stable, use commit ids

Mats> Look for incoming tree here. Mats> http://www.selenic.com/mercurial/wiki/index.cgi/WorkingPractices Ah, right. Thanks. The master workspaces for the bits of Solaris that I work on are in the same building as my office, so I forgot about keeping a clone (incoming tree) for network performance reasons. Mats> I also find the practise of using incoming tree, "feature"-trees Mats> and outgoing tree a possible and good way to work although I have Mats> just a tiny experience with using it. Using MQ, named branches or Mats> other means to switch between different private tasks, as has been Mats> discussed, seems so complicated when just using the disc can do Mats> the trick. But I'm probably missing something here. I've used a distributed VCS (first Teamware, then Mercurial) since 1992. I, too, prefer separate workspaces over branches. I suspect that some of that preference is due to lack of support in Teamware for branches, plus my observation of CVS repositories that have an inpenetrable clutter of branches and tags. I don't use MQ for my personal repos, but I do use it for my XEmacs work. For example, I have a couple different patches for MH-E that I'll eventually submit upstream. One patch fixes the way MH-E looks for images (toolbar glyphs). Another patch fixes some MH-E macros so that they don't disable certain features just because they're not supported at compile time. I want to keep those separate so that they can be submitted and discussed individually. If I commit them as normal changesets, subsequent merges or refinements of the original patch can make it hard to extract out the exact patch for submission. cheers, mike _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta