On the subject of Git, Bazaar, and the future of Emacs development

[John Wiegley]

Hello all,

We have often debated the merits of Git vs. Bazaar, and which one the GNU
project should use for Emacs development. I think now is an appropriate time
to revisit this decision.

My main reason for bringing this up again is that Bazaar development has
effectively stalled. There are major bugs which have been in their
bug-tracker for years now -- bugs affecting Emacs development, such as the
ELPA repository -- whach have been ignored all this time. There are also
other factors, but this one alone is significant enough that I think it
justifies us switching over to Git all by itself.

So, to Richard as the undisputed Czar of all things Emacs: can we now, pretty
please, switch to Git? :) I'm happy to coordinate whatever resources it takes
to make a full and faithful conversion from Bzr happen as soon as possible.

Yours,
John Wiegley

[Jordi Gutiérrez Hermoso]

Post by John Wiegley
My main reason for bringing this up again is that Bazaar development has
effectively stalled. There are major bugs which have been in their
bug-tracker for years now -- bugs affecting Emacs development, such as the
ELPA repository -- whach have been ignored all this time.

Let us also note that the ELPA repository is now in git due to this,
so part of Emacs development is already de jure in git, and lots of
other development is de facto done on git.

I still think git is a horrible DVCS, but at least it's maintained, unlike bzr.

- Jordi G. H.

[Stefan Monnier]

Post by Jordi Gutiérrez Hermoso
Let us also note that the ELPA repository is now in git due to this,

Actually, no, it's not using Git yet. But any help I can get to do that
would be welcome.


Stefan

[Karl Fogel]

Post by John Wiegley
We have often debated the merits of Git vs. Bazaar, and which one the GNU
project should use for Emacs development. I think now is an appropriate time
to revisit this decision.
My main reason for bringing this up again is that Bazaar development has
effectively stalled. There are major bugs which have been in their
bug-tracker for years now -- bugs affecting Emacs development, such as the
ELPA repository -- whach have been ignored all this time. There are also
other factors, but this one alone is significant enough that I think it
justifies us switching over to Git all by itself.
So, to Richard as the undisputed Czar of all things Emacs: can we now, pretty
please, switch to Git? :) I'm happy to coordinate whatever resources it takes
to make a full and faithful conversion from Bzr happen as soon as possible.

+1

Calling Bazaar a "GNU project" is becomes more meaningless the slower
Bzr's development gets. The last release candidate, 2.6b2, was in July
2012. That announcement said "2.6.0 is planned to be released in August
2012".

I understand that unplanned things can delay a major release -- this can
happen to any project. But it's a little more disturbing when there's a
cessation of "beta" releases *on the way* to the next major release. If
it's in the release testing process, then we should see successive beta
releases, not inactivity.

There are no announcements at all from after 24 July 2012, on the Bazaar
home page at http://bazaar.canonical.com/en/.

There is a small amount of activity in the bug tracker, but IMHO not
enough. For example, look at the "89 New Bugs" [1] and make sure to use
the little gear icon to turn on "Date Last Updated" and "Age" columns;
click either column to sort by that column. What you'll see is that
after the first 7 bugs, the next most recently filed new bug was filed
more than four months ago. Of the first 7, only a few have meaningful
responses (whether from a maintainer or otherwise).

The needle on the "project health meter" in my head is hovering down
near the low end of the dial.

As a minor package maintainer in Emacs, I would be better able to do my
job if the master Emacs sources were in Git. I don't use Bazaar for
anything else now, so it's just another slightly different command set
to remember. And it's clearly causing us trouble interacting with
packages whose upstream maintenance happens outside our tree, in git.

And for what? So we can say we're supporting a "GNU Project"? What a
fascinating vector for a DoS attack: call $FOO a GNU Project and get
Emacs to use it. Then don't maintain $FOO.

I like Bazaar, and personally like the people who work on it (many of
whom I've been lucky enough to meet). Canonical took a big risk
developing it, and Bzr may well still be the right tool for the import
of upstream sources into Launchpad for Ubuntu packaging. But for an
independent upstream like Emacs, git long ago became the right choice.
Maybe Emacs' decision to use Bazaar in order to support a fellow GNU
project was the right at one time... but surely that decision's
rightness can & should change based on changes in the status of Bzr and
Emacs' needs?

-Karl

[1] https://bugs.launchpad.net/bzr/+bugs?search=Search&field.status=New&orderby=-date_last_updated&start=0

[Juanma Barranquero]

The last release candidate, 2.6b2, was in July 2012.

And no Windows installer for that RC was ever built. RC2 has not been
tested on Windows, except perhaps by those that build their own Bazaar
(likely not many, as it isn't the easiest of targets to build to, I
think).

J

[Richard Stallman]

The maintainer says he is fixing some bugs, and I asked him
just yesterday to fix the ELPA branch bug.
I'd like to give him a reasonable time to do this.

[Thierry Volpiatto]

Post by Richard Stallman
The maintainer says he is fixing some bugs, and I asked him
just yesterday to fix the ELPA branch bug.
I'd like to give him a reasonable time to do this.

When next python version will be adopted by all distributions, expect
the amount of bugs in bzr to grow, and when python 3.++ will be adopted
expect bzr will not work anymore.

[Dmitry Gutov]

Post by Richard Stallman
The maintainer says he is fixing some bugs, and I asked him
just yesterday to fix the ELPA branch bug.

Isn't this a bit late? The bug is 1.5 years old. Was he not aware of it
before?

And considering that the decision to move ELPA to Git has already been
made, fixing that specific bug shouldn't make a difference. This
discussion is about Emacs core.

[Stephen J. Turnbull]

Post by Dmitry Gutov

Post by Richard Stallman
The maintainer says he is fixing some bugs, and I asked him
just yesterday to fix the ELPA branch bug.

Isn't this a bit late? The bug is 1.5 years old. Was he not aware of it
before?

No, true, yes, and Richard is aware of all those facts, I'm sure.
Good projects go dormant for years, sometimes. Richard knows and
accepts that. Obviously, he's trying to do something to reverse it in
this case because it's important to Emacs to have a good VCS.

Dmitry, please go back and review the original discussion that led to
selection of Bazaar. Everything you need to know will be in the
emacs-devel archives. While I strongly disagreed with that decision,
and equally strongly disagree with this one, Richard's position is
entirely consistent across time. If you're going to change his mind,
you're going to need to deal with his reasons, which already were
strong enough to overcome objections to Bazaar (which was much farther
behind git in almost all ways at that time). I myself don't have any
strong new reasons, sorry, so I can't help you.

[Allen S. Rout]

Post by Stephen J. Turnbull
please go back and review the original discussion that led to
selection of Bazaar. [...]

Might some kind soul decorate this with e.g. a GMANE reference or other
similar?

- Allen S. Rout

[Dmitry Gutov]

Post by Allen S. Rout

Post by Stephen J. Turnbull
please go back and review the original discussion that led to
selection of Bazaar. [...]

Might some kind soul decorate this with e.g. a GMANE reference or other
similar?

If I found the right discussion, these two messages:

http://thread.gmane.org/gmane.emacs.devel/90798/focus=92070
http://thread.gmane.org/gmane.emacs.devel/90798/focus=91330

seem to indicate that Bazaar was considered a good enough tech at the
time, and that politics were coming second, or at least were not an
overriding factor.

If Bazaar had been in bad shape even then, I don't see anyone mentioning
that in the discussion (admittedly, I haven't read every message).

[Stephen J. Turnbull]

Post by Dmitry Gutov
http://thread.gmane.org/gmane.emacs.devel/90798/focus=92070
http://thread.gmane.org/gmane.emacs.devel/90798/focus=91330
seem to indicate that Bazaar was considered a good enough tech at the
time, and that politics were coming second, or at least were not an
overriding factor.

I read your citations as indicating exactly the opposite. Especially
in context of the actual discussion, where the technical demands for
"good enough" were minimized.

In any case, here's the original thread started by Eric Raymond, where
Richard says from the get-go that the determining factor is GNU-ness:

http://thread.gmane.org/gmane.emacs.devel/85669/focus=85669

Post by Dmitry Gutov
If Bazaar had been in bad shape even then, I don't see anyone
mentioning that in the discussion (admittedly, I haven't read every
message).

It was known at the time that Bazaar's current version was slow and
repos were bloated. (Part of why Python rejected it in March 2009, a
year later. See http://www.python.org/dev/peps/pep-0374/#decision and
the following discussion.) The thread starting at msg 85669 on Gmane
also provides plenty of evidence that Bazaar performed poorly compared
to git and Mercurial.

The fact is that Bazaar is much better now than it was then. It's
quite usable in a project the size of Emacs these days.[1] That's why
I say you're not going to change Richard's mind without much stronger
reasons than any I know of at this date.

Footnotes:
[1] Assuming you haven't already decided that you need git. ;-)

[Richard Stallman]

Post by Richard Stallman
The maintainer says he is fixing some bugs, and I asked him
just yesterday to fix the ELPA branch bug.

Isn't this a bit late? The bug is 1.5 years old. Was he not aware of it
before?

The point is, I am trying to determine whether Bzr is effectively
maintained or not. I'd rather get a Yes answer than a No answer.

[Juanma Barranquero]

Post by Richard Stallman
The point is, I am trying to determine whether Bzr is effectively
maintained or not.

The answer to that question should be obvious by looking at the public
repository and developers' list. Perhaps they are maintaing it
internally, or perhaps they intend to maintain it again in the (near
or not-so-near) future. But right now, and for quite a while, the
answer to "is effectively maintained?" cannot be other than "not".

J

[John Yates]

I am surprised no one has mentioned in this thread the parade of
erstwhile bzr developers (including Martin Pool) who have admitted on
the bzr mailing list that they have abandoned the project and why.
Richard, can I assume that you are familiar with at least some of
these posting?

/john

Post by Juanma Barranquero

Post by Richard Stallman
The point is, I am trying to determine whether Bzr is effectively
maintained or not.

The answer to that question should be obvious by looking at the public
repository and developers' list. Perhaps they are maintaing it
internally, or perhaps they intend to maintain it again in the (near
or not-so-near) future. But right now, and for quite a while, the
answer to "is effectively maintained?" cannot be other than "not".
J

[Werner LEMBERG]

Post by John Yates
I am surprised no one has mentioned in this thread the parade of
erstwhile bzr developers (including Martin Pool) who have admitted on
the bzr mailing list that they have abandoned the project and why.
Richard, can I assume that you are familiar with at least some of
these posting?

For example here:

http://stationary-traveller.eu/pages/bzr-a-retrospective.html


Werner

[Richard Stallman]

I am surprised no one has mentioned in this thread the parade of
erstwhile bzr developers (including Martin Pool) who have admitted on
the bzr mailing list that they have abandoned the project and why.

I know that Martin Pool no longer works on Bzr. He never told me why,
but I think that Canonical decided to stop funding its development
very much.

I don't have time to read the Bzr mailing list. Or any development
mailing list. The only such list I am on is this one, and the only
reason I can be on this ls is that I don't follow most of the questions
that come up. You might as well tell me to fly to the moon as tell
me to read something on the Bzr list.

I read http://stationary-traveller.eu/pages/bzr-a-retrospective.html
before. It says many useful things but does not say anything about
the crucial question: whether Bzr is maintained enough or not.

[Leo Liu]

Post by Richard Stallman
I don't have time to read the Bzr mailing list. Or any development
mailing list. The only such list I am on is this one, and the only
reason I can be on this ls is that I don't follow most of the questions
that come up. You might as well tell me to fly to the moon as tell
me to read something on the Bzr list.

Exactly. Your time will be better spent on issues other than BZR.

Most GNU projects aren't using BZR as you might be aware. While helping
BZR fixing bugs might be a gain for BZR, it is a loss as a whole for
GNU. Volunteers spend their spare time on GNU projects and if 20% of
that time is taken up by wrestling with BZR, it becomes costly to the
point discouraging people from joining.

For the greater good of GNU, move off BZR seems like the only sound
choice.

Leo

[j***@verona.se]

Post by John Yates
I am surprised no one has mentioned in this thread the parade of
erstwhile bzr developers (including Martin Pool) who have admitted on
the bzr mailing list that they have abandoned the project and why.
I know that Martin Pool no longer works on Bzr. He never told me why,
but I think that Canonical decided to stop funding its development
very much.
I don't have time to read the Bzr mailing list. Or any development
mailing list. The only such list I am on is this one, and the only
reason I can be on this ls is that I don't follow most of the questions
that come up. You might as well tell me to fly to the moon as tell
me to read something on the Bzr list.
I read http://stationary-traveller.eu/pages/bzr-a-retrospective.htmlbefore. It says many useful things but does not say anything about
the crucial question: whether Bzr is maintained enough or not.

Isn't it a reasonable position that the users of bzr have say in wether
bzr is sufficiently maintained or not?

I have done my best to be a constructive user of the tool, and I have
had many technical difficulties. When I try to find solutions to the
issues I notice the following:

- The bzr community is very helpful. This is good.

- There are many well known bugs. There are also many well known patches
for these, some of them provided by Emacs developers. They never enter
upstream. By "never" I mean years. This is bad.

The situation generates a lot of frustration.

Anyway, from here one can discuss solutions. I think most of them have
been discussed more than once. Heres my take:

- Accept losses with bzr. Life goes on.
- Use Git as a technical interim solution.
- Incrementally produce a GNU-Git, which is maintained by GNU
The initial versions of this new implementaiton could use libgit2, which
is LGPLV2. Eventually the library could be rewritten as GPLV3 if deemed
necessary. (OTOH using libgit2 doesnt seem worse than using Python as
bzr does), The new implementation could also use Guile, which would
support an important GNU project.

So, thats IMHO a reasonable idea. I only have very small resources to
devote personally towards it though.

[Thien-Thi Nguyen]

() ***@verona.se
() Thu, 28 Mar 2013 08:53:01 +0100

Heres my take:

[...]
- Incrementally produce a GNU-Git, which is maintained by GNU

The initial versions of this new implementaiton could use libgit2,
which is LGPLV2. Eventually the library could be rewritten as GPLV3
if deemed necessary. (OTOH using libgit2 doesnt seem worse than using
Python as bzr does), The new implementation could also use Guile,
which would support an important GNU project.

Recently, Guile-SDL was accepted as a GNU project (transition wip,
announcement RSN). It wraps libsdl (and friends) for Guile 1.4 and up.

I imagine the wrapping of libgit2 would entail similar work and hereby
volunteer to mentor anyone who steps forward on the techniques Guile-SDL
uses. (The majority of the hair is Guile-version-specific shimming.)

Like Guile-SDL, i think Guile-Git (or whatever) would be best if started
as non-GNU and GPLv3+, and only after some refinement worry about being
accepted as GNU. The important part is the GPLv3+.

I only have very small resources to
devote personally towards it though.

I know what you mean. Everyone should be warned that my mentoring style
is best-suited for those who probably don't need a mentor. :-D

Please, let's continue this on the guile-user list.

[Richard Stallman]

Isn't it a reasonable position that the users of bzr have say in wether
bzr is sufficiently maintained or not?

When I have to decide whether a maintainer is doing an adequate job or
needs to be replaced, I pay attention to whatever relevant information
I get. However, to give users "a say" in the decision seems improper,
so I don't do that.

- Incrementally produce a GNU-Git, which is maintained by GNU

Could you explain what you are proposing? A fork of Git?
A replacement for Git?

As of now I don't know of a reason to do either of those things.

[Karl Fogel]

Post by Richard Stallman
I know that Martin Pool no longer works on Bzr. He never told me why,
but I think that Canonical decided to stop funding its development
very much.
I don't have time to read the Bzr mailing list. Or any development
mailing list. The only such list I am on is this one, and the only
reason I can be on this ls is that I don't follow most of the questions
that come up. You might as well tell me to fly to the moon as tell
me to read something on the Bzr list.
I read http://stationary-traveller.eu/pages/bzr-a-retrospective.html
before. It says many useful things but does not say anything about
the crucial question: whether Bzr is maintained enough or not.
The answer to that question should be obvious by looking at the
public repository and developers' list.
I can't do that -- it is too big a job. I have to find out in ways
that take less time. I am working more than 10 hours a day.

Well, really, you don't have time to pay close enough attention to Bzr
development to competently decide whether it's still a good choice for
Emacs. That's fine -- no one has time to do every important thing, and
you do many other important things.

But then why do you think you still have the time & mental bandwidth to
make this decision well? Why not delegate it to the Emacs maintainers
on the grounds that you no longer have time to do a good job of this
evaluation? You delegate other things. Why is this special?

Post by Richard Stallman
I hope you understand that before I take the drastic step of giving up
on a package, I need to be convinced there is no hope. People on this
list are proposing that I give up after a snap judgment based on a
weaker criterion. I won't do that. The advice which suggests I do that
is not useful or relevant.

The idea that asking one person about one bug will answer the question
"Is Bzr maintained enough?" is wrong. Even if someone responds and
fixes that one bug, that does not mean there is hope. To correctly
assess the chances of hope, you have to look at the overall situation --
which others here have already done, in greater depth and taking more
variables into account than you can. Many people in this thread,
including myself, have already done a more thorough investigation into
the question than you are able to do, given your time constraints, and
most have come to the same conclusion.

Post by Richard Stallman
The help that I need, to make the decision, is to give me the
corrdinates of the specific Bzr bug report about the ELPA branch.
There should be someone on this list for whom that would be quick and
easy.

https://bugs.launchpad.net/bzr/+bug/830947, as Eli pointed out later in
the thread.

The most recent comment on that bug is from November of last year. In
https://code.launchpad.net/~rrw/bzr/830947-tree-root-exception there is
a patch (not landed in mainline; there is no estimate of whether the
patch is ready to land in mainline, nor when it would happen if so).
Bug 937101 also gives a workaround recipe in comment #11.

But this one-bug approach is a bad way to evaluate overall project
health. A single bug is not a proxy for project health. A collection
of data points is. If you don't have time to evaluate that collection,
and don't have time to trust those who have done so, then your chances
of making a good decision are essentially random.

-Karl

[Richard Stallman]

But then why do you think you still have the time & mental bandwidth to
make this decision well? Why not delegate it to the Emacs maintainers

Because more than Emacs is at stake here.

[Juanma Barranquero]

Post by Richard Stallman
Because more than Emacs is at stake here.

Have the Bazaar developers (or Canonical) ever given more than lip
service to Bazaar being a GNU project?

J

[Richard Stallman]

The answer to that question should be obvious by looking at the public
repository and developers' list.

I can't do that -- it is too big a job. I have to find out in ways
that take less time. I am working more than 10 hours a day.

The maintainer says he and others fix bugs. I have asked him to fix a
specific bug. Would someone please help, by pointing him at the report
for that bug?

[Juanma Barranquero]

Post by Richard Stallman
I can't do that -- it is too big a job.

My point is not that you should spend time on it, but that it is
painfully evident for those of us that do follow the Bazaar
developers' list.

Post by Richard Stallman
The maintainer says he and others fix bugs. I have asked him to fix a
specific bug.

Even if the maintainers fix these bugs by your request, that means
nothing IMHO. There seems to be no long-term commitment, and without
that, the Bazaar development community doesn't seem very healthy right
now.

Juanma

[Stefan Monnier]

Post by Juanma Barranquero
Even if the maintainers fix these bugs by your request, that means
nothing IMHO.

Indeed. We have already pleaded to fix this bug several times.


Stefan

[Richard Stallman]

My point is not that you should spend time on it, but that it is
painfully evident for those of us that do follow the Bazaar
developers' list.

_Some_ conclusion is painfully evident to you, but it is not clear
what your conclusion implies for the decision I face. We are, in
essence, miscommunicating.

Even if the maintainers fix these bugs by your request, that means
nothing IMHO.

I hope you understand that before I take the drastic step of giving up
on a package, I need to be convinced there is no hope. People on this
list are proposing that I give up after a snap judgment based on a
weaker criterion. I won't do that. The advice which suggests I do that
is not useful or relevant.

The help that I need, to make the decision, is to give me the
corrdinates of the specific Bzr bug report about the ELPA branch.
There should be someone on this list for whom that would be quick and
easy.

Without this help, my decision will be stuck in the same limbo where
it has been stuck for some months. Please help me out.

[John Wiegley]

I hope you understand that before I take the drastic step of giving up on a
package, I need to be convinced there is no hope. People on this list are
proposing that I give up after a snap judgment based on a weaker criterion.
I won't do that. The advice which suggests I do that is not useful or
relevant.

I think your approach here is perfectly reasonable, Richard, and commendable.
It is not a decision to be taken lightly -- especially since you'd be choosing
to replace the use of a GNU project with a non-GNU one -- so I'll help you
gather whatever evidence you need.

The Bazaar bug in question, concerning bzr and ELPA, is here:

https://bugs.launchpad.net/bzr/+bug/937101

John

[Eli Zaretskii]

Date: Thu, 28 Mar 2013 19:26:58 +0000
https://bugs.launchpad.net/bzr/+bug/937101

It is a duplicate of

https://bugs.launchpad.net/bzr/+bug/830947

[Richard Stallman]

The Bazaar bug in question, concerning bzr and ELPA, is here:

https://bugs.launchpad.net/bzr/+bug/937101

Thanks. That looks like exactly what I need.

[Eli Zaretskii]

Date: Thu, 28 Mar 2013 14:58:52 -0400
The help that I need, to make the decision, is to give me the
corrdinates of the specific Bzr bug report about the ELPA branch.
There should be someone on this list for whom that would be quick and
easy.
Without this help, my decision will be stuck in the same limbo where
it has been stuck for some months. Please help me out.

Sorry, I wasn't aware that you still didn't identify the bug. Here it
is:

https://bugs.launchpad.net/bzr/+bug/830947

A duplicate was reported here:

https://bugs.launchpad.net/bzr/+bug/1099209

[Allen S. Rout]

Post by Richard Stallman
The point is, I am trying to determine whether Bzr is effectively
maintained or not. I'd rather get a Yes answer than a No answer.

I'm a 20-year lover of Emacs, though only the most negligible
contributor. It might be appropriate for my two cents to be ignored by
this assemblage, but here it is.

If RMS must make a personal appeal to generate action at this moment,
even if action is forthcoming, that action cannot reasonably be laid to
the general credit of the Bzr project.

The "maintained" state of a project is not determined by response to a
single bug, but by ongoing availability and responsiveness. Waiting
for maintainer interest to decay again so that the situation is again
unambiguous is IMO a waste of time. A 5 year sample (the conversation
from March 2008) to now seems sufficient rope.


- Allen S. Rout

[Josh]

Post by Allen S. Rout
I'm a 20-year lover of Emacs, though only the most negligible
contributor. It might be appropriate for my two cents to be ignored by
this assemblage, but here it is.

Two more cents from another casual contributor: though I have
completed the copyright assignment paperwork and made a couple of
commits to the trunk, my experience in getting my Bzr environment set
up and pushing those commits was burdensome enough that I've been
reluctant to go through that process again in order to commit the
handful of other improvements and bug fixes that are now locked away
in my init file and thus of no use to anyone but me and people with
whom I share the code directly. I personally would contribute more if
the Emacs source code were managed by Git, not because it is best
technically -- which indeed it may not be as Jordi so often asserts :)
-- but because it's familiar to me and thus I'd have more time
available to improve Emacs instead of battling an unfamiliar, niche,
seemingly moribund VCS.

Based on numerous comments that I've seen in #emacs over the years, I
suspect that many other casual and potential contributors are of like
mind and are less engaged with Emacs development as they might be were
Emacs to use a more mainstream VCS. It seems to me that Emacs and the
GNU project as a whole would be best served by making it as easy as
possible for newcomers to join our community, and that migrating to
Git would go a long way toward doing so.

Post by Allen S. Rout
The "maintained" state of a project is not determined by response to a
single bug, but by ongoing availability and responsiveness. Waiting
for maintainer interest to decay again so that the situation is again
unambiguous is IMO a waste of time. A 5 year sample (the conversation
from March 2008) to now seems sufficient rope.

+1

[Stefan Monnier]

Post by Richard Stallman
The maintainer says he is fixing some bugs, and I asked him
just yesterday to fix the ELPA branch bug.
I'd like to give him a reasonable time to do this.

I'm not interested. GNU ELPA will move to Git, which will make lots of
things easier since it merges from various external branches, 99% of
which use Git (which currently forces me to do a good bit of gymnastics
to use bzr-git and then work around some of its limitations, which will
never be fixed because they can't really be called bugs).


Stefan

[Richard Stallman]

Post by Richard Stallman
The maintainer says he is fixing some bugs, and I asked him
just yesterday to fix the ELPA branch bug.
I'd like to give him a reasonable time to do this.

I'm not interested.

It is important for the GNU Project to see if we can get Bzr
bugs fixed. If you reported the bug, could you tell him
enough to see which bug this is?

[Stefan Monnier]

It is important for the GNU Project to see if we can get Bzr bugs fixed.

Whether we can, in theory, is not very important. As for practice,
I know that we can't, at least not without devoting way too many resources.


Stefan "who generally likes Bzr and uses it for all his own branches"

[John Wiegley]

It is important for the GNU Project to see if we can get Bzr bugs fixed. If
you reported the bug, could you tell him enough to see which bug this is?

Richard, I think the fact that we've had to involve you in order to carry the
weight we need to get this bug fixed, is the very point. Bzr is not advancing
well enough on its own to deserve to be our VCS.

John

[Bastien]

Post by Richard Stallman
It is important for the GNU Project to see if we can get Bzr
bugs fixed.

If GNU developers were asked to use GNU Hurd and to wait for Hurd
bugs to be fixed because it is important to see if we can get them
fixed, I don't think anyone would find it is an efficient way of
supporting the GNU project--because the kernel is a central piece,
and its limitations would affect our ability to contribute to GNU.

I think the same argument applies to bzr as a dVCS: it is not just
another GNU software, it's the software that we use the most often
after Emacs.

[Richard Stallman]

If GNU developers were asked to use GNU Hurd and to wait for Hurd
bugs to be fixed

If the GNU Hurd were as usable and developed as Bzr is,
I might well give that approach a try to get the Hurd into use.

[chad]

For whatever reason, these bugs are no longer found by launchpad's
search function (for me, at least - launchpad suffered several
`temporary errors' while I tried to find these). There is, as far
as I know, no way to look at these without using a web browser.

The bug in question is 18 months old:

https://bugs.launchpad.net/bzr/+bug/830947

It was re-reported by emacs developers more than a year ago:

https://bugs.launchpad.net/bzr/+bug/937101

Almost exactly a year ago, the bazaar people downgraded the bug
importance from `High' to `Low'. Multiple requests from Chong
Yidong since then have gone unanswered.

In the interest of helping you determine if the project as a whole
is actively maintained or not, it's worth pointing out the current
announcement from the bazaar team:

https://launchpad.net/bzr/+announcement/10362
"2.6.0 is planned to be released in August 2012."

Looking at the branch of bzr marked as "the current focus of
development", there are 66 branches proposed for merging (i.e.
there's lots of patches waiting to be examined and either rejected
or accepted). There is exactly one change to the current dev tree
this year, that makes their test suite work with last October's
Ubuntu release. The most recent change that looks (to my non-expert
eyes) to be an actual code change is ~6 months old.

https://code.launchpad.net/~bzr-pqm/bzr/bzr.dev

I hope that helps.
~Chad

[Bastien]

Post by Bastien
If GNU developers were asked to use GNU Hurd and to wait for Hurd
bugs to be fixed
If the GNU Hurd were as usable and developed as Bzr is,
I might well give that approach a try to get the Hurd into use.

If GNU Hurd were as usable and developed and *unmaintained* as bzr,
then my guess is that it would be hard to convince GNU contributors
to use it.

I'm all for considering the GNU project as a whole, and supporting
other GNU projects is a good goal. But IMO this goal should not
hurt the whole dynamic: relying on unmaintained software (or poorly
maintained) is just... depressing.

If Mercurial (or another dVCS) is good enough, well maintained,
willing to become a GNU project and to use GPLv3+--I'd be glad to
learn it and to use it for Emacs.

[Michael Welsh Duggan]

Post by John Wiegley
We have often debated the merits of Git vs. Bazaar, and which one the GNU
project should use for Emacs development. I think now is an appropriate time
to revisit this decision.

I see these Git versus Bazaar arguments pop up every now and then on
this forum. I must admit my experience with Git has been better than
that with Bazaar, but I have to ask, why isn't Mercurial being
considered?

[Leo Liu]

Post by Michael Welsh Duggan
I see these Git versus Bazaar arguments pop up every now and then on
this forum. I must admit my experience with Git has been better than
that with Bazaar, but I have to ask, why isn't Mercurial being
considered?

[Stephen J. Turnbull]

Post by Michael Welsh Duggan
I see these Git versus Bazaar arguments pop up every now and then on
this forum. I must admit my experience with Git has been better than
that with Bazaar, but I have to ask, why isn't Mercurial being
considered?

Nobody in the community is using it to develop Emacs, would be the
reason I expect.

Mercurial is perfectly serviceable, XEmacs and Python both use it.
However, it really isn't as powerful or coherent as git, and the DAGs
it creates tend to be rather ugly unless you have a standard
project-wide workflow. The lack of a good colocated branch story[1]
hurts in many workflows (as indeed it does in Bazaar). Nobody does
submodules well yet, but I'll bet git gets there first because git's
implementation is such a natural extension of Linus's original model.

Despite the constant criticism of git's command-line UI[2], IMO it's a
red herring for Emacs use[3]. In git's favor, git has a powerful
(though incomplete in some respects[4]) model of version control,
consistently applies it, and exposes its full power to all users.
Perhaps that resembles an editor you know? Not to mention that the
operation of "commit", basic to all version control, is implemented by
adding a link to the head of a singly-linked list. Does that resemble
a programming language you've heard of?[5]

Now it's true that perhaps the majority of Emacs developers want a VCS
that just stays out of their way. Bazaar and Mercurial are better
choices for that, it seems, but only if you restrict yourself to the
CLI. But I think that that desideratum will be more than adequately
satisfied via Lisp interfaces to git[3]. OTOH, there is a large
contingent of Emacs developers whose preferred VCS is git for various
reasons.

Of course, I've long been a git advocate, so the above is a selective
account of the merits and demerits. Nevertheless, HTH.

Footnotes:
[1] IMHO YMMV.

[2] Which criticism I admit I have no sympathy for. Of the plethora
of commands, I admit I use quite a few (16 = init, add, rm, mv,
commit, status, log, diff, pull, push, branch, checkout, reset, gitk,
tag, help) frequently, but I rarely use options other than -m and -F
to commit, -b to checkout, and -<number> to log. I suppose you
noticed "help", well, (a) I advise people on git a lot and need to
refer to help for workflows I don't use, and (b) I grant that
infrequently used commands like rebase are indeed complex, but their
power more than justifies the time to refer to help. But I suppose
that's just me. ;-)

I think that one big problem is not the CLI per se, but that
people who have a non-git mental model of VCS have great trouble
making sense of the way branch, checkout, and reset interact. Also,
many people dislike git's practice of counting versions "backward"
from HEAD rather than "forward" from the repository root.

[3] You've heard of vc.el and magit, I suppose?

[4] Rename and first-class directory support.

[5] The analogy is not perfect, of course, because a cons can have
only one cdr, while to implement merges a git commit is allowed to
have multiple parents.

[John Wiegley]

I see these Git versus Bazaar arguments pop up every now and then on this
forum. I must admit my experience with Git has been better than that with
Bazaar, but I have to ask, why isn't Mercurial being considered?

[Romain Francoise]

I think Git presents us with a pretty good answer to each of these
points, in terms of Emacs development.

You can work on Emacs using Git today, the Git mirror is an accurate
conversion of what's in Bazaar and is updated at a reasonable frequency.
When I did the ACL stuff last year I had everything in Git and only used
Bazaar once, to install my changes (after several rounds of review).

I hate to play devil's advocate, I'm all for a switch to Git. But at least
from my experience, having the code in Bazaar is only a minor
inconvenience. I imagine that the same would apply to a majority of
potential contributors if we just encouraged people to use the Git mirror
instead of Bazaar.

[Jordi Gutiérrez Hermoso]

Post by Michael Welsh Duggan

Post by John Wiegley
We have often debated the merits of Git vs. Bazaar, and which one the GNU
project should use for Emacs development. I think now is an appropriate time
to revisit this decision.

I see these Git versus Bazaar arguments pop up every now and then on
this forum. I must admit my experience with Git has been better than
that with Bazaar, but I have to ask, why isn't Mercurial being
considered?

[Carsten Dominik]

Post by John Wiegley
Hello all,
We have often debated the merits of Git vs. Bazaar, and which one the GNU
project should use for Emacs development. I think now is an appropriate time
to revisit this decision.
My main reason for bringing this up again is that Bazaar development has
effectively stalled. There are major bugs which have been in their
bug-tracker for years now -- bugs affecting Emacs development, such as the
ELPA repository -- whach have been ignored all this time. There are also
other factors, but this one alone is significant enough that I think it
justifies us switching over to Git all by itself.
So, to Richard as the undisputed Czar of all things Emacs: can we now, pretty
please, switch to Git? :) I'm happy to coordinate whatever resources it takes
to make a full and faithful conversion from Bzr happen as soon as possible.

For what it is worth, I believe that the Org-mode community
would wholeheartedly support such a move, it would simplify things
for us enormously.

With kind regards

- Carsten Dominik

[Julien Danjou]

Post by John Wiegley
We have often debated the merits of Git vs. Bazaar, and which one the GNU
project should use for Emacs development. I think now is an appropriate time
to revisit this decision.
My main reason for bringing this up again is that Bazaar development has
effectively stalled. There are major bugs which have been in their
bug-tracker for years now -- bugs affecting Emacs development, such as the
ELPA repository -- whach have been ignored all this time. There are also
other factors, but this one alone is significant enough that I think it
justifies us switching over to Git all by itself.

I strongly support this initiative.

[Ted Zlatanov]

Post by John Wiegley
We have often debated the merits of Git vs. Bazaar, and which one the GNU
project should use for Emacs development. I think now is an appropriate time
to revisit this decision.

JD> I strongly support this initiative.

I support it, likewise. We've had technical developments since Bazaar
was chosen:

- magit.el has matured; VCS mode has improved Git support

- Git credential helpers let the user get and store authentication
tokens to external facilities like the Mac OS X or W32 keychain (I
wrote one to talk to a netrc file with or without GPG encryption,
allowing Git and Emacs' auth-source.el to share the same netrc file)

- I am not aware of any projects choosing Bazaar for any reason,
technical or not, since RMS' decision.

- the Gnus project has a person dedicated to Bazaar-Git bidirectional
synchronization; it is a very demanding task for the rest of us.

Ted

[David Engster]

Post by Ted Zlatanov
- I am not aware of any projects choosing Bazaar for any reason,
technical or not, since RMS' decision.

CEDET.

OK, not a great data point, I admit that. :-)

I think bzr is good enough (and much, *much* better than during the time
Emacs switched to it), and I could live with bzr being in maintenance
mode if it was actually rock-solid. However, next to the obvious ELPA
branch bug, it also seems the conflict handling during merges is still
problematic. I hit such a bug, and it would have been a showstopper if
some nice guy from the bzr mailing list hadn't shown me a workaround:

https://lists.ubuntu.com/archives/bazaar/2012q3/075253.html

What also worries me is that our CEDET repository seems to have become
nonconvertible during the merges, and development on the 'Fast Import'
plugin seems to have stalled as well, so I don't think bugs like
https://bugs.launchpad.net/bzr-fastimport/+bug/1057534 will ever get
fixed. Therefore, I'm not sure we could even switch to git if we wanted
to. It is also very unfortunate that for this reason we cannot provide a
git mirror, which I consider to be important for attracting developers
in the first place.

Post by Ted Zlatanov
- the Gnus project has a person dedicated to Bazaar-Git bidirectional
synchronization; it is a very demanding task for the rest of us.

Well, I don't believe that git will make cross-project merges easier, at
least not until someone shows me how (and don't just say "submodules",
please ;-) ).

-David

[Ted Zlatanov]

Post by Ted Zlatanov
- the Gnus project has a person dedicated to Bazaar-Git bidirectional
synchronization; it is a very demanding task for the rest of us.

DE> Well, I don't believe that git will make cross-project merges easier, at
DE> least not until someone shows me how (and don't just say "submodules",
DE> please ;-) ).

The challenge for me is matching Bazaar and Git commits and
synchronizing them because I don't know Bazaar and don't use it for any
other purpose. I am pretty sure that's the case for the rest of the
Gnus contributors (Julien is one of them; Lars doesn't like Bazaar much
IIRC; we chose Git over Bazaar years ago and have not regretted it).

For this specific case, `git filter-branch' will probably be used to
rewrite paths the way you describe, but that's a technical detail.
Git-Git sync is just much easier logistically.

Ted

[Julien Danjou]

Post by David Engster
Well, I don't believe that git will make cross-project merges easier, at
least not until someone shows me how (and don't just say "submodules",
please ;-) ).

I'm pretty sure it does make this easier:

http://git-scm.com/book/en/Git-Tools-Subtree-Merging

[Stefan Monnier]

Post by Julien Danjou

Post by David Engster
Well, I don't believe that git will make cross-project merges easier, at
least not until someone shows me how (and don't just say "submodules",
please ;-) ).

http://git-scm.com/book/en/Git-Tools-Subtree-Merging

The core of the problem is bidirectional merging. AFAIK none of the
current DVCS have an answer for that. Subtree merging is nice, but it's
still unidirectional.

For bidirectional merging, you end up having to do some of the work
outside of the DVCS proper, in which case having Bazaar on one side and
Git on the other doesn't make much difference. Especially since you can
use things like bzr-git to translate a branch from one system to
the other.


Stefan

[David Engster]

Post by Stefan Monnier

Post by Julien Danjou

Post by David Engster
Well, I don't believe that git will make cross-project merges easier, at
least not until someone shows me how (and don't just say "submodules",
please ;-) ).

http://git-scm.com/book/en/Git-Tools-Subtree-Merging

The core of the problem is bidirectional merging. AFAIK none of the
current DVCS have an answer for that. Subtree merging is nice, but it's
still unidirectional.

Exactly. The other problem is this little "one of the projects maps to a
subdirectory of the other one", which AFAIK must be taken literally.

Post by Stefan Monnier
For bidirectional merging, you end up having to do some of the work
outside of the DVCS proper, in which case having Bazaar on one side and
Git on the other doesn't make much difference. Especially since you can
use things like bzr-git to translate a branch from one system to
the other.

Let me also point to

http://felipec.wordpress.com/2012/11/13/git-remote-hg-bzr-2/

which is pretty magic (and *almost* manages to convert the CEDET repo).

But in the end, you just do the 'diff | patch' game, no matter which
VCS.

-David

[Stephen Leake]

Post by Stefan Monnier

Post by Julien Danjou

Post by David Engster
Well, I don't believe that git will make cross-project merges easier, at
least not until someone shows me how (and don't just say "submodules",
please ;-) ).

http://git-scm.com/book/en/Git-Tools-Subtree-Merging

The core of the problem is bidirectional merging.

If I understand what you mean by "bidirectional merging", then monotone
handles it nicely (http://www.monotone.ca/).

I use monotone for all my projects, and merge back and forth between
branches all the time.

[Stephen Leake]

Post by Stephen Leake

Post by Stefan Monnier

Post by Julien Danjou

Post by David Engster
Well, I don't believe that git will make cross-project merges easier, at
least not until someone shows me how (and don't just say "submodules",
please ;-) ).

http://git-scm.com/book/en/Git-Tools-Subtree-Merging

The core of the problem is bidirectional merging.

If I understand what you mean by "bidirectional merging", then monotone
handles it nicely (http://www.monotone.ca/).
I use monotone for all my projects, and merge back and forth between
branches all the time.

I suspect the key feature that makes it work is the conflict resolution
tools in monotone;
http://www.monotone.ca/docs/Merge-Conflicts.html#Merge-Conflicts

I worked hard to make that flow nicely, and also to make the Emacs front
end for it flow nicely
(http://stephe-leake.org/emacs/ada-mode/dvc-intro.html)

But there's not a lot of support for monotone, certainly no company is
behind it, so it's probably not a good bet for a large long-term project.

[Stephen J. Turnbull]

Post by Stephen Leake
If I understand what you mean by "bidirectional merging", then monotone
handles it nicely (http://www.monotone.ca/).
I use monotone for all my projects, and merge back and forth between
branches all the time.

When you say "my", do you mean projects that mostly only you work on?
If so, you probably won't run into the problem, unless you're in the
habit of keeping several workspaces on a given branch and you don't
keep them current. In a one-person, multibranch workflow, you will
typically see DAGs like this:

trunk 0--------A--B--C--D-- ...
\ / \
\ / \
branch a--b--c--------d-- ...

and the nature of such workflows is that typically conflicts are
relatively few; you do different things in different branches.
Furthermore, at each merge point (<B> and <d>) there are exactly two
paths from the most recent common ancestor (<c> and <C>,
respectively), which helps to simplify analysis of the merge.

Multi-person, multi-branch workflows admit a nastier kind of geometry,
which the Bazaar developers call "criss-cross merges" for an obvious
reason:

trunk 0--------A--B--C--D--E----- ...
\ / \/ \
\ / /\ \
branch a--b--c-----d--e-----f-- ...

and the merge at <f> can be a monstrosity because the structure of the
DAG is little help in disentangling conflicts: the most recent common
ancestor of <f> is <c>, and there are 4 "long" paths between them,
increasing the expected number of conflicts. If Monotone does handle
these gracefully, that would be *really* cool!

Post by Stephen Leake
I suspect the key feature that makes it work is the conflict
resolution tools in monotone;
http://www.monotone.ca/docs/Merge-Conflicts.html#Merge-Conflicts

Could be, but I really don't see anything on that page that other
DVCSes don't have, and the note about "the special case of file
content conflicts" which invoke an external merge tool looks pretty
ordinary. I suspect that --resolve-conflicts-file does something
similar to git's rerere command, or perhaps git's interactive rebase
command.

Steve

[Stephen Leake]

Post by Stephen J. Turnbull

Post by Stephen Leake
If I understand what you mean by "bidirectional merging", then monotone
handles it nicely (http://www.monotone.ca/).
I use monotone for all my projects, and merge back and forth between
branches all the time.

When you say "my", do you mean projects that mostly only you work on?

yes, or a small group (~ 5 people), with a well controlled branching
policy.

Post by Stephen J. Turnbull
If so, you probably won't run into the problem, unless you're in the
habit of keeping several workspaces on a given branch and you don't
keep them current.

That we do; each release is a branch, and new work happens both on trunk
for major new features, and on the release branch for patches.
Eventually they get merged together.

Post by Stephen J. Turnbull
In a one-person, multibranch workflow, you will typically see DAGs
trunk 0--------A--B--C--D-- ...
\ / \
\ / \
branch a--b--c--------d-- ...
and the nature of such workflows is that typically conflicts are
relatively few; you do different things in different branches.

Yes, that is typical.

Post by Stephen J. Turnbull
Multi-person, multi-branch workflows admit a nastier kind of geometry,
which the Bazaar developers call "criss-cross merges" for an obvious
trunk 0--------A--B--C--D--E----- ...
\ / \/ \
\ / /\ \
branch a--b--c-----d--e-----f-- ...
and the merge at <f> can be a monstrosity because the structure of the
DAG is little help in disentangling conflicts: the most recent common
ancestor of <f> is <c>, and there are 4 "long" paths between them,
increasing the expected number of conflicts. If Monotone does handle
these gracefully, that would be *really* cool!

We often get criss-cross merges with short paths; people do work on the
same branch in parallel.

You are correct that sorting out the conflicts when the path to the
ancestor is long is inherently hard. monotone/DVC presents the relevant
files in a nice way, and allows the user to take their time in sorting
things out. The conflict resolution state is saved on the disk, so you
don't have to resolve all conflicts in one interactive session.

Post by Stephen J. Turnbull

Post by Stephen Leake
I suspect the key feature that makes it work is the conflict
resolution tools in monotone;
http://www.monotone.ca/docs/Merge-Conflicts.html#Merge-Conflicts

Could be, but I really don't see anything on that page that other
DVCSes don't have, and the note about "the special case of file
content conflicts" which invoke an external merge tool looks pretty
ordinary. I suspect that --resolve-conflicts-file does something
similar to git's rerere command, or perhaps git's interactive rebase
command.

Hmm. According to
https://www.kernel.org/pub/software/scm/git/docs/git-rerere.html, 'git
rerere' is for conflicts that happen again on subsequent merges.
monotone (in recent heads, not in the current release) has that for
dropped/modified conflicts; I haven't felt the need for it for other
types of conflicts, but it would be easy to add.

--resolve-conflicts-file specifies the resolutions for one merge; it
does not make sense to save the whole file for a subsequent merge. It
might make sense to save parts of it.

'git rebase' is similar to 'mtn merge'; 'git rebase --continue' appears
to support a "merge" that stops partway thru due to a conflict, which
the user must then resolve before resuming the merge, and getting to the
next conflict.

So the user does not see all conflicts at once, which makes the conflict
resolution harder. It is especially frustrating if you don't know how
many conflicts there are; how much time will be needed to finish the
merge. Is there a git command that lists all conflicts in a rebase
before starting?

When git rebase hits a conflict, it creates a local file with CVS-style
conflict markers. monotone just notes the two file versions, and the DVC
front end pops up an Emacs ediff; that's better than Emacs' CVS conflict
mode.

git then requires 'git add' commit to indicate the conflict resolution.
This leaves the workspace in an odd state; is there a git command that
indicates the workspace is in the middle of an interactive rebase?
Suppose you are interrupted, and come back in a week; can you tell what
state the rebase is in? In monotone, all of the conflict resolution is
done outside the workspace (in <root>/_MTN/resolutions/*), and it is
always clear what is going on.

These are not fundamentally different approaches (they do solve the same
problem), but the details can matter when you do this a lot. I assume
git could be enhanced to be more similar to monotone in this area; I'll
probably be forced to do that when monotone finally dies :(.

[Andreas Schwab]

is there a git command that indicates the workspace is in the middle
of an interactive rebase?

git status

Andreas.

[David Engster]

Post by Stephen J. Turnbull
Multi-person, multi-branch workflows admit a nastier kind of geometry,
which the Bazaar developers call "criss-cross merges" for an obvious

Yes, I get 'criss-cross merge' warnings all the time.

To hopefully make clear what a "cross-project merge" implies, here's my
current setup for the CEDET merge:


/--to-emacs <-| --------------------->
/ ^ | diff|patch
| | |
| | |
CEDET ----trunk| <-| Emacs trunk
| |
| |
\ | diff|patch
\--from-emacs -| <--------------------


CEDET->Emacs: This is actually fairly easy. The 'to-emacs' branch is a
subset of Emacs trunk, containing only the files from CEDET upstream,
but generated from CEDET 'trunk'. This also handily tracks necessary
renames (for instance, EIEIO is located under lisp/emacs-lisp in Emacs,
but in CEDET it is in lisp/eieio). So in theory, I can just merge
'trunk' into 'to-emacs', generate a diff from this merge, and apply it
to Emacs trunk. In practice however, I get a conflict for every file
that was changed in 'trunk' but does not exist in 'to-emacs' (and there
are many such files). Unfortunately, bzr cannot automatically deal with
this (is git able to do that?). But it's a minor issue, since I can
easily script doing 'bzr --take-this resolve' on those files.

Emacs->CEDET: Now that's tedious. You have to first generate a list of
commits in Emacs trunk which changed files from CEDET. Then you try to
cherry-pick those commits into the 'from-emacs' branch. Doing this by
hand is a nightmare, so I've written a package for this
(cedet-emacs-merge.el in CEDET trunk). It generates this list, display
them nicely, lets me test the patches, show conflicts, generates commit
messages, and so on. Most importantly, it keeps track of things I have
applied or ignored and saves this state in the repository as a file
which I can load later.

When I've cherry-picked all the commits to 'from-emacs'. I also have to
merge it into 'to-emacs' before merging 'trunk', as I don't want things
in my diff for CEDET->Emacs which originated from Emacs in the first
place. I guess this is where the criss-crossing comes from.

Yep, it's messy. But I'm used to it now. The most time consuming thing
is fixing ChangeLogs (we don't have any in CEDET and generate them from
commit logs).

-David

[Christopher Schmidt]

The most time consuming thing is fixing ChangeLogs (we don't have any
in CEDET and generate them from commit logs).

I would like to suggest another change - how about removing ChangeLog
files from the development repository. I think these files are
redundant to the commit log of the vc.

Removing the files from the repository would clean diffs and reduce
merge conflicts. Considering distributed vc, a project's history cannot
be thought of as to be list of consecutive increments.

Distributions of Emacs could include ChangeLog files generated from the
vc commit log, of course.

Do I make sense? Are there any drawbacks?

Christopher

[Thierry Volpiatto]

Post by Christopher Schmidt

The most time consuming thing is fixing ChangeLogs (we don't have any
in CEDET and generate them from commit logs).

I would like to suggest another change - how about removing ChangeLog
files from the development repository. I think these files are
redundant to the commit log of the vc.
Removing the files from the repository would clean diffs and reduce
merge conflicts. Considering distributed vc, a project's history cannot
be thought of as to be list of consecutive increments.
Distributions of Emacs could include ChangeLog files generated from the
vc commit log, of course.
Do I make sense?

YES!!!

Post by Christopher Schmidt
Are there any drawbacks?
Christopher

[Richard Stallman]

Emacs ChangeLog files are not redundant with VC change records.
We put different information in them. At least, I do.
In the ChangeLog files I put lists of functions changed and how.
In the bzr log entry I explain the overall purpose of the change.

There are various good ways to store the important change information,
but this has been discussed before. Let's not repeat.

[Aidan Gauland]

Post by Richard Stallman
Emacs ChangeLog files are not redundant with VC change records.
We put different information in them. At least, I do.
In the ChangeLog files I put lists of functions changed and how.
In the bzr log entry I explain the overall purpose of the change.

I put both in the ChangeLog entry and then copy it to the commit log. I
think the ChangeLog format (file list and overall summary) is great, and
I think we should use it in the commit logs. (GNU Guile does this.)

--Aidan

[Stefan Monnier]

Post by Richard Stallman
Emacs ChangeLog files are not redundant with VC change records.
We put different information in them. At least, I do.
In the ChangeLog files I put lists of functions changed and how.
In the bzr log entry I explain the overall purpose of the change.

The rules we supposedly follow in Emacs's repository is to put a copy of
the ChangeLog entry in the commit record. So the ChangeLog file
should be redundant. If it's not, it's an error of the committer.


Stefan

[Richard Stallman]

The rules we supposedly follow in Emacs's repository is to put a copy of
the ChangeLog entry in the commit record. So the ChangeLog file
should be redundant. If it's not, it's an error of the committer.

I guess I have made that error in all my commits.

Why choose this approach, rather than the one I used?

[Paul Eggert]

Post by Stefan Monnier
The rules we supposedly follow in Emacs's repository is to put a copy of
the ChangeLog entry in the commit record. So the ChangeLog file
should be redundant. If it's not, it's an error of the committer.
I guess I have made that error in all my commits.
Why choose this approach, rather than the one I used?

It's simpler and less confusing if the ChangeLog
equals the commit record. When I'm reading a
ChangeLog, I often want to know the overall
purpose of the change, and it can be frustrating
when this information is omitted. Conversely, when I'm
reading a sequence of commit records, it's
convenient to know all the functions and files
that got changed, for the same reason it's convenient
to know this when reading a ChangeLog.

For Emacs, I use typically use vc-dwim (a GNU program)
to check in changes. vc-dwim computes the commit record
automatically from the ChangeLog changes. So I
don't have to write commit records, and this saves
me time.

Many GNU programs these days compute ChangeLog
files automatically from the commit records, which
boils down to the same thing. (vc-dwim also supports
this style of maintenance.)

[Steve Youngs]

Post by Richard Stallman
Emacs ChangeLog files are not redundant with VC change records.
We put different information in them. At least, I do.

You're probably a part of a quite small minority that does. In most
cases where I have come across projects that use a modern SCM and
ChangeLog files they end up doing "double-accounting-logging" with a lot
of copy-pasting from one log to the other.

Post by Richard Stallman
In the ChangeLog files I put lists of functions changed and how.
In the bzr log entry I explain the overall purpose of the change.

This may have made sense in the old days of limited featured VC's such
as RCS or CVS, but not anymore, not with today's tools.

Without looking it up I can't tell you what the very first change we
made to SXEmacs was, but I can say that eliminating the ChangeLog files
was one of the first. Actually, I shouldn't say that the ChangeLog
files were "eliminated" because they still exist for the benefit of
people who use the tarball releases, but they are generated from the
SCM (tla in the beginning, git now).

Post by Richard Stallman
There are various good ways to store the important change information,

Yes, but storing that information in two different places, even when
there isn't any overlap of info between the places, isn't one of them.
Why add a level of complexity, even a minor one like this, when you
don't need to?

[Richard Stallman]

Post by Richard Stallman
There are various good ways to store the important change information,

Yes, but storing that information in two different places, even when
there isn't any overlap of info between the places, isn't one of them.

It is a fine method, which makes each kind of information convenient
for its purpose.

[Steve Youngs]

Post by Steve Youngs

Post by Richard Stallman
There are various good ways to store the important change information,

Yes, but storing that information in two different places, even when
there isn't any overlap of info between the places, isn't one of them.
It is a fine method, which makes each kind of information convenient
for its purpose.

Seems to me that it would be a lot more convenient if the "what" and the
"why" of a change were in the same place. That is where you are making
the split, ChangeLogs for the what and commit logs for the why?

The problem that your method alleviates, the doubling up of information,
simply doesn't exist when you are logging to a single place.

Your method does nothing to alleviate the problem of recurring conflicts
on the ChangeLog files. Because of their very nature and purpose the
ChangeLog files get the most conflicts. Normally very easy to resolve,
but still, a PITA.

Having the VC's built-in logging be the _only_ place your developers
write up their changes logs solves all of these issues. And in my
experience, it does so painlessly.

We have never had a single problem, complaint or concern with using this
method of logging in SXEmacs, and I'd be only too happy to answer any
concerns that you or anyone else might have with moving to this
method. Just Cc me or email me directly (I don't watch this list too
closely).

[Carsten Dominik]

Post by Christopher Schmidt

The most time consuming thing is fixing ChangeLogs (we don't have any
in CEDET and generate them from commit logs).

I would like to suggest another change - how about removing ChangeLog
files from the development repository. I think these files are
redundant to the commit log of the vc.
Removing the files from the repository would clean diffs and reduce
merge conflicts. Considering distributed vc, a project's history cannot
be thought of as to be list of consecutive increments.
Distributions of Emacs could include ChangeLog files generated from the
vc commit log, of course.
Do I make sense? Are there any drawbacks?

I think it makes sense. In fact, org-mode does already create
ChangeLog entries automatically from git commit messages. We
enforce commit message to have a section that does look just
like a ChangeLog entry, and we extract these when the time
is ripe for another merge with Emacs. Here is a recent
example of such a commit message:

------------------------------------------------------------------------------------------
org.el (org-store-link): Storing multiple links in the active region now requires a triple prefix argument

* org.el (org-store-link): Storing multiple links in the active region now
requires a triple prefix argument.


Thanks to Matt Lundin for reporting bugs in this area.
-------------------------------------------------------------------------------------------


Indeed, this process does get rid of many conflicts, because the adding of text to the
beginning of a file (like ChangeLog) often causes merge conflicts. And it avoids a lot of duplicate work.

- Carsten

[Alan Mackenzie]

Hello, Christopher.

Post by Christopher Schmidt

The most time consuming thing is fixing ChangeLogs (we don't have any
in CEDET and generate them from commit logs).

I would like to suggest another change - how about removing ChangeLog
files from the development repository. I think these files are
redundant to the commit log of the vc.
Removing the files from the repository would clean diffs and reduce
merge conflicts. Considering distributed vc, a project's history cannot
be thought of as to be list of consecutive increments.
Distributions of Emacs could include ChangeLog files generated from the
vc commit log, of course.

Of course? Generating the (structured) ChangeLog from (free form) log
entrys isn't trivial.

Post by Christopher Schmidt
Do I make sense? Are there any drawbacks?

Yes. ChangeLog files are useful, e.g. for hunting down changes. I do
this often enough that the lack of ChangeLogs would be inconvenient. I
don't doubt that it's possible to wring the necessary info out of bzr,
I've done it, but it's not pleasant.

Anyway, whilst the choice of DVCS is up in the air is not the time to be
debating this question, IMAO.

Post by Christopher Schmidt
Christopher

[David Engster]

Post by Alan Mackenzie

Post by Christopher Schmidt

The most time consuming thing is fixing ChangeLogs (we don't have any
in CEDET and generate them from commit logs).

I would like to suggest another change - how about removing ChangeLog
files from the development repository. I think these files are
redundant to the commit log of the vc.
Removing the files from the repository would clean diffs and reduce
merge conflicts. Considering distributed vc, a project's history cannot
be thought of as to be list of consecutive increments.
Distributions of Emacs could include ChangeLog files generated from the
vc commit log, of course.

Of course? Generating the (structured) ChangeLog from (free form) log
entrys isn't trivial.

Indeed. That's why I wrote the time consuming thing is "fixing" those
generated ChangeLogs, like

- combining changes to the same file (and maybe function) which stretch
over several commits,

- removing further explanations which are fine in commit logs but not in
ChangeLogs,

- putting ChangeLogs entries in the right places (I have to deal with
five different ChangeLogs: etc/, admin/, doc/misc, lisp/, and finally
lisp/cedet),

- and many more smaller things; sometimes commit logs just don't have
the proper format.

Much of this stuff could be automated, though. I just didn't have time
yet to implement all this. Maybe we could work together with the Org
people on that; while we use bzr, I guess some of the code could be
shared.

-David

[Steve Youngs]

Post by David Engster
Indeed. That's why I wrote the time consuming thing is "fixing" those
generated ChangeLogs, like
- combining changes to the same file (and maybe function) which stretch
over several commits,

Having logs line up with commits is normally more of a benefit than an
annoyance IMO.

Post by David Engster
- removing further explanations which are fine in commit logs but not in
ChangeLogs,

Don't be afraid of verbosity in logs. :-)

Post by David Engster
- putting ChangeLogs entries in the right places (I have to deal with
five different ChangeLogs: etc/, admin/, doc/misc, lisp/, and finally
lisp/cedet),

Move to a single log model and then never have to worry about this step
again.

Post by David Engster
- and many more smaller things; sometimes commit logs just don't have
the proper format.

I've not ever found a time when it didn't.

Post by David Engster
Much of this stuff could be automated, though.

The biggest obstacle is getting your developers to DTRT at commit time,
and once you get that down pat, it is smooth sailing from there on. :-)

[Thierry Volpiatto]

Post by Alan Mackenzie
Hello, Christopher.

Post by Christopher Schmidt

The most time consuming thing is fixing ChangeLogs (we don't have any
in CEDET and generate them from commit logs).

I would like to suggest another change - how about removing ChangeLog
files from the development repository. I think these files are
redundant to the commit log of the vc.
Removing the files from the repository would clean diffs and reduce
merge conflicts. Considering distributed vc, a project's history cannot
be thought of as to be list of consecutive increments.
Distributions of Emacs could include ChangeLog files generated from the
vc commit log, of course.

Of course? Generating the (structured) ChangeLog from (free form) log
entrys isn't trivial.

Post by Christopher Schmidt
Do I make sense? Are there any drawbacks?

Yes. ChangeLog files are useful, e.g. for hunting down changes. I do
this often enough that the lack of ChangeLogs would be inconvenient. I
don't doubt that it's possible to wring the necessary info out of bzr,
I've done it, but it's not pleasant.

Because bzr log take ages to popup, I guess it is one reason you relay
on changelog files.

Post by Alan Mackenzie
Anyway, whilst the choice of DVCS is up in the air is not the time to be
debating this question, IMAO.

Post by Christopher Schmidt
Christopher

[John Wiegley]

Post by Alan Mackenzie
Of course? Generating the (structured) ChangeLog from (free form) log
entrys isn't trivial.

Here is a script I use for creating GNU-style ChangeLog entries from the
output of 'git log':

https://github.com/jwiegley/git-scripts/blob/master/git-changelog

John

[Steve Youngs]

Post by Alan Mackenzie
Generating the (structured) ChangeLog from (free form) log
entrys isn't trivial.

It isn't needed if you write structured log entries in the first place.
I think someone (Stefan?) already suggested... make
#'add-change-log-entry and friends DTRT.

[Stefan Monnier]

Post by Christopher Schmidt
I would like to suggest another change - how about removing ChangeLog
files from the development repository. I think these files are
redundant to the commit log of the vc.

We already dropped them from `elpa', but my experience is that the support
for writing commit logs entries is not yet up-to-par with the support
for writing ChanegLog entries. I encourage people to work on that
(e.g. make C-x 4 a do something useful for those projects that don't
use ChangeLog files).

Post by Christopher Schmidt
Of course? Generating the (structured) ChangeLog from (free form) log
entrys isn't trivial.

Luckily, that's not quite the problem we're trying to solve: the commit
log messages in Emacs should (and mostly do) follow the exact same
conventions as the ChangeLog entries.

Post by Christopher Schmidt
Because bzr log take ages to popup, I guess it is one reason you relay
on changelog files.

Agreed. Commit logs are much more useful in Git where they show up much
more quickly.

Another big issue is that commit logs can't be fixed (it's not an
inherent limitation, just a limitation of "bzr log" and AFAIK of "git
log" as well).


Stefan

[Eli Zaretskii]

Date: Thu, 28 Mar 2013 08:41:25 -0400

Post by Thierry Volpiatto
Because bzr log take ages to popup, I guess it is one reason you relay
on changelog files.

Agreed. Commit logs are much more useful in Git where they show up much
more quickly.

Not here:

D:\gnu\bzr\emacs\trunk>timep bzr log --line -l5000 > nul

real 00h00m00.921s
user 00h00m00.875s
sys 00h00m00.062s

$ time git log --oneline -n5000 > /dev/null

real 0m0.218s
user 0m0.015s
sys 0m0.015s

I hope you at least won't claim that 900 msec is "much more quickly"
than 200 msec. (Not that anyone should ever need to look at 5000
revisions.)

[Eli Zaretskii]

Date: Thu, 28 Mar 2013 18:34:41 +0200
D:\gnu\bzr\emacs\trunk>timep bzr log --line -l5000 > nul
real 00h00m00.921s
user 00h00m00.875s
sys 00h00m00.062s
$ time git log --oneline -n5000 > /dev/null
real 0m0.218s
user 0m0.015s
sys 0m0.015s
I hope you at least won't claim that 900 msec is "much more quickly"
than 200 msec. ^^^^^^^

Err, I meant "slowly", of course.

[Dmitry Gutov]

Post by Eli Zaretskii

Date: Thu, 28 Mar 2013 08:41:25 -0400

Post by Thierry Volpiatto
Because bzr log take ages to popup, I guess it is one reason you relay
on changelog files.

Agreed. Commit logs are much more useful in Git where they show up much
more quickly.

D:\gnu\bzr\emacs\trunk>timep bzr log --line -l5000 > nul
real 00h00m00.921s
user 00h00m00.875s
sys 00h00m00.062s
$ time git log --oneline -n5000 > /dev/null
real 0m0.218s
user 0m0.015s
sys 0m0.015s
I hope you at least won't claim that 900 msec is "much more quickly"
than 200 msec. (Not that anyone should ever need to look at 5000
revisions.)

Your conclusion here seems to be the reverse of what the command output
shows (900ms for Bazaar and 200ms for Git).

In my experience, Bzr is especially slow when showing log for a subtree
or a specific file.

[Eli Zaretskii]

Date: Thu, 28 Mar 2013 21:20:44 +0400

Post by Eli Zaretskii
D:\gnu\bzr\emacs\trunk>timep bzr log --line -l5000 > nul
real 00h00m00.921s
user 00h00m00.875s
sys 00h00m00.062s
$ time git log --oneline -n5000 > /dev/null
real 0m0.218s
user 0m0.015s
sys 0m0.015s
I hope you at least won't claim that 900 msec is "much more quickly"
than 200 msec. (Not that anyone should ever need to look at 5000
revisions.)

Your conclusion here seems to be the reverse of what the command output
shows (900ms for Bazaar and 200ms for Git).

It was a typo. See my followup message.

In my experience, Bzr is especially slow when showing log for a subtree
or a specific file.

I could ask you to show numbers (because I have no such experience),
but I won't. No one in this thread wants any serious discussion,
anyway.

[Dmitry Gutov]

Post by Eli Zaretskii

Date: Thu, 28 Mar 2013 21:20:44 +0400

Post by Eli Zaretskii
D:\gnu\bzr\emacs\trunk>timep bzr log --line -l5000 > nul
real 00h00m00.921s
user 00h00m00.875s
sys 00h00m00.062s
$ time git log --oneline -n5000 > /dev/null
real 0m0.218s
user 0m0.015s
sys 0m0.015s
I hope you at least won't claim that 900 msec is "much more quickly"
than 200 msec. (Not that anyone should ever need to look at 5000
revisions.)

Your conclusion here seems to be the reverse of what the command output
shows (900ms for Bazaar and 200ms for Git).

It was a typo. See my followup message.

I saw it after I sent the reply.

To answer your question, then, yes, 4.5 times faster indeed is "much
more quickly". The difference here is not critical, but nice to have.

Post by Eli Zaretskii

In my experience, Bzr is especially slow when showing log for a subtree
or a specific file.

I could ask you to show numbers (because I have no such experience),
but I won't. No one in this thread wants any serious discussion,
anyway.

I would send you the numbers if you pointed me at the mingw port of
'time' you're apparently using. But here's an example command:

git log lisp\progmodes\ruby-mode.el | less

It takes about 300ms on the first run and is instantaneous after that.

If I call the respective command in a Bazaar repository, it takes about
4 seconds on every run, Bazaar doesn't seem to do any caching here. Note
that I'm using version 2.5.1, it could be better in the latest beta.

Anyway, the most important speedup I expect to see is the time it takes
to do "git pull" vs "bzr update". I haven't done any real testing there
yet, but the latter command takes entirely too long. Of course, most of
that is due to the server being overloaded.

Speaking of removing changelogs, I think the foremost challenge is
keeping the format. We don't have anything similar to
`add-change-log-entry' for the log-edit buffer, and I'm not sure how
that would even work.

[Eli Zaretskii]

Date: Fri, 29 Mar 2013 01:04:35 +0400
To answer your question, then, yes, 4.5 times faster indeed is "much
more quickly". The difference here is not critical, but nice to have.

Get real! This started from the example of someone looking at the log
entry; human needs much more than a few hundreds of milliseconds to
read it, so a difference of 700 msec (for 5000 revisions!) is entirely
irrelevant. Do you really know someone who can read 5000 entries in
under one second?

Post by Eli Zaretskii

Post by Dmitry Gutov
In my experience, Bzr is especially slow when showing log for a subtree
or a specific file.

I could ask you to show numbers (because I have no such experience),
but I won't. No one in this thread wants any serious discussion,
anyway.

I would send you the numbers if you pointed me at the mingw port of
'time' you're apparently using.

I wrote that program myself. Unix 'time' cannot be ported, because it
uses too many Posix APIs.

git log lisp\progmodes\ruby-mode.el | less
It takes about 300ms on the first run and is instantaneous after that.

Not here:

$ time git log lisp/progmodes/ruby-mode.el > /dev/null

real 0m5.140s
user 0m0.015s
sys 0m0.000s

D:\gnu\bzr\emacs\msys-build>timep bzr log lisp\progmodes\ruby-mode.el > nul

real 00h00m04.281s
user 00h00m04.078s
sys 00h00m00.218s

Entirely comparable. And re-running the commands doesn't change the
times, so I don't think any caching is involved.

Anyway, the most important speedup I expect to see is the time it takes
to do "git pull" vs "bzr update". I haven't done any real testing there
yet, but the latter command takes entirely too long.

Depends on how large is your pull. E.g., the initial "git clone" took
me almost 3 hours; bzr did the same in under 50 min.

But we have been all through this, time and again. The real numbers
don't convince anyone. It's a religious argument since day one.

[Dmitry Gutov]

Post by Eli Zaretskii

Date: Fri, 29 Mar 2013 01:04:35 +0400
To answer your question, then, yes, 4.5 times faster indeed is "much
more quickly". The difference here is not critical, but nice to have.

Get real! This started from the example of someone looking at the log
entry; human needs much more than a few hundreds of milliseconds to
read it, so a difference of 700 msec (for 5000 revisions!) is entirely
irrelevant. Do you really know someone who can read 5000 entries in
under one second?

Why are you arguing with "nice to have"? I gave you a more significant
example below.

Post by Eli Zaretskii

Post by Eli Zaretskii

Post by Dmitry Gutov
In my experience, Bzr is especially slow when showing log for a subtree
or a specific file.

I could ask you to show numbers (because I have no such experience),
but I won't. No one in this thread wants any serious discussion,
anyway.

I would send you the numbers if you pointed me at the mingw port of
'time' you're apparently using.

I wrote that program myself. Unix 'time' cannot be ported, because it
uses too many Posix APIs.

Since you don't seem inclined to distribute it, you won't get exact
numbers from me.

Post by Eli Zaretskii

git log lisp\progmodes\ruby-mode.el | less
It takes about 300ms on the first run and is instantaneous after that.

$ time git log lisp/progmodes/ruby-mode.el > /dev/null
real 0m5.140s
user 0m0.015s
sys 0m0.000s
D:\gnu\bzr\emacs\msys-build>timep bzr log lisp\progmodes\ruby-mode.el > nul
real 00h00m04.281s
user 00h00m04.078s
sys 00h00m00.218s
Entirely comparable. And re-running the commands doesn't change the
times, so I don't think any caching is involved.

That's a weak reply.

Since I get much better numbers with Git, it just means that you need to
install a newer version, do 'git gc', or whatever. On the other hand,
you get the same numbers with Bazaar, which confirms that Bazaar can't
do better.

For the record:

C:\Users\gutov\vc\emacs-git>git --version
git version 1.8.0.msysgit.0

Post by Eli Zaretskii

Anyway, the most important speedup I expect to see is the time it takes
to do "git pull" vs "bzr update". I haven't done any real testing there
yet, but the latter command takes entirely too long.

Depends on how large is your pull. E.g., the initial "git clone" took
me almost 3 hours; bzr did the same in under 50 min.

I mean that whenever I need to do a commit in the Emacs repository, 'bzr
update' takes at least 30 seconds or so, even when the difference
between the local and remote heads is a couple of commits.

I don't see this kind of problem with Git, but maybe I just haven't
tried it with a repository hosted on the same server as Bazaar one.

[Eli Zaretskii]

Date: Fri, 29 Mar 2013 02:42:51 +0400

Post by Eli Zaretskii
I wrote that program myself. Unix 'time' cannot be ported, because it
uses too many Posix APIs.

Since you don't seem inclined to distribute it, you won't get exact
numbers from me.

You never asked. I can send the source to you privately, if you
want.

C:\Users\gutov\vc\emacs-git>git --version
git version 1.8.0.msysgit.0

Same here:

$ git version
git version 1.8.0.msysgit.0

Post by Eli Zaretskii

Post by Dmitry Gutov
Anyway, the most important speedup I expect to see is the time it takes
to do "git pull" vs "bzr update". I haven't done any real testing there
yet, but the latter command takes entirely too long.

Depends on how large is your pull. E.g., the initial "git clone" took
me almost 3 hours; bzr did the same in under 50 min.

I mean that whenever I need to do a commit in the Emacs repository, 'bzr
update' takes at least 30 seconds or so, even when the difference
between the local and remote heads is a couple of commits.
I don't see this kind of problem with Git, but maybe I just haven't
tried it with a repository hosted on the same server as Bazaar one.

I did, just now:

D:\gnu\bzr\emacs\trunk>timep bzr up
Connected (version 2.0, client OpenSSH_5.9)
Authentication (publickey) successful!
Secsh channel 1 opened.
M nt/ChangeLog
M nt/config.nt
M src/ChangeLog
M src/makefile.w32-in
All changes applied successfully.
Updated to revision 112175 of branch bzr+ssh://***@bzr.savannah.gnu.org/emacs/trunk

real 00h00m24.890s
user 00h00m01.125s
sys 00h00m00.203s

$ time git pull
remote: Counting objects: 17, done.
remote: Compressing objects: 100% (10/10), done.
remote: Total 10 (delta 8), reused 0 (delta 0)
Unpacking objects: 100% (10/10), done.

[Eli Zaretskii]

Date: Fri, 29 Mar 2013 08:45:44 +0300

Date: Fri, 29 Mar 2013 02:42:51 +0400

Post by Eli Zaretskii
I wrote that program myself. Unix 'time' cannot be ported, because it
uses too many Posix APIs.

Since you don't seem inclined to distribute it, you won't get exact
numbers from me.

You never asked. I can send the source to you privately, if you
want.

Btw: bzr logs all of its times in .bzr.log, so you don't need any
additional programs to time it. (I wish git had such a comprehensive
logging facility, it proved invaluable for me quite a few times in the
past.)

[Thierry Volpiatto]

Post by Eli Zaretskii

Date: Fri, 29 Mar 2013 08:45:44 +0300

Date: Fri, 29 Mar 2013 02:42:51 +0400

Post by Eli Zaretskii
I wrote that program myself. Unix 'time' cannot be ported, because it
uses too many Posix APIs.

Since you don't seem inclined to distribute it, you won't get exact
numbers from me.

You never asked. I can send the source to you privately, if you
want.

Btw: bzr logs all of its times in .bzr.log, so you don't need any
additional programs to time it. (I wish git had such a comprehensive
logging facility, it proved invaluable for me quite a few times in the
past.)

[Eli Zaretskii]

Date: Fri, 29 Mar 2013 07:43:03 +0100

Post by Eli Zaretskii
Btw: bzr logs all of its times in .bzr.log, so you don't need any
additional programs to time it. (I wish git had such a comprehensive
logging facility, it proved invaluable for me quite a few times in the
past.)

[Dmitry Gutov]

Post by Eli Zaretskii

Date: Fri, 29 Mar 2013 02:42:51 +0400

Post by Eli Zaretskii
I wrote that program myself. Unix 'time' cannot be ported, because it
uses too many Posix APIs.

Since you don't seem inclined to distribute it, you won't get exact
numbers from me.

You never asked. I can send the source to you privately, if you
want.

Please do. Hopefully, it's not hard to compile.

[Stefan Monnier]

Post by Stefan Monnier
Agreed. Commit logs are much more useful in Git where they show up much
more quickly.

Obviously, it depends on the specific case. My use cases are mostly
"C-x v l" from a file, with default settings. Also I have not measured
it, so maybe it simply appears faster (e.g. because it starts giving
output sooner).


Stefan

[Stefan Monnier]

Post by David Engster
/--to-emacs <-| --------------------->
/ ^ | diff|patch
| | |
| | |
CEDET ----trunk| <-| Emacs trunk
| |
| |
\ | diff|patch
\--from-emacs -| <--------------------

[...]

Post by David Engster
Emacs->CEDET: Now that's tedious. You have to first generate a list of
commits in Emacs trunk which changed files from CEDET.

Hmm... Why don't you have a more symmetric setup. I.e. have
a "to-cedet" branch on the Emacs side, where the non-CEDET files are
removed and the CEDET files are renamed appropriately?


Stefan

[David Engster]

Post by Stefan Monnier

Post by David Engster
/--to-emacs <-| --------------------->
/ ^ | diff|patch
| | |
| | |
CEDET ----trunk| <-| Emacs trunk
| |
| |
\ | diff|patch
\--from-emacs -| <--------------------

[...]

Post by David Engster
Emacs->CEDET: Now that's tedious. You have to first generate a list of
commits in Emacs trunk which changed files from CEDET.

Hmm... Why don't you have a more symmetric setup. I.e. have
a "to-cedet" branch on the Emacs side, where the non-CEDET files are
removed and the CEDET files are renamed appropriately?

I have thought of doing a similar setup on the Emacs side. The main
problem is that I'd have a huge list of conflicts every time I merge
from trunk (for every file that was changed which is not in
'to-cedet'). I could probably script things to resolve those
automatically, though. Still, getting the list of commits which change
CEDET files is not difficult, aside from taking several minutes to
complete (basically bzr log lisp/cedet lisp/emacs-lisp/eieio* ...).

The real work is getting the patches to apply upstream, resolve
conflicts and not loose track of what you've already merged (although I
guess I should just merge more often...).

-David

[Stephen J. Turnbull]

Post by David Engster
Emacs->CEDET: Now that's tedious. You have to first generate a list of
commits in Emacs trunk which changed files from CEDET. Then you try to
cherry-pick those commits into the 'from-emacs' branch.

Have you tried Robert Collins' looms? It seems to me that they would
help with this (but last time I checked they require a different
branch format).

[Stefan Monnier]

Post by Stephen Leake

Post by Stefan Monnier
The core of the problem is bidirectional merging.

If I understand what you mean by "bidirectional merging", then monotone
handles it nicely (http://www.monotone.ca/).

By bidirectional merging, I mean that you have two parallel branches
that should be kept in sync, so that any commit on branch A should be
sync'd to branch B and vice versa. Yet branch A and branch B are not
identical (there's a "constant" diff between the two).


Stefan

[Kolo Rahl]

Question about these "bidirectional" merge situations: how often do they
happen and what is an example of one? I'm honestly curious, as it seems
that such a development flow would imply a cyclic set of dependencies
between the two branches. A _needs_ to be in sync with B only if it has a
dependency on work in the B branch and vice versa, so if A and B branches
both need to be constantly sync'd with each other, that means they have
cyclic dependencies, right?

Post by Stefan Monnier

Post by Stephen Leake

Post by Stefan Monnier
The core of the problem is bidirectional merging.

If I understand what you mean by "bidirectional merging", then monotone
handles it nicely (http://www.monotone.ca/).

By bidirectional merging, I mean that you have two parallel branches
that should be kept in sync, so that any commit on branch A should be
sync'd to branch B and vice versa. Yet branch A and branch B are not
identical (there's a "constant" diff between the two).
Stefan

[Stefan Monnier]

Post by Kolo Rahl
Question about these "bidirectional" merge situations: how often do they
happen and what is an example of one?

Sync'ing Emacs and CEDET, or Emacs and Gnus, or ...


Stefan

[Stephen Leake]

Post by Stefan Monnier

Post by Stephen Leake

Post by Stefan Monnier
The core of the problem is bidirectional merging.

If I understand what you mean by "bidirectional merging", then monotone
handles it nicely (http://www.monotone.ca/).

By bidirectional merging, I mean that you have two parallel branches
that should be kept in sync, so that any commit on branch A should be
sync'd to branch B and vice versa. Yet branch A and branch B are not
identical (there's a "constant" diff between the two).

Ah. That is not what I thought.

A use case for this would be support for old Emacs versions in the
upstream of an Emacs feature, but only the current Emacs in the Emacs
trunk.

monotone does not handle that directly; it would be an interesting
feature to add. But it would make more sense to add it to git.