2:51 a.m.
I like Mercurial a little less every day.
*Always* post the log messages or commit ID, *never* the r numbers.
The r numbers are *not stable* across repositories, and just confuse
the readers.
You can get the commit IDs with "hg log" or "hg id".
Somebody wrote to me:
Aidan thought one of your commits between r4532 and r4534 influenced
the handling of Xresource.
This is what I get, fingering Aidan, not me, amusingly enough.
(Amusing, because this isn't real evidence that Aidan had anything to
do with it. I have no idea what commits the OP's revisions 4532:4534
might refer to.)
$ hg log -r 4532:4534
changeset: 4532:16906fefc8df
branch: bytecomp-coding-system-2008-10-29
user: Aidan Kehoe <kehoea(a)parhasard.net>
date: Sun Dec 21 17:23:06 2008 +0000
summary: Return a list copy in #'built-in-face-specifiers,
pre-empting modification.
changeset: 4533:4a7c4ccac2fe
parent: 4527:8418d1ad4944
parent: 4532:16906fefc8df
user: Aidan Kehoe <kehoea(a)parhasard.net>
date: Mon Dec 22 12:05:47 2008 +0000
summary: Merge.
changeset: 4534:f32c7f843961
user: Aidan Kehoe <kehoea(a)parhasard.net>
date: Mon Dec 22 12:09:08 2008 +0000
summary: #'built-in-face-specifiers; document that we're returning
a copy.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
3:42 p.m.
Ar an dara lá de mí Eanair, scríobh Stephen J. Turnbull:
I like Mercurial a little less every day.
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!)
*Always* post the log messages or commit ID, *never* the r numbers.
The r numbers are *not stable* across repositories, and just confuse
the readers.
You can get the commit IDs with "hg log" or "hg id".
Somebody wrote to me:
> Aidan thought one of your commits between r4532 and r4534 influenced
> the handling of Xresource.
This is what I get, fingering Aidan, not me, amusingly enough.
(Amusing, because this isn't real evidence that Aidan had anything to
do with it. I have no idea what commits the OP's revisions 4532:4534
might refer to.)
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
1 a.m.
>>>> Stephen wrote:
Stephen> I like Mercurial a little less every day.
There is always a dark side I guess in every tool ...
Stephen> *Always* post the log messages or commit ID, *never* the r
Stephen> numbers. The r numbers are *not stable* across repositories,
Stephen> and just confuse the readers.
Even if the repository is updated by always pulling from
http://hg.debian.org/hg/xemacs/xemacs?
Stephen> You can get the commit IDs with "hg log" or "hg id".
OK. I'll correct myself.
Stephen> Somebody wrote to me:
(In case the rest of you haven't figured it out by now, yes, it was I
...)
> Aidan thought one of your commits between r4532 and r4534
influenced
> the handling of Xresource.
What I see is this. A build from
changeset: 4532:16906fefc8df
branch: bytecomp-coding-system-2008-10-29
tag: tip
user: Aidan Kehoe <kehoea(a)parhasard.net>
date: Sun Dec 21 17:23:06 2008 +0000
summary: Return a list copy in #'built-in-face-specifiers, pre-empting
modification.
works fine. A build from
changeset: 4533:4a7c4ccac2fe
tag: tip
parent: 4527:8418d1ad4944
parent: 4532:16906fefc8df
user: Aidan Kehoe <kehoea(a)parhasard.net>
date: Mon Dec 22 12:05:47 2008 +0000
summary: Merge.
does not.
However. I don't get this fully yet but it is getting clearer. Can it
be so that Aidan merged in your changes on branch
bytecomp-coding-system-2008-10-29 in the changeset 4533:4a7c4ccac2fe?
So they surfaced first there for me.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
4:54 a.m.
Mats Lidell writes:
Stephen> I like Mercurial a little less every day.
There is always a dark side I guess in every tool ...
Yeah, but this confusion is pretty awful.
Stephen> numbers. The r numbers are *not stable* across
repositories,
Stephen> and just confuse the readers.
Even if the repository is updated by always pulling from
http://hg.debian.org/hg/xemacs/xemacs?
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.
What I see is this. A build from
changeset: 4532:16906fefc8df
branch: bytecomp-coding-system-2008-10-29
summary: Return a list copy in #'built-in-face-specifiers
works fine. A build from
changeset: 4533:4a7c4ccac2fe
summary: Merge.
does not.
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.
However. I don't get this fully yet but it is getting clearer.
Can it
be so that Aidan merged in your changes on branch
bytecomp-coding-system-2008-10-29 in the changeset 4533:4a7c4ccac2fe?
So they surfaced first there for me.
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
12:34 a.m.
>>>> Stephen wrote:
Stephen> Your repo may not differ from the public one, but an active
Stephen> developer's repo will likely be different.
Would it be asking too much if active developers keep one workspace
that is a mere mirror from the public one? I think I even read
somewhere that that was a recommended procedure with mercurial?
But I acknowledge your concern here. Using procedure to stop you from
making mistakes will fail sometime. There is probably a good mercurial
shot-yourself-in-the-foot joke here somewhere.
Stephen> Are you sure those are the versions you tried?
I think so. I cloned with -r option and used diff on the resulting
files on the file system!
Stephen> My changes should be in 4532:16906fefc8df because it's on the
Stephen> "bytecomp" branch. And in fact a diff of 4532:16906fefc8df
Stephen> against 4533:4a7c4ccac2fe shows no change. Similarly, a diff
Stephen> of 4532:16906fefc8df against 4534:f32c7f843961 shows only a
Stephen> trivial change.
Yes, it has probably something to do with that 4532 is on the
branch. I've been reading the mercurial docs but haven't got it fully
yet, if possible ;-)
Stephen> Note that I changed the default for fcFontName, which takes
Stephen> precedence over the xftFont in the current code. Try adding
Stephen> XEmacs*menubar*fcFontName: arial-6
Stephen> (I think that's the font you were using), merging with xrdb, and
Stephen> restarting XEmacs.
Yes that works perfectly. Thanks! My fonts are back again!
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
1:31 a.m.
>>>> "Mats" == Mats Lidell
<matsl(a)xemacs.org> writes:
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
7:43 a.m.
Mats Lidell writes:
Would it be asking too much if active developers keep one workspace
that is a mere mirror from the public one?
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.
Stephen> Note that I changed the default for fcFontName, which
takes
Stephen> precedence over the xftFont in the current code. Try adding
Stephen> XEmacs*menubar*fcFontName: arial-6
Stephen> (I think that's the font you were using), merging with xrdb, and
Stephen> restarting XEmacs.
Yes that works perfectly. Thanks! My fonts are back again!
That's the important thing.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
11:55 p.m.
>>>> Mike wrote:
Mike> I've never heard of that.
Look for incoming tree here.
http://www.selenic.com/mercurial/wiki/index.cgi/WorkingPractices
I also find the practise of using incoming tree, "feature"-trees and
outgoing tree a possible and good way to work although I have just a
tiny experience with using it. Using MQ, named branches or other
means to switch between different private tasks, as has been
discussed, seems so complicated when just using the disc can do the
trick. But I'm probably missing something here.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
1:53 a.m.
>>>> "Mats" == Mats Lidell
<matsl(a)xemacs.org> writes:
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
3:50 p.m.
Mike Kupfer writes:
>>>>> "Mats" == Mats Lidell
<matsl(a)xemacs.org> writes:
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.
Well, you evidently don't feel obligated to keep dozens of separate
tasks in process. The maintainer does. It is definitely convenient
to be able to see diffs between any two branches instantaneously. And
creating an XEmacs branch with hg clone is *slow*. I'm simply not
going to do it as often as with git.
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.
In git you can manage that with mkdir (1) and mv(1).
Also, note that I do not keep all my XEmacs 21.5 work in a single
repository, and don't want to. I do want to have a small number of
repos.
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.
In hg, that is indeed true. In git, "no problema o menos." All you
have to do is remember the name of the branch.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
6:17 p.m.
on 01/12/2009 07:50 AM Stephen J. Turnbull said the following:
In git you can manage that with mkdir (1) and mv(1).
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
10:12 p.m.
>>>> Stephen wrote:
Stephen> Well, you evidently don't feel obligated to keep dozens of
Stephen> separate tasks in process. The maintainer does.
Acknowledged. I don't know what the maintainer needs to do. You are of
course free to use what method you think works best for you.
I do know that having simultaneous tasks in process in parallell is
really hard and should be avoided if possible.
Stephen> It is definitely convenient to be able to see diffs between
Stephen> any two branches instantaneously.
Ordinary diff tools can be used to cover up for that.
Stephen> And creating an XEmacs branch with hg clone is *slow*. I'm
Stephen> simply not going to do it as often as with git.
On my laptop it takes roughly 18s to clone.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
11:22 a.m.
Mats Lidell writes:
>>>>> Stephen wrote:
Stephen> Well, you evidently don't feel obligated to keep dozens of
Stephen> separate tasks in process. The maintainer does.
Acknowledged. I don't know what the maintainer needs to do. You are of
course free to use what method you think works best for you.
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.
I do know that having simultaneous tasks in process in parallell is
really hard and should be avoided if possible.
Stephen> It is definitely convenient to be able to see diffs
between
Stephen> any two branches instantaneously.
Ordinary diff tools can be used to cover up for that.
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.
Stephen> And creating an XEmacs branch with hg clone is *slow*.
I'm
Stephen> simply not going to do it as often as with git.
On my laptop it takes roughly 18s to clone.
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
11:04 p.m.
on 01/13/2009 03:22 AM Stephen J. Turnbull said the following:
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.
Designers make choices, and clearly Linus has chosen a design that
allows branches to be made very quickly. But, is there some other
common operation that takes longer in git than it does in Mercurial?
I'd expect that there is.
--- Vladimir
--
Vladimir G. Ivanovic
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
4:51 a.m.
>>>> "ST" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
ST> It may be *possible* to do what I want to do in Mercurial, but it's
ST> clearly not a preferred (or even documented) work flow.
You're probably right, but have you asked on the Mercurial user list?
There are probably more people there who use named branches, and they
might be able to give some workflow tips.
Come to think of it, I remember seeing someone advertising a pbranch
extension[1] that sounded like it might be closer to your preferred
workflow. And the extensions page mentions a localbranch extension[2]
that might also be relevant.
cheers,
mike
Footnotes:
[1] http://www.selenic.com/mercurial/wiki/index.cgi/PatchBranchExtension
[2] http://www.selenic.com/mercurial/wiki/index.cgi/LocalbranchExtension
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
10:25 a.m.
Vladimir G. Ivanovic writes:
Designers make choices, and clearly Linus has chosen a design that
allows branches to be made very quickly. But, is there some other
common operation that takes longer in git than it does in Mercurial?
I'd expect that there is.
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
4:54 a.m.
>>>> "MikeK" == Mike Kupfer
<mike.kupfer(a)xemacs.org> writes:
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
8:27 a.m.
Mike Kupfer writes:
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.
OK, I'll take a look at that.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
10:43 p.m.
>>>> Stephen wrote:
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
11:11 p.m.
Ar an cúigiú lá déag de mí Eanair, scríobh Mats Lidell:
[...] 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.
You’ll lose me if XEmacs switches to git, I don’t have time to learn a new
VCS. (Well, not that I have time to work on XEmacs anyway, but I still seem
to be committing.)
--
¿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
8:34 p.m.
Aidan Kehoe <kehoea(a)parhasard.net> writes:
Ar an cúigiú lá déag de mí Eanair, scríobh Mats Lidell:
> [...] 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.
You’ll lose me if XEmacs switches to git, I don’t have time to learn a new
VCS. (Well, not that I have time to work on XEmacs anyway, but I still seem
to be committing.)
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
12:16 a.m.
Ar an séú lá déag de mí Eanair, scríobh David Kastrup:
Aidan Kehoe <kehoea(a)parhasard.net> writes:
> You’ll lose me if XEmacs switches to git, I don’t have time to learn a new
> VCS. (Well, not that I have time to work on XEmacs anyway, but I still seem
> to be committing.)
The advantage of VC is that you can use new version control systems from
within Emacs/XEmacs without needing a clue about the differences.
The disadvantage of VC is that I would need to learn it, which does not
differentiate it from, say, git in the medium term.
--
¿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
5556
days inactive
5587
days old
21 comments
7 participants
participants (7)
-
Aidan Kehoe -
David Kastrup -
Mike Kupfer -
Stephen J. Turnbull -
Stephen J. Turnbull -
The XEmacs Package Smoketest -
Vladimir G. Ivanovic