Ar an dara lá de mí Eanair, scríobh Stephen J. Turnbull: We did have plenty of discussion about what revision control system to move to, it was not a decision made in haste. I am very happy with Mercurial. By the way, please don’t use branches when pushing to the trunk, when the rest of us do a hg fetch those branches are applied locally, and we have to explicitly merge with default if we want things to work intuitively. Search for bytecomp-coding-system-2008-10-29 in the output of hg log if you want to see an instance of this. (I suppose you could merge locally either, but make sure to actually do that!) I was talking to Matsl in IRC; I had been looking at the merge in http://hg.debian.org/hg/xemacs/xemacs?cs=4a7c4ccac2fe , using the trunk r-number, so yeah, the listed commits are correct. The code that struck me turned out to have been from this: http://hg.debian.org/hg/xemacs/xemacs?cs=726060ee587c If it was actually all mechanical, then it wasn’t that change that affected him, but I suspect there was some hand-coding to it. -- ¿Dónde estará ahora mi sobrino Yoghurtu Nghe, que tuvo que huir precipitadamente de la aldea por culpa de la escasez de rinocerontes? _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Mats Lidell writes: Yeah, but this confusion is pretty awful. Your repo may not differ from the public one, but an active developer's repo will likely be different. What's the point of distributed VC if you have to check with the central repo to find out what everybody is talking about? For an example, check out the tail of the output of the attached script with "./test-hg.sh 3". Pay attention to "bar" and "baz" and the parents of the merge. Are you sure those are the versions you tried? My changes should be in 4532:16906fefc8df because it's on the "bytecomp" branch. And in fact a diff of 4532:16906fefc8df against 4533:4a7c4ccac2fe shows no change. Similarly, a diff of 4532:16906fefc8df against 4534:f32c7f843961 shows only a trivial change. Well, that's what happened, but there's clearly confusion about the revisions we're talking about still. My guess is that the change in question is in lwlib/xlwmenu.c (this is a hunk from "hg diff -r 8418d1ad4944:726060ee587c", as Aidan suggested in another message). #ifdef USE_XFT_MENUBARS - {XtNfcFontName, XtCFcFontName, XtRString, sizeof (String), - offset(menu.fcFontName), - XtRString, (XtPointer) NULL}, + fontres (XtNfcFontName, XtCFcFontName, XtRString, String, fcFontName, + "sans-serif-12:bold"), /* #### This needs to be fixed to give a proper type and converter for XftFonts. See also xlwtabs.c. */ - {XtNxftFont, XtCXftFont, XtRString, sizeof(XtPointer), - offset(menu.xftFontName), XtRString, (XtPointer) "Helvetica-12:bold" }, + fontres (XtNxftFont, XtCXftFont, XtRString, XtPointer, xftFontName, + "Helvetica-12:bold"), #endif Note that I changed the default for fcFontName, which takes precedence over the xftFont in the current code. Try adding XEmacs*menubar*fcFontName: arial-6 (I think that's the font you were using), merging with xrdb, and restarting XEmacs. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Mats> Would it be asking too much if active developers keep one Mats> workspace that is a mere mirror from the public one? I think I Mats> even read somewhere that that was a recommended procedure with Mats> mercurial? I've never heard of that. I *have* read, many times, a recommendation to use the changeset ID (the hash), not the integer revision number, when you identify a changeset in a discussion with someone else. mike _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

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

on 01/12/2009 07:50 AM Stephen J. Turnbull said the following: Stephen's comment reminds me of a *HUGE* (in my mind) benefit of TeamWare, the version control system of SunPro's SPARCworks: all the databases were text files. So (a) you could figure out merely by looking what TeamWare was doing, and (b) if you made a misteak, you could compound your, er, you could fix your mistake by simply editing a text file. I have no idea if this applies to git or to any other version control system in common use, but if I were to design one, this would be a hard requirement. One could say that (X)Emacs embodies this approach (more or less) because most of (X)Emacs's functionality is in elisp files, which, of course, are just text. --- Vladimir -- Vladimir G. Ivanovic _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Mats Lidell writes: Well, no, I'm not, not in Mercurial. I'm clearly being pushed away from named branches and toward MQ or separate workspaces. It may be *possible* to do what I want to do in Mercurial, but it's clearly not a preferred (or even documented) work flow. Not really. They're either 3 orders of magnitude slower (full-tree diff) or require specifying the exact files. It may also require a checkout. But it's the specification of exact files and paths to repos that is the killer. On my iBook G4 1.33MHz it takes 1m10s according to time. But even 18 seconds is long enough to tempt me to go for a beer :-), compared to git's 18 microseconds to make a branch. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Vladimir G. Ivanovic writes: I rather doubt it on Mac OS X because of the startup overhead of the Python interpreter and module imports, while git is a C program (mostly). There might be no perceptible difference on systems with better disk performance. But definitely Mercurial has no speed advantage anywhere in my workflow. The tradeoff that the Mercurial designers chose was (a) implementation in a modern[1] somewhat OO garbage-collected language and (b) attention to keeping the UI straightforward vs. (c) coding at a low level in C for speed and (d) letting users shell-script their own UI. The Mercurial designers also did a lot of optimization for programs that are at least an order of magnitude bigger with two orders of magnitude more history than XEmacs. It certainly *was* true, and still *may* be, that some operations would be faster with Mercurial, and/or would require more manual maintenance (ie, git-repack and git-gc) than in Mercurial. But XEmacs isn't that big in either dimension. Footnotes: [1] YMMV. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

MikeK> Come to think of it, I remember seeing someone advertising a MikeK> pbranch extension that sounded like it might be closer to your MikeK> preferred workflow. And the extensions page mentions a MikeK> localbranch extension that might also be relevant. While catching up on Mercurial email today I also came across the Bookmarks extension[1], which is said to have been inspired by git branches. And unlike pbranch and localbranch, the bookmarks extension is bundled with Mercurial (v1.1). mike Footnotes: [1] http://selenic.com/pipermail/mercurial/2008-October/021749.html, http://www.selenic.com/mercurial/wiki/index.cgi/BookmarksExtension, http://blog.experimentalworks.net/2008/11/mercurial-bookmarks/ _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Stephen> Well, no, I'm not, not in Mercurial. OK. The tool doesn't allow you. Right. But you are free to have an idea of how you would like to work ;-) Lets hops some of the alternative mechanisms inside mercurial works out for you. I don't know a thing about git so I'm not advocating against it based on any technical grounds. I just feel that it would be worth testing some alternative ways inside of mercurial before we switch version control again. Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Aidan Kehoe <kehoea(a)parhasard.net&gt; writes: The advantage of VC is that you can use new version control systems from within Emacs/XEmacs without needing a clue about the differences. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Mats Lidell writes: No; that's what I'm currently doing for other reasons. But I think this is way suboptimal for identifying revisions. Too easy to forget which repo you're in, switching is a PITA, etc. That's the important thing. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta