What a modern collaboration toolkit looks like

What a modern collaboration toolkit looks like

[Eric S. Raymond]

This started out as part of a longer essay called "On not kissing the pig".
But that essay grew into an epic.  Rather than dump it on the list all 
at once, I think it will be useful if I start by giving everybody a
clear idea of the potential benefits of changing our practices.

I'm going to describe the collaboration toolkit on another project where
I happen to be a senior dev, called Battle For Wesnoth.  You can find
the project at <http://www.wesnoth.org/>.

This is a typical modern open-source project.  It's not even a
particularly large one -- no more than a dozen core devs, 58
developers total.  Here are the collaborative tools we use every day:

* Source control with Subversion
* A bug tracker
* A very active IRC channel used for routine dev chatter
* A dev mailing list, used mostly for white papers and long proposals
* Web forums where a large user community hangs out
* Subversion commits are echoed to IRC in real time by a monitor bot
* Subversion commits that reference a bug append a comment to the tracker
* A bot on IRC that you can query with a bug number and get a tracker URL.

Here are some of the ways my workflow on Wesnoth differs from my
workflow on Emacs:

1. When I do a commit of changes to several files, the entire changeset
is saved as a unit with a single change comment attached to it.  

a) That change can be referenced, through its Subversion revision ID.  
   (So, for example, "Hey boucman, your r22615 broke linger mode!")

b) That change can be backed out as a unit.

c) That change is instantly browseable by any dev.

d) If that change is a fix that references a bug number, that fact
   instantly becomes part of the bug database *where everyone can
   see it*.

2. My commit is also echoed to the IRC channel, where there are almost
never fewer than three or four devs hanging out as they hack, chatting
in real time.  Review tends to happen instantly.

3. Because everybody (and our user community!) uses the bug tracker, 
everybody always knows exactly what the dozen most important 
bugs are, and has a pretty good idea what the dozen most valuable
feature requests are.

4. Because the IRC has a monitor bot hooked to the bug database,
whenever someone says "Eric, have you looked at feature request #2355,
it looks like your kind of thing." I can get to that issue by typing
"wesbot: bug #2355" and clicking once.  Questioner usually gets a
response less than 30 seconds later.  If I address the request,
they'll see my commit comment in real time without me having to do
anything special.

5. The entire commit history of the project is visible to me 
moments after I type C-X v l.  This is much more powerful 
than just having the per-file change history visible, because 
the commit groupings themselves tell me valuable things 
about developer intentions.

The effect of all these tools is more than the sum of its parts.
  
One huge one is simply that devs can choose to spend time picking
bugs off the tracker and nailing them, with basically zero process
friction.

Another is that we routinely hash out serious design and coding issues
in real time, because everyone on the chat channel can share hyperlinks
to the codebase, the commit history, the bug tracker, and posts
on the user forums.

Yet a third is that when we decide to do it, we can converge on a
releasable state with almost absurd ease.  Like, Ivanovic (our release
manager) will announce "Point release scheduled this coming Wednesday"
and everyone will pretty much flip into bug-stomping mode.  The
tracker bug list tends to shrink dramatically when this happens --
not only do we get prepared for release but *we know we've done so*.

More generally, development happens *fast*.  I don't have to wait
weeks to find out whether other devs think of an idea.  Commonly
I know within minutes.

The Wesnoth devs are good but not exceptionally so, and we're weighed
down by a crappy implementation language (C++).  Nevertheless our
productivity, in terms of goals achieved per hour of work, is quite
high.  That's because our collaboration tools support everything we do
without imposing noticeable process friction.  This makes us
dramatically more effective as individuals and as a group than we
could possibly be without them.

Lessons for the Emacs project?  Hell, yes.  But I'm not going to 
write that rant until y'all have had a little time to absorb 
this description of how things can be.

And bear in mind: At the end of 2007 this is obervably *normal*.  It's
not that Battle For Wesnoth's collaboration toolkit is ahead of the
curve -- it's that Emacs's is behind.  Way, *way* behind.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Americans have the will to resist because you have weapons. 
If you don't have a gun, freedom of speech has no power.
         -- Yoshimi Ishikawa, Japanese author, in the LA Times 15 Oct 1992

Re: What a modern collaboration toolkit looks like

[Thien-Thi Nguyen]

() "Eric S. Raymond" <esr@snark.thyrsus.com>
() Sun, 30 Dec 2007 07:22:17 -0500 (EST)

   And bear in mind: At the end of 2007 this is obervably *normal*.
   It's not that Battle For Wesnoth's collaboration toolkit is
   ahead of the curve -- it's that Emacs's is behind.  Way, *way*
   behind.

interesting stuff!  i'm worried about speedfreak mentality,
however.  how does the group treat (not (connected-p 'always))
programmers?  more precisely: what kind of stigmatism do such
programmers endure?

thi

Re: What a modern collaboration toolkit looks like

[Richard Stallman]

I usually don't have an internet connection, so I could not possibly
use the methods you recommend.  I cannot communicate with people by
IRC.  I cannot get information from a web interface.

Email and CVS work for me because I have the data off-line.

Even when I have a net connection, IRC is inefficient in terms of my
time.  I cannot afford watch a window while text dribbles in.  I want
to get the information as a batch, such as an email message.

Re: What a modern collaboration toolkit looks like

[Eric S. Raymond]

Richard Stallman <rms@gnu.org>:
> I usually don't have an internet connection, so I could not possibly
> use the methods you recommend.  I cannot communicate with people by
> IRC.  I cannot get information from a web interface.

Er...perhaps you should fix these problems, rather than allowing them
to limit and damage Emacs and every other project you are involved in.

How is it even *possible* that you cannot get information from a Web
interface?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: What a modern collaboration toolkit looks like

[Robert J. Chassell]

   Richard Stallman <rms@gnu.org>:
   > I usually don't have an internet connection, so I could not possibly
   > use the methods you recommend.  I cannot communicate with people by
   > IRC.  I cannot get information from a web interface.

   "Eric S. Raymond" <esr@thyrsus.com>:
   Er...perhaps you should fix these problems, rather than allowing them
   to limit and damage Emacs and every other project you are involved in.

Why should RMS change his politics or his procedures?

As for myself, I cannot have a continuous Internet connection, for
example when I am visiting.  Moreover, I certainly don't want one at
home because (a) although I have a great deal of security I am not an
expert and I don't trust that I won't run into a malicious external
site, and (b) I want to get work done and not be interrupted.

I know there are people who do not mind interruptions, but I am not
one of them.  For me, that is key.  Different people have different
desires.

An advantage of email is that you don't have to respond for a day or
two.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: What a modern collaboration toolkit looks like

[Nick Roberts]

 > > I usually don't have an internet connection, so I could not possibly
 > > use the methods you recommend.  I cannot communicate with people by
 > > IRC.  I cannot get information from a web interface.
 > 
 > Er...perhaps you should fix these problems, rather than allowing them
 > to limit and damage Emacs and every other project you are involved in.

I don't think Richard perceives it as a problem.  After a long thread about
using a bug tracker, we still use a file called FOR-RELEASE; seven months
after 22.1 was released, there has been no bugfix 22.2 release; and after
five and a half years on a branch, Unicode Emacs is still on a branch.

This is how Emacs development works.  As they say, you can lead a horse to
water but you can't make it drink.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: What a modern collaboration toolkit looks like

[Lennart Borgman (gmail)]

Nick Roberts wrote:
>  > > I usually don't have an internet connection, so I could not possibly
>  > > use the methods you recommend.  I cannot communicate with people by
>  > > IRC.  I cannot get information from a web interface.
>  > 
>  > Er...perhaps you should fix these problems, rather than allowing them
>  > to limit and damage Emacs and every other project you are involved in.
> 
> I don't think Richard perceives it as a problem.  After a long thread about
> using a bug tracker, we still use a file called FOR-RELEASE; seven months
> after 22.1 was released, there has been no bugfix 22.2 release; and after
> five and a half years on a branch, Unicode Emacs is still on a branch.
> 
> This is how Emacs development works.  As they say, you can lead a horse to
> water but you can't make it drink.

What was the problem with choosing a bug tracking system? Aren't there 
any systems where you can commit changes and do other things with bug 
track records just as you do for source code?

Re: What a modern collaboration toolkit looks like

[Richard Stallman]

    What was the problem with choosing a bug tracking system? Aren't there 
    any systems where you can commit changes and do other things with bug 
    track records just as you do for source code?

I would not be averse to using a bug-tracking system if I can operate
it by mail.

However, I don't think that recording the known bugs differently
will automatically convince people to work on fixing them.
That's the bottleneck.  The same 4 or 5 bugs have been recorded
in the Emacs 22 FOR-RELEASE file for over a month.  Would people
please work on fixing them?

Re: What a modern collaboration toolkit looks like

[Richard Stallman]

    > I usually don't have an internet connection, so I could not possibly
    > use the methods you recommend.  I cannot communicate with people by
    > IRC.  I cannot get information from a web interface.

    Er...perhaps you should fix these problems, rather than allowing them
    to limit and damage Emacs and every other project you are involved in.

I will not turn my life upside down to follow your recommendations for
development tools.

Re: What a modern collaboration toolkit looks like

[Eric S. Raymond]

Richard Stallman <rms@gnu.org>:
>     > I usually don't have an internet connection, so I could not possibly
>     > use the methods you recommend.  I cannot communicate with people by
>     > IRC.  I cannot get information from a web interface.
> 
>     Er...perhaps you should fix these problems, rather than allowing them
>     to limit and damage Emacs and every other project you are involved in.
> 
> I will not turn my life upside down to follow your recommendations for
> development tools.

It's not the fact that they're my recommendations that is relevant.  Don't
turn this into a personality issue, it's not one.  It's a question about
how your choices affect the projects you are responsible for.

*You* are talented enough that you can out-code most other people even
when they have modern tools and you're refusing them.  But this isn't
true of most of your contributors -- by imposing your limits on their
working methods as well as your own you're putting the projects you
run under a severe handicap, damaging their ability to ship timely and
high-quality code.

Telling evidence for this is the very long interval between Emacs
point releases and the trouble you have been having clearing your bug
list.  In 1997 the Emacs project's performance on these scores would
have been well within the normal range, given the number and quality
of developers you have -- but the world has changed, the tools are
better, the typical tempo of development is faster, and in 2007 this
project's performance looks really bad.  Unpredictable intervals of
more than a year between point releases just do not cut it these days.

Here's a scale indication: Battle For Wesnoth does a point release
pretty regularly every three weeks, and they're usually good releases.
This is by no means exceptional performance in 2007.  With decent 
tools and practices I'm sure we could match it.

Very unfortunately, the second-order effects of poor productivity
may be worse than the first-order ones.  Many younger developers out
there think Emacs is limping along on old ideas and old tech, its
glory days long in the past.  I think they're seriously wrong,
because...well...I think Lisp is eternal; earlier this very evening at
a holiday party I was defending Emacs against a bunch of Eclipse fans
who think I'm nuts to hold onto it.

But it gets harder to maintain that position as time goes by.  When
those Eclipse fans pointed and laughed because we're still stuck on
CVS and don't have a bug tracker, what counter could I have had?  They
know these are bad choices and they know that I know it -- so when
they write off Emacs as old, tired, and irrelevant to anything they're
interested in, I find it increasingly difficult to reply.

Emacs will never be irrelevant for *me*; it fits my hand too well.
But a thing I was painfully reminded of just a few hours ago is that
we're losing the kids (for values of "kids" up to about age 35).  That
means we're losing the future.

And that's why, when you block your projects from using modern tools,
it's a serious problem.  I certainly don't expect you to "turn your
life upside down" to meet my preferences -- but if you're not willing
to do it so the projects that have been your life's work will remain
able to attract new blood and have a healthy future, that's entirely
another matter.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: What a modern collaboration toolkit looks like

[Thien-Thi Nguyen]

() "Eric S. Raymond" <esr@thyrsus.com>
() Sun, 30 Dec 2007 21:58:36 -0500

   block your projects from using modern tools

i did not see where rms says he intends to block anything,
just that he is not willing to do non-email-based hacking.
(i take that as a personal statement, as one hacker's
preference amongst the group, and a reasonable position
to hold.)

you can save yourself the rant and try to think of a way
to accomodate email-based hacking w/ speedfreak hacking.

as for the "kids" missing out -- let them spin.  what
they chase they will find in emacs, sooner or later.
perhaps it will not be in /usr/bin/emacs, but instead
some .../embedded-emacs-workalike.so; that's irrelevant.

thi

Re: What a modern collaboration toolkit looks like

[John S. Yates, Jr.]

On Mon, 31 Dec 2007 13:14:02 +0100, Thien-Thi Nguyen wrote:

>i did not see where rms says he intends to block anything,
>just that he is not willing to do non-email-based hacking.

The bzr project has an impressive amount of tooling to
support email-based development.  For starters, take a look
at its send command:

  http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#send

and the BundleBuggy tool:

  http://bazaar-vcs.org/BundleBuggy?highlight=%28bundle%29

/john

Re: What a modern collaboration toolkit looks like

[Thien-Thi Nguyen]

() "John S. Yates, Jr." <john@yates-sheets.org>
() Tue, 01 Jan 2008 18:57:18 -0500

   The bzr project has an impressive amount of tooling to
   support email-based development.  For starters, take a look
   at [some bzr features]

thanks for the tip.  maybe i'll get to looking into bzr sometime
in 2008.  i am in the midst of a (now) two-month trial-by-fire
period w/ git.  it's interesting.  some side effects can be seen
at: <http://www.gnuvola.org/wip/>.

i think long term what will win is some distributed system,
presuming the off{line,world ;-} folks and cortical jackers can
maintain mutual respect.

thi

Re: What a modern collaboration toolkit looks like

[Richard Stallman]

    And that's why, when you block your projects from using modern tools,
    it's a serious problem.

If it is a problem (and other people seem to disagree with you on
this), it can't be helped.  I won't change the way I live my life just
so I can use different methods to work on Emacs Working on Emacs is
not all I do.  Meanwhile, using IRC for discussions would be very
inefficient for me, so I won't do that even when I do have a net
connection.

Re: What a modern collaboration toolkit looks like

[Leo]

On 2007-12-31 22:29 +0000, Richard Stallman wrote:
>     And that's why, when you block your projects from using modern tools,
>     it's a serious problem.
>
> If it is a problem (and other people seem to disagree with you on
> this), it can't be helped. 

I don't think other people disagree with ESR. I think people understand
how difficult it is to propose such a solution.

I really appreciate ERS's effort to save the Emacs project.

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .:  [ GPG Key: 9283AA3F ]  :.

          Use the best OS -- http://www.fedoraproject.org/

Re: What a modern collaboration toolkit looks like

[Eli Zaretskii]

> From: "Eric S. Raymond" <esr@snark.thyrsus.com>
> Date: Sun, 30 Dec 2007 07:22:17 -0500 (EST)
> 
> This is a typical modern open-source project.  It's not even a
> particularly large one -- no more than a dozen core devs, 58
> developers total.

A striking difference with Emacs.  We never had such a large group of
active developers.

Re: What a modern collaboration toolkit looks like

[Eric S. Raymond]

Eli Zaretskii <eliz@gnu.org>:
> > This is a typical modern open-source project.  It's not even a
> > particularly large one -- no more than a dozen core devs, 58
> > developers total.
> 
> A striking difference with Emacs.  We never had such a large group of
> active developers.

Really?  How interesting.  Makes me proportionately more important to
Emacs than I thought I was. :-)

The old-timers on this list should be asking themselves why, when Emacs
is so undeniably important, it can't attract as many developers as a
mere fantasy game.

One of the ways the hacker community has changed as it has grown is that
project populations are rather larger on average than they used to be.
I see this as a direct effect of sites like SourceForge, Berlios,
Gna!, Savannah, etc. which make it easier to coordinare larger dev groups.

The Emacs project, though, is still operating at a scale and tempo I
think of as being typical of the late 1980s and early 1990s.  I think
we are limited by poor tools, and by habits of thought derived from
those poor tools.

I'd like to help that change.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: What a modern collaboration toolkit looks like

[Eli Zaretskii]

> Date: Mon, 31 Dec 2007 08:07:12 -0500
> From: "Eric S. Raymond" <esr@thyrsus.com>
> Cc: "Eric S. Raymond" <esr@snark.thyrsus.com>, emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org>:
> > > This is a typical modern open-source project.  It's not even a
> > > particularly large one -- no more than a dozen core devs, 58
> > > developers total.
> > 
> > A striking difference with Emacs.  We never had such a large group of
> > active developers.
> 
> Really?  How interesting.  Makes me proportionately more important to
> Emacs than I thought I was. :-)

I knew there was a compliment there somewhere...

> The old-timers on this list should be asking themselves why, when Emacs
> is so undeniably important, it can't attract as many developers as a
> mere fantasy game.

That's not a question for me.  It's quite clear to me why programming
a game would be more fun than programming a text editor.

And if you are hinting that using CVS is the reason, then I must say
that in the 15 years I've been involved in Emacs development (using
RCS at first, btw), I don't think I've ever heard some potential
contributor say that she refuses to come on board because of the VCS
we use.  Maybe my memory is failing me, who knows.

> The Emacs project, though, is still operating at a scale and tempo I
> think of as being typical of the late 1980s and early 1990s.  I think
> we are limited by poor tools, and by habits of thought derived from
> those poor tools.

My analysis is different: I think we are limited by a small number of
core developers, and by the lack of head maintainer(s) who could
devote much more time than any of us can evidently provide to coding
and leading the rest of the developers.

Re: What a modern collaboration toolkit looks like

[Eric S. Raymond]

Eli Zaretskii <eliz@gnu.org>:
> And if you are hinting that using CVS is the reason,

Not exactly.  I think CVS in itself is *a* reason people sheer away
from the project -- selecting themselves out before you even notice
they're doing that -- but I think CVS is more important as a major
symptom and part-cause of the largest problem this project has.

That largest problem?  Boy howdy, did I get a faceful of it last night
at my friends the Matuszeks' post-Yule party.  They're AI researchers
and their parties attract a rather dizzying assortment of alpha geeks,
considering we're in Pennsylvania. People fly in to be at their
annual bash.

I proudly mentioned my work on VC-mode, and got majorly dumped on for
bothering with Emacs at all.  The kids out there think we're a
stagnant backwater, an old-boys club of bearded grognards that has
learned nothing and forgotten nothing for the last decade.

I'll also say I wasn't all that surprised at this reaction.  I've seen
this image problem building for a while; it's just that before I rejoined
the dev team I had little incentive to address it.

> > The Emacs project, though, is still operating at a scale and tempo I
> > think of as being typical of the late 1980s and early 1990s.  I think
> > we are limited by poor tools, and by habits of thought derived from
> > those poor tools.
> 
> My analysis is different: I think we are limited by a small number of
> core developers, and by the lack of head maintainer(s) who could
> devote much more time than any of us can evidently provide to coding
> and leading the rest of the developers.

I don't disagree with you that either is a serious problem.  But I 
see all three issues (few developers, weak leadership, crappy tools)
as all causally linked and feeding into each other. 

In particular, crappy tools and weak leadership hinder attracting new
developers.  I can't solve the weak leadership problem, so I'm 
focusing on what I know how to do: fix the tools.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: What a modern collaboration toolkit looks like

[Nick Roberts]

 > In particular, crappy tools and weak leadership hinder attracting new
 > developers.  I can't solve the weak leadership problem, so I'm 
 > focusing on what I know how to do: fix the tools.

Stating that Emacs has weak leadership is a ridiculous assertion as it's
a highly successful project by any standards.  I do agree, however, that it's
going through a slow and painful death.

Richard has already stated that he would like to hand over maintenance to one
person or a small team.  Currently you're not offering much more than rhetoric.
If you volunteered to maintain Emacs over the next five years, say, now that
might be an interesting propsition.

Contrary to your suggestions, there are some very talented developers on this
list, and they could probably cover areas of Emacs with which you are not
familiar.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: What a modern collaboration toolkit looks like

[Eric S. Raymond]

Nick Roberts <nickrob@snap.net.nz>:
> Stating that Emacs has weak leadership is a ridiculous assertion as it's
> a highly successful project by any standards.

The "weak leadership" characterization was Eli's, not mine.  I agree with it,
however; Richard has been distracted and operating under some fairly 
crippling constraints.

> Richard has already stated that he would like to hand over
> maintenance to one person or a small team.  Currently you're not
> offering much more than rhetoric.  If you volunteered to maintain
> Emacs over the next five years, say, now that might be an
> interesting propsition.

Alas, I can't do that.  But I have already offered to put in the
full-time effort required to clean up the tools situation in 2008.

This would, among other things, free the actual project lead to think
about the right direction for Emacs itself.

> Contrary to your suggestions, there are some very talented developers on this
> list, and they could probably cover areas of Emacs with which you are not
> familiar.

Eh?  When did I ever suggest the developers here weren't "very talented"?
I believe I've actually said twice that they average more capable than
at Battle For Wesnoth, which is the model I've been exhibiting for 
good tool use.

There is no shortage of talent here.  I'd say some of us have become rather 
too rigid in our thinking, but that's a different issue.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: What a modern collaboration toolkit looks like

[Eli Zaretskii]

> Date: Mon, 31 Dec 2007 19:50:51 -0500
> From: "Eric S. Raymond" <esr@thyrsus.com>
> Cc: esr@snark.thyrsus.com, Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> 
> Nick Roberts <nickrob@snap.net.nz>:
> > Stating that Emacs has weak leadership is a ridiculous assertion as it's
> > a highly successful project by any standards.
> 
> The "weak leadership" characterization was Eli's, not mine.

I didn't say "weak leadership", I said head maintainers that have more
time to spend on Emacs development and leadership than what we have
now.

Re: What a modern collaboration toolkit looks like

[Eric S. Raymond]

Eli Zaretskii <eliz@gnu.org>:
> > Date: Mon, 31 Dec 2007 19:50:51 -0500
> > From: "Eric S. Raymond" <esr@thyrsus.com>
> > Cc: esr@snark.thyrsus.com, Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> > 
> > Nick Roberts <nickrob@snap.net.nz>:
> > > Stating that Emacs has weak leadership is a ridiculous assertion as it's
> > > a highly successful project by any standards.
> > 
> > The "weak leadership" characterization was Eli's, not mine.
> 
> I didn't say "weak leadership", I said head maintainers that have more
> time to spend on Emacs development and leadership than what we have
> now.

Fair enough.  I didn't intend any aspersion on Richard.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: What a modern collaboration toolkit looks like

[Eli Zaretskii]

> Date: Mon, 31 Dec 2007 16:41:08 -0500
> From: "Eric S. Raymond" <esr@thyrsus.com>
> Cc: esr@snark.thyrsus.com, emacs-devel@gnu.org
> 
> I proudly mentioned my work on VC-mode, and got majorly dumped on for
> bothering with Emacs at all.  The kids out there think we're a
> stagnant backwater, an old-boys club of bearded grognards that has
> learned nothing and forgotten nothing for the last decade.

Curiously enough, I'm having an opposite experience these days: a
bunch of extremely able developers who work for years with MS Visual
Studio came to respect Emacs, as a viable and powerful alternative to
the bloated and dog-slow Studio, even on Windows, to say nothing of
GNU/Linux (this is a dual-platform project, where software is
developed to run on both systems).  All I needed to do is introduce
them to some optional features, such as Speedbar, ebrowse, and gdb-ui,
and craft a simple .emacs to bind the various Fn keys to
compile/run/debug commands they were used to have.  After that, I
never again heard anyone of them laughing at "stagnant backwater" that
is Emacs.

Of course, I'm not saying that Emacs is going to win proprietary IDEs
any time soon, just that not everybody "dumps" us right away.

> In particular, crappy tools and weak leadership hinder attracting new
> developers.  I can't solve the weak leadership problem, so I'm 
> focusing on what I know how to do: fix the tools.

Sorry, I was taught to identify the 80-20 divide and concentrate on
the 80 part before I turn to the other 20.  I don't see a point in a
revolution that wastes everybody's resources just to produce a 20% or
25% improvement.  But that's me.

Re: What a modern collaboration toolkit looks like

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

  > > Date: Mon, 31 Dec 2007 16:41:08 -0500
  > > From: "Eric S. Raymond" <esr@thyrsus.com>
  > > Cc: esr@snark.thyrsus.com, emacs-devel@gnu.org
  > > 
  > > I proudly mentioned my work on VC-mode, and got majorly dumped on for
  > > bothering with Emacs at all.  The kids out there think we're a
  > > stagnant backwater, an old-boys club of bearded grognards that has
  > > learned nothing and forgotten nothing for the last decade.
  > 
  > Curiously enough, I'm having an opposite experience these days: a
  > bunch of extremely able developers who work for years with MS Visual
  > Studio came to respect Emacs, as a viable and powerful alternative to
  > the bloated and dog-slow Studio, even on Windows, to say nothing of
  > GNU/Linux (this is a dual-platform project, where software is
  > developed to run on both systems).  All I needed to do is introduce
  > them to some optional features, such as Speedbar, ebrowse, and gdb-ui,
  > and craft a simple .emacs to bind the various Fn keys to
  > compile/run/debug commands they were used to have.  After that, I
  > never again heard anyone of them laughing at "stagnant backwater" that
  > is Emacs.

Care to post an example of such .emacs? 
Maybe it can be used as a skeleton for a package for such users, or
maybe we can change some defaults to match such users' expectations.

Re: What a modern collaboration toolkit looks like

[Mike Mattie]

[-- Attachment #1.1: Type: text/plain, Size: 5207 bytes --]

On Mon, 31 Dec 2007 16:27:07 -0800
Dan Nicolaescu <dann@ics.uci.edu> wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
> 
>   > > Date: Mon, 31 Dec 2007 16:41:08 -0500
>   > > From: "Eric S. Raymond" <esr@thyrsus.com>
>   > > Cc: esr@snark.thyrsus.com, emacs-devel@gnu.org
>   > > 
>   > > I proudly mentioned my work on VC-mode, and got majorly dumped
>   > > on for bothering with Emacs at all.  The kids out there think
>   > > we're a stagnant backwater, an old-boys club of bearded
>   > > grognards that has learned nothing and forgotten nothing for
>   > > the last decade.
>   > 
>   > Curiously enough, I'm having an opposite experience these days: a
>   > bunch of extremely able developers who work for years with MS
>   > Visual Studio came to respect Emacs, as a viable and powerful
>   > alternative to the bloated and dog-slow Studio, even on Windows,
>   > to say nothing of GNU/Linux (this is a dual-platform project,
>   > where software is developed to run on both systems).  All I
>   > needed to do is introduce them to some optional features, such as
>   > Speedbar, ebrowse, and gdb-ui, and craft a simple .emacs to bind
>   > the various Fn keys to compile/run/debug commands they were used
>   > to have.  After that, I never again heard anyone of them laughing
>   > at "stagnant backwater" that is Emacs.
> 
> Care to post an example of such .emacs? 
> Maybe it can be used as a skeleton for a package for such users, or
> maybe we can change some defaults to match such users' expectations.

I have tried to do something like this but I have constantly run into
what I think is the true issue facing Emacs, the fact that it is forked
almost to death.

There are three forks of Emacs for Mac OS X, cedet is maintained outside
of the mainline, the Ohio Lisp archive died ages ago, slime is third party,
and icicles distributes through the emacs wiki.

Why does Emacs branch, until the branches become so old that you are forced
to admit they are a fork ?

It may be that Emacs simply tries to set a higher standard for merging, a standard
that the current tools and practices do not support well. Or there may be an
artificial barrier.

As long as assembling a modern, slick Emacs consists of scavenging various
pieces scattered across the net with unreliable hosting, and uncertain maintainer-ship,
it's extremely hard to build a cross-platform Emacs. 

I have found the Emacs community to be one of the most responsive and skilled 
group of developers in open-source, but trying to straddle all the schisms to 
support users is really hard.

Here is a code example of how I am trying to solve this problem. When I have a part
of the emacs setup that is only distributed with some of the emacs forks, or none
I split the setup into a separate file.

I have a macro that traps errors on load.

(defmacro load-guard ( file error )
  "Trap errors from loading a file for robustness while initializing."
  `(condition-case nil
     (load (concat my-emacs-dir ,file))
     (error (progn
              ;; duplicate the message to both *Messages* as a log
              ;; and to the *scratch* buffer where it is highly visible.
              (message "initialization failed %s" ,error)
              (with-current-buffer "*scratch*"
                (goto-char (point-max))
                (insert (format "; !degraded configuration! %s\n" ,error)))
              ))
     ))


Inside the file for spelling support I start it with something like this:

(defun install-flyspell ()
  "install or update flyspell"
  (interactive)
  (dl-elisp "http://www-sop.inria.fr/mimosa/Manuel.Serrano/flyspell/flyspell-1.7n.el" "flyspell"))

(require 'flyspell)

config....


The idea is that if require fails then it raises an error, and the user has a function to install
the functionality. They can then re-execute the configuration once the necessary elisp is installed.
Each of the files must have all of the features required as require forms to ensure that it does not
configure features that are not installed.

This could be made into a much slicker macro that would generate the check,install defuns from a
nice syntax.

This scheme in practice really doesn't work all that well, because you need reliable hosting for the
packages, and you need the last 5 or 10 versions with the version encoded in the URL/path so you can
lock a config to a known good version tested against the other components. The provide/require
lacks version information. That is another killer. Emacs.app provides flyspell, but what version ?

I am not proposing this sort of lightweight package management as a solution, rather as an example
of the reality of trying to create an Emacs setup that includes all of the wonderful creativity
and innovation that is the hallmark of Emacs.

So why do Emacs branches last for years instead of months ? Why is Emacs forked to death ?
These are not rhetorical punctuations of a vision, but rather real questions.

> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

RE: What a modern collaboration toolkit looks like

[Drew Adams]

> I have constantly run into what I think is the true issue facing
> Emacs, the fact that it is forked almost to death.
>
> There are three forks of Emacs for Mac OS X, cedet is maintained outside
> of the mainline, the Ohio Lisp archive died ages ago, slime is
> third party, and icicles distributes through the emacs wiki.

I really, really (!) do not want to get involved with this thread.

But since you opened a tiny parenthesis by mentioning Icicles, Mike, I'll
respond to that. [Inserts foot in door.]

There are lots of libraries and code snippets that are distributed on Emacs
Wiki. And that's a good thing, not a bad thing. gnu-emacs-sources is also a
good place to distribute libraries. Nothing wrong with either.

I don't interpret your remark negatively, but as a compliment. But I want to
be clear that Icicles and many other libraries that are not distributed as
part of Emacs do not constitute forks of Emacs. As far as Icicles is
concerned, it is compatible with Emacs 20 through 23. IOW, it is more
compatible with Emacs than Emacs is. ;-)

There are lots of possible reasons why a given library is not integrated
with Emacs and distributed as part of it. The Emacs world is not limited to
GNU Emacs, and even the GNU Emacs world is not limited to the code
distributed with GNU Emacs. The fact that there are multiple degrees of
unity and multiple means of distribution is rather a sign of vitality, IMO,
not of decline.

Speaking only of Icicles, using it as an example, I will say that though
there would be some advantages to having Icicles as part of Emacs, there
would be some disadvantages also. Since it is separate, I am the only
author, and the user base is relatively small, who cares? I am free to take
it where I like, which means I can shape it in any weird way I might dream
up.

IOW, Icicles has the benefit of being a lab, and I have the privilege of
playing mad scientist. Don't get me wrong, I try to respond to users, as you
know, but it's not the same sort of sober commitment that Emacs development
offers. To me, Emacs is a game, not just a tool to get a job done. I don't
even use Emacs for anything anymore - just for farting around with Emacs
Lisp, an end in itself, a job I never want to get done.

The plus side of this state of affairs is that Icicles can serve as a set of
UI experiments - a late night snack for thought. The minus side is that if
you get addicted to using it you might want to save a copy of today's
version because tomorrow's might be too far out there for your taste ;-). Ya
never know. And you have only one developer to deal with, which also has its
pros and cons.

I would say that (1) it is generally good that Emacs developers take the
integrity of the Emacs code base seriously, and (2) there is also room for
Emacs development outside the innermost tent.

When it comes to things I would like to see changed in Emacs, I sometimes
find (nameless) Emacs developers too close-minded and tight-assed. I tell
myself that they lack imagination. But when it comes to things that I don't
want to see changed in Emacs, I can find the same developers too
loosey-goosey and wish they'd stop messing it up arbitrarily. Taken
together, and given that I am only one consumer of Emacs, those opposite
judgments probably indicate that the developers are not too far off track on
average. ;-)

So consider this my toast to the New Year - here's to Emacs!

Nah, not to you guys - Emacs is more than any of us, RMS included. Emacs has
a life of its own. Offspring are like that. And I'd be willing to bet that
it will have a very long life. My guess is that Emacs will outlive the
future daughter of the youngest gadget-&-gamesick, pimply and ircsome
recruit that any pied-piper pledge drive might bring under its spell.
Nothing wrong with cross-fertilization, new blood, new tools, and new means
of discussion, development, and distribution.

All of that wake-up-and-smell-the-coffee pep-talk stuff is about us and GNU
Emacs as a project, however; it's not so much about Emacs. Emacs dead or
declining? Nah.

40 years from now, in another cocktail soiree, someone will still be
prancing on about how dull, old-fashioned, and decrepit Emacs is, and
everyone there will nod and agree and wonder how and why it still keeps
dragging its sorry, tres depassee ass along. Why doesn't someone put the
damn thing out of its misery?  But Ol' Man Emacs, dat Ol' Man Emacs, he mus'
know sumpin', but don' say nothin'; he jes' keeps rollin', he keeps on
rollin' along...

Re: What a modern collaboration toolkit looks like

[Agustin Martin]

On Mon, Dec 31, 2007 at 07:00:34PM -0800, Mike Mattie wrote:
> Inside the file for spelling support I start it with something like this:
> 
> (defun install-flyspell ()
>   "install or update flyspell"
>   (interactive)
>   (dl-elisp "http://www-sop.inria.fr/mimosa/Manuel.Serrano/flyspell/flyspell-1.7n.el" "flyspell"))
> 
> (require 'flyspell)
> 
> config....

Just a side note here, Manuel is no longer maintaining flyspell.el, although
he puts some flyspell.el in his personal page. flyspell.el from emacs cvs is by far
more up-to-date, but you may need an actual emacs for some of the features.

-- 
Agustin

Re: What a modern collaboration toolkit looks like

[Richard Stallman]

    I have found the Emacs community to be one of the most responsive and skill=
    ed=20
    group of developers in open-source,

Please do not use the term "open source" to describe what Emacs is in.
Emacs is part of the GNU Project, which is part of the free software
movement.  To call us "open source" is like callingt Kucinich a
Republican.

    , but trying to straddle all the schisms =
    to=20
    support users is really hard.

We sometimes adopt features to make it easier for code
to run in the variants of Emacs.  But I don't really understand
what you mean by "split the setup" here,

    When I hav=
    e a part
    of the emacs setup that is only distributed with some of the emacs forks, o=
    r none
    I split the setup into a separate file.

so I don't understand the issue.

    Inside the file for spelling support I start it with something like this:

What is "the file for spelling support"?  I am totally lost.
Do you mean ispell.el?  If not that, then what?

Re: What a modern collaboration toolkit looks like

[Mike Mattie]

[-- Attachment #1.1: Type: text/plain, Size: 6199 bytes --]

On Thu, 03 Jan 2008 04:50:57 -0500
Richard Stallman <rms@gnu.org> wrote:

>     I have found the Emacs community to be one of the most responsive
> and skill= ed=20
>     group of developers in open-source,
> 
> Please do not use the term "open source" to describe what Emacs is in.
> Emacs is part of the GNU Project, which is part of the free software
> movement.  To call us "open source" is like callingt Kucinich a
> Republican.
> 
>     , but trying to straddle all the schisms =
>     to=20
>     support users is really hard.
> 
> We sometimes adopt features to make it easier for code
> to run in the variants of Emacs.  But I don't really understand
> what you mean by "split the setup" here,

I think I can articulate this a bit better now. My interest in this
thread revolved around the idea of a more advanced Emacs user being
able to help a newer user setup a Emacs environment that is appealing
with more features than the default configuration.

Helping a new user requires some subtly, as simply dumping a large
configuration on a new user does not work well. An older user has
had alot of time to add the customizations incrementally and adjust
to them incrementally.

The new user when they receive such a configuration first has to
get the configuration running. If the advanced user has downloaded
alot of third-party elisp the configuration file will likely generate
errors and abort the loading of the configuration file.

The new user also has to integrate the new features and behavior into
their workflow which takes time, and is alot easier when done in
small pieces.

So split the setup means break up the user's .emacs file into parts:

config/
   .emacs
   style/ -> spell.el ; spell features
          -> lisp.el  ; lisp programming features

the .emacs file is carefully coded to make sure that it has a low
risk of errors. Note that the style directory is not included in load-path
deliberately.

I named the directory style as a metaphor from the world of martial arts.
In martial arts the harmonious blend of a set of techniques is often
called a "fighting style" or some such thing. In this case turning
on, adding, and customizing the various spelling features of Emacs to the
point where spelling support is pervasive and well integrated constitutes
a modular style of using Emacs.

each of these large customization files such as spell.el have this basic form:

phase 1: define a installer

phase 2: check dependencies with require

phase 3: perform customization

My simple load-guard macro trapped errors during loading and suggests a installation method.

The installation method does not necessarily need to be a package manager implemented in elisp.
A table that maps features to package names for various package managers is sufficient. The final
piece is a nice Emacs interface to the common package managers.

With a configuration split up in the way I have described above it is alot easier to help
another user use and learn the more advanced capabilities of Emacs. The advanced configuration
is split up into parts like a curriculum. They can turn on all of "Guru Bob's" spelling features 
and integrate them into their workflow without having to learn at the same time all of his lisp 
tweaks, and other enhancements.

A typical scenario would then go something like this:

1. User request's some help getting their Emacs setup with some of Bob's (Guru) features.
2. User receives The Guru's modular configuration and installs it.
3. The user chooses a feature set they are going to integrate into their work-flow, so they
   move the configuration for the features into the style directory where it will be picked
   up by the core .emacs file.

4. When they start emacs next it will likely not have necessary libraries, and so It tells
   them that the configuration is degraded and that they can type "install-foo" to fetch
   the necessary parts.

5. install foo determines what package manager is in use on the host, and searches the package
   system for the package names. It displays the search results for the user with a interface
   that generates the correct package manager commands and feeds them to the package manager
   via sudo or su if necessary.

6. with the libraries installed they can load the configuration file again. Since it aborted
   when the dependencies weren't met it didn't leave Emacs in a partially configured state.

It doesn't require especially clever code to construct a configuration like this, just
a little bit of elisp and a plan for how the configuration is organized. Assuming that Emacs
is a good fit for the user they will likely pick it up fairly quickly, and soon write
their own configuration. Without the beginning of the learning curve being broken up into
steps it is very hard for even a eager new user to comprehend the potential of Emacs, especially
when they are trying to quickly match the productivity of their old environment.

The end result is a a middle ground for the new user. Instead of a dilemma of either starting 
from scratch and cherry-picking random elisp code without the elisp skills to integrate the code 
fragements properly, or choosing a massive jumbo configuration with another foreboding learning
curve and no upgrade path, they can now incrementally adopt advanced features and configuration
incrementally.

A good question at this point is where does this fit into Emacs ? I have seen many "Jumbo configs" 
for java etc. A best practices guide for creating such configurations, along with some
modes for the common package managers out there might be useful.


>     When I hav=
>     e a part
>     of the emacs setup that is only distributed with some of the
> emacs forks, o= r none
>     I split the setup into a separate file.
> 
> so I don't understand the issue.
> 
>     Inside the file for spelling support I start it with something
> like this:
> 
> What is "the file for spelling support"?  I am totally lost.
> Do you mean ispell.el?  If not that, then what?

Hopefully I have explained it a bit better, if not let me know.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: What a modern collaboration toolkit looks like

[Richard Stallman]

    So split the setup means break up the user's .emacs file into parts:

    config/
       .emacs
       style/ -> spell.el ; spell features
	      -> lisp.el  ; lisp programming features

    the .emacs file is carefully coded to make sure that it has a low
    risk of errors. Note that the style directory is not included in load-path
    deliberately.

We ask people not to start off beginners with a customized Emacs.
A new users should learn a standard Emacs, and then customize it
if he wants to customize it.  But he shouldn't be led into using
something nonstandard before he knows the difference.

    In this case turning
    on, adding, and customizing the various spelling features of Emacs to the
    point where spelling support is pervasive and well integrated constitutes
    a modular style of using Emacs.

Do you think that enabling the spelling features of Emacs is complex?
If so, maybe we should simplify it.  That would be a better solution
to this problem, if it exists.


    each of these large customization files such as spell.el have this basic fo=
    rm:

    phase 1: define a installer

    phase 2: check dependencies with require

    phase 3: perform customization

Why is so much needed just to enable spelling features?

    1. User request's some help getting their Emacs setup with some of Bob's (G=
    uru) features.
    2. User receives The Guru's modular configuration and installs it.

If "Bob's features" refers to Lisp packages not included in Emacs,
then why not install them in the standard directory on the user's
machine?  There `load-library' will find them without any special
effort.

Re: What a modern collaboration toolkit looks like

[Richard Stallman]

    I have found the Emacs community to be one of the most responsive and skill=
    ed=20
    group of developers in open-source,

Please do not use the term "open source" to describe what Emacs is in.
Emacs is part of the GNU Project, which is part of the free software
movement.  To call us "open source" is like calling Kucinich a
Republican.

See http://www.gnu.org/philosophy/open-source-misses-the-point.html
for more explanation.

Re: What a modern collaboration toolkit looks like

[Eli Zaretskii]

> From: Dan Nicolaescu <dann@ics.uci.edu>
> Cc: emacs-devel@gnu.org
> Date: Mon, 31 Dec 2007 16:27:07 -0800
> 
>   > All I needed to do is introduce
>   > them to some optional features, such as Speedbar, ebrowse, and gdb-ui,
>   > and craft a simple .emacs to bind the various Fn keys to
>   > compile/run/debug commands they were used to have.  After that, I
>   > never again heard anyone of them laughing at "stagnant backwater" that
>   > is Emacs.
> 
> Care to post an example of such .emacs? 
> Maybe it can be used as a skeleton for a package for such users, or
> maybe we can change some defaults to match such users' expectations.

There's nothing too fancy about it; most of it goes like this:

  (defun ez-clcheckout ()
    "Checkout from ClearCase the file visited by current buffer."
    (interactive)
    (shell-command (format "cleartool co %s" buffer-file-name))
    (revert-buffer nil t))
  (global-set-key (kbd "<f9>") 'ez-clcheckout)
  (defun ez-clcheckin ()
    "Checkin to ClearCase the file visited by current buffer."
    (interactive)
    (shell-command
	(format "cleartool ci %s" buffer-file-name))
    (revert-buffer nil t))
  (global-set-key (kbd "<C-f9>") 'ez-clcheckin)
  (defun ez-maketarg ()
    "Build the project in current buffer's directory."
    (interactive)
    (save-buffer)
    (if (eq system-type 'windows-nt)
	(compile compile-command)
      (compile "gmake -k DEBUG")))

  (global-set-key (kbd "<f7>") 'ez-maketarg)
  (add-hook 'c-mode-common-hook
	 (lambda ()
	   (unless (or (file-exists-p "makefile")
		       (file-exists-p "Makefile"))
	     (let* ((dsp-dir (file-name-directory buffer-file-name))
		    (dsp-file (downcase (file-name-nondirectory
					 (directory-file-name dsp-dir)))))
	       (set (make-local-variable 'compile-command)
		    (concat "devenv.com "
			    (convert-standard-filename dsp-dir)
			    dsp-file
			  ".vcproj debug /rebuild"))))))

  (global-set-key (kbd "<f4>") 'next-error)

Re: What a modern collaboration toolkit looks like

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

  > > From: Dan Nicolaescu <dann@ics.uci.edu>
  > > Cc: emacs-devel@gnu.org
  > > Date: Mon, 31 Dec 2007 16:27:07 -0800
  > > 
  > >   > All I needed to do is introduce
  > >   > them to some optional features, such as Speedbar, ebrowse, and gdb-ui,
  > >   > and craft a simple .emacs to bind the various Fn keys to
  > >   > compile/run/debug commands they were used to have.  After that, I
  > >   > never again heard anyone of them laughing at "stagnant backwater" that
  > >   > is Emacs.
  > > 
  > > Care to post an example of such .emacs? 
  > > Maybe it can be used as a skeleton for a package for such users, or
  > > maybe we can change some defaults to match such users' expectations.
  > 
  > There's nothing too fancy about it; most of it goes like this:

Thanks.

  >   (defun ez-clcheckout ()
  >     "Checkout from ClearCase the file visited by current buffer."
  >     (interactive)
  >     (shell-command (format "cleartool co %s" buffer-file-name))
  >     (revert-buffer nil t))
  >   (global-set-key (kbd "<f9>") 'ez-clcheckout)
  >   (defun ez-clcheckin ()
  >     "Checkin to ClearCase the file visited by current buffer."
  >     (interactive)
  >     (shell-command
  > 	(format "cleartool ci %s" buffer-file-name))
  >     (revert-buffer nil t))
  >   (global-set-key (kbd "<C-f9>") 'ez-clcheckin)

Maybe this should use vc-clearcase (if such a thing exists). 

Are the f9 and C-f9 the usual keys for this type of functionality in
one some platforms? 

Would be useful for us to add some default extra bindings to the
functions keys for the VC functions?


  >   (defun ez-maketarg ()
  >     "Build the project in current buffer's directory."
  >     (interactive)
  >     (save-buffer)
  >     (if (eq system-type 'windows-nt)
  > 	(compile compile-command)
  >       (compile "gmake -k DEBUG")))
  > 
  >   (global-set-key (kbd "<f7>") 'ez-maketarg)
  >   (add-hook 'c-mode-common-hook
  > 	 (lambda ()
  > 	   (unless (or (file-exists-p "makefile")
  > 		       (file-exists-p "Makefile"))
  > 	     (let* ((dsp-dir (file-name-directory buffer-file-name))
  > 		    (dsp-file (downcase (file-name-nondirectory
  > 					 (directory-file-name dsp-dir)))))
  > 	       (set (make-local-variable 'compile-command)
  > 		    (concat "devenv.com "
  > 			    (convert-standard-filename dsp-dir)
  > 			    dsp-file
  > 			  ".vcproj debug /rebuild"))))))

I always wished we had a nice one key binding to a "smart" version of
M-x compile...

  >   (global-set-key (kbd "<f4>") 'next-error)

We already use f4, so this can't be bound by default :-(

Re: What a modern collaboration toolkit looks like

[Eli Zaretskii]

> From: Dan Nicolaescu <dann@ics.uci.edu>
> Cc: emacs-devel@gnu.org
> Date: Tue, 01 Jan 2008 20:17:36 -0800
> 
>   >   (defun ez-clcheckout ()
>   >     "Checkout from ClearCase the file visited by current buffer."
>   >     (interactive)
>   >     (shell-command (format "cleartool co %s" buffer-file-name))
>   >     (revert-buffer nil t))
>   >   (global-set-key (kbd "<f9>") 'ez-clcheckout)
>   >   (defun ez-clcheckin ()
>   >     "Checkin to ClearCase the file visited by current buffer."
>   >     (interactive)
>   >     (shell-command
>   > 	(format "cleartool ci %s" buffer-file-name))
>   >     (revert-buffer nil t))
>   >   (global-set-key (kbd "<C-f9>") 'ez-clcheckin)
> 
> Maybe this should use vc-clearcase (if such a thing exists). 

It exists, but the users for whom I made these customizations weren't
used to having any interface to ClearCase in the IDE besides
checkout/checkin commands.  So I didn't bother installing
vc-clearcase, because doing so would need to make global changes on
our several dozen lab computers.

> Are the f9 and C-f9 the usual keys for this type of functionality in
> one some platforms? 

AFAIU, they are in Visual Studio.

> Would be useful for us to add some default extra bindings to the
> functions keys for the VC functions?

Probably.

>   >   (global-set-key (kbd "<f4>") 'next-error)
> 
> We already use f4, so this can't be bound by default :-(

Yeah, and I'd be damned if I understand why it's important.

Re: What a modern collaboration toolkit looks like

[Eric S. Raymond]

Eli Zaretskii <eliz@gnu.org>:
> > I proudly mentioned my work on VC-mode, and got majorly dumped on for
> > bothering with Emacs at all.
> 
> Curiously enough, I'm having an opposite experience these days:

I completely believe you.  I think our accounts unify nicely if you
reflect that the people giving me crap were mainly Eclipse fans --
ex-Emacs users who think they've found something better.

On the other hand, anybody who's been stuck using Microsoft tools...
well, of *course* Emacs is better; an Acheulian flint hand-axe would
probably strike those poor bastards as an improvement.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: What a modern collaboration toolkit looks like

[Eli Zaretskii]

> Date: Mon, 31 Dec 2007 19:57:49 -0500
> From: "Eric S. Raymond" <esr@thyrsus.com>
> Cc: esr@snark.thyrsus.com, emacs-devel@gnu.org
> 
> On the other hand, anybody who's been stuck using Microsoft tools...

These tools still have a few features that Emacs could benefit from,
such as a better class browser, visual code folding, function and
variable hints in tooltips, etc.  Ebrowse did not see any significant
development since its introduction in v21.1.

Re: What a modern collaboration toolkit looks like

[Miles Bader]

"Eric S. Raymond" <esr@thyrsus.com> writes:
> Boy howdy, did I get a faceful of it last night at my friends the
> Matuszeks' post-Yule party.  They're AI researchers and their parties
> attract a rather dizzying assortment of alpha geeks,
...
> I proudly mentioned my work on VC-mode, and got majorly dumped on for
> bothering with Emacs at all.

These people apparently treat software as some kind of fashion contest.
Do you expect us to put any stock in what they say?

-MIles

-- 
The secret to creativity is knowing how to hide your sources.
  --Albert Einstein

Re: What a modern collaboration toolkit looks like

[Eric S. Raymond]

Miles Bader <miles@gnu.org>:
> These people apparently treat software as some kind of fashion contest.
> Do you expect us to put any stock in what they say?

Well...at least two of them, to my certain personal knowledge, have
been expert Emacs users in the past.  (I'm thinking of David and Cyndy
Matuszek, in case anyone here has ever met them.)

They're not fashionistas. They have a belief, which is not badly founded
given the evidence available to them, that the Emacs project is old,
tired, badly run, and effectively moribund.

I can't say that I blame them much for this.  We have a lot of work to
do to re-establish the level of credibility we enjoyed at the time I
was last directly involved in the early 1990s.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: What a modern collaboration toolkit looks like

[Miles Bader]

"Eric S. Raymond" <esr@thyrsus.com> writes:
> They're not fashionistas. They have a belief, which is not badly founded
> given the evidence available to them, that the Emacs project is old,
> tired, badly run, and effectively moribund.

Are they judging the software, or the "project"?

In my activitiy as a "branch merger", as well as reading the mailing
list, I see the activity of the Emacs project in a fair amount of
detail.  It's quite clear to me that while the Emacs project is
obviously old (hard to change that :-), it's neither "tired" nor
"moribund"; indeed, sometimes I rather wish people would be a bit _less_
enthusiastic about making changes.... :-/

[Note that I'm all for moving to more modern tools.  Subversion is
probably not a great choice though -- if we're going to change, we
should change to one of the distributed systems like git.]

-Miles

-- 
The key to happiness
 is having dreams.	[from a fortune cookie]

Re: What a modern collaboration toolkit looks like

[Eric S. Raymond]

Miles Bader <miles@gnu.org>:
> "Eric S. Raymond" <esr@thyrsus.com> writes:
> > They're not fashionistas. They have a belief, which is not badly founded
> > given the evidence available to them, that the Emacs project is old,
> > tired, badly run, and effectively moribund.
> 
> Are they judging the software, or the "project"?

Fair question.  I caught a little of both.  I'm not sure they're
clearly distinguished in the critics' thinking.

David Matuszek (star CS professor at UPenn) has been griping at me
for years about things like features he relied upon disappearing
during version upgrades.  He's made it very clear that he thinks this
sort of thing is a symptom of inattention to what users are actually
doing with the software by developers too obsessed with the next cool
hack.  I think that counts as both software and project croticism.

Cyndy (AI researcher, Dave's daughter, formerly with Doug Lenat's Cyc
project and now doing a six-year gig in Seattle) didn't particularly
slam the software, but was entertainingly rude about CVS.  One of her
milder remarks was to the effect that "Somebody needs to remind RMS
what year it is."  There wasn't much I could say about this project
criticism given that I pretty completely agree with it.

Matt, whose last name I didn't catch but who I think is a software
designer at Google, came the closest to having a "fashionista"
position; he thinks Eclipse's UI makes Emacs's look paleolithic.

There was someone else in the discussion who's a doctoral candidate at CMU
doing research in language design -- I don't remember what her gripe
was but she sure wasn't giving Emacs any love.

It was rather unnerving.
 
> [Note that I'm all for moving to more modern tools.  Subversion is
> probably not a great choice though -- if we're going to change, we
> should change to one of the distributed systems like git.]

Agreed, one of the 3Gs would be better.  I'm doing a technical survey paper
on them now; I'll be *extremely* well equipped to choose one well-fitted
for the Emacs project's needs when that's done.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: What a modern collaboration toolkit looks like

[Tom Tromey]

>>>>> "Miles" == Miles Bader <miles@gnu.org> writes:

Miles> These people apparently treat software as some kind of fashion
Miles> contest.  Do you expect us to put any stock in what they say?

I tell all my friends that I work in a fashion industry :-).  How else
to explain the long parade of fads and silver bullets, or at least
silver-handled six-shooters?  But seriously...


A couple years ago, after using and loving Emacs for 15 years, I moved
all my Java development into Eclipse.  I did this despite the facts
that Eclipse's editor is amazingly bad and its UI is clunky and
impossible to customize.

The reason I did this is that Eclipse provides a number of compelling
features which Emacs does not.  At least, it does for Java -- for
other programming languages it is not nearly as useful, IME.

* An integrated Java compiler that knows about your whole project.
  This has a number of nice implications:

  * No more waiting.  It compiles while you type.  When you save a
    file you are ready to run your tests immediately.
  * Class browsing, call hierarchy information ("find all callers of
    this method"), intelligent completion, documentation and API help
    while you type.
  * Refactoring.  E.g., a simple one is "rename this class".  If you
    rename into a different package it will update all users, all
    import statements, etc.  (There are lots of nice refactorings.)
  * Quick fix.  Certain common problems (warnings and whatnot) can
    come with a fix, you click and Eclipse fixes your code.
  * Will write the Javadoc "skeleton" for you, so you can just fill in
    the details.
  * A problem view.  I loved this.  Instead of compiling and then
    stepping through errors and warnings, the view shows everything,
    is always up-to-date, and is filterable.

* Eclipse knows about projects, and you can easily share settings with
  other developers.  (This is what inspired my as-yet-unfinished
  "project.el" hacks.)  This means that getting a new developer
  up-and-running is extremely easy.

  Combined with the integrated compiler and build setup, usually a
  developer can check out a project and immediately have it be built
  and be ready to work.  You can check in launchers so that common
  test or debug invocations are automatically available after
  checkout.

  Many features are trivial to restrict to the current project -- the
  problem view, searches, browsing, file-name completion.  In Emacs
  most things are global by default -- you can run a single gdb,
  find-tag uses a global tags buffer, etc.

* The version control UI is much friendlier than VC.  At least, that
  is true as of a couple weeks ago.

Newer versions have bugzilla integration, and task-based ways to
filter what you work on and see ("mylyn" -- I still haven't played
with this).

The above is necessarily a brief list.  I can go into more detail if
you really want.  Basically, for Java, Eclipse changed the way I work.

It pained me to make this move.  I love Emacs.  But, Emacs doesn't get
the same level of investment, and at the time appeared from the
outside to be dead (no release in years).

None of these features is impossible to implement in Emacs.  In fact
many could probably be done by reusing Eclipse's Java compiler.


Another interesting IDE to look at is NetBeans.  I've used it a lot
less than I used Eclipse, and it seemed to have fewer killer features.
But I went to JavaOne last year and saw something really interesting
-- every new technology introduced during a keynote came with a
corresponding NetBeans plugin.  And, you could get started using that
technology *immediately* by going to some online NetBeans repository
(accessible directly in the IDE) and downloading the plugin.

This is, more or less, where ELPA came from.  The idea is simple --
your IDE won't ever contain absolutely everything, so make it trivial
to fetch and install helpful packages.  (Eclipse also has a plugin
downloader, though it is pretty bad.)


Anyway, the bar for a programming editor is much higher now than when
I started using Emacs.  Nowadays intelligent completion, API help,
browsing, and refactoring are the baseline.  Emacs does some of these
in some modes -- elisp is the best example; lisp-complete-symbol and
eldoc are quite nice -- but for most modes this stuff is either
missing, or the defaults are wrong.


I hope you don't mind that I don't enumerate Emacs' many advantages.
There are tons of them.  Emacs is very, very strong at the mechanics
of editing, and it is very simple to extend (lisp may be weird or
whatever, but even a trivial Eclipse plugin is really hard).  However,
while Emacs rocks at these things, the IDEs have been working hard to
intelligently analyze source and apply this understanding in useful
ways.


HTH,
Tom

Re: What a modern collaboration toolkit looks like

[Nick Roberts]

 > A couple years ago, after using and loving Emacs for 15 years, I moved
 > all my Java development into Eclipse.  I did this despite the facts
 > that Eclipse's editor is amazingly bad and its UI is clunky and
 > impossible to customize.
 > 
 > The reason I did this is that Eclipse provides a number of compelling
 > features which Emacs does not.  At least, it does for Java -- for
 > other programming languages it is not nearly as useful, IME.
 > 
 > * An integrated Java compiler that knows about your whole project.
 >   This has a number of nice implications:
 > 
 >   * No more waiting.  It compiles while you type.  When you save a
 >     file you are ready to run your tests immediately.
 >   * Class browsing, call hierarchy information ("find all callers of
 >     this method"), intelligent completion, documentation and API help
 >     while you type.

[snip - long list]

Yes, I agree.  While Emacs has certainly moved forward over the last few years,
relatively it's fallen behind and I suspect many users are moving to other
applications like Eclipse.  It's a vicious circle: if we are ever to catch up
we need more developers and attract them we need more users.  That's why I
think it's counterproductive to hold back releases for bugs like:

** eric@openbsd.org, 24 Nov: c-mode syntactic analysis regression in emacs-22.1

which might irritate some people but will hardly drive people away from using
Emacs in large numbers.

A bug tracker could record such bugs and track its status.  In my experience,
such bugs do get fixed, albeit several releases later.

However, if the issue is ideological, i.e., that code is not released with any
known bugs is more important than having a user base then there is no argument,
of course.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: What a modern collaboration toolkit looks like

[Miles Bader]

Tom Tromey <tromey@redhat.com> writes:
> Anyway, the bar for a programming editor is much higher now than when
> I started using Emacs.  Nowadays intelligent completion, API help,
> browsing, and refactoring are the baseline.  Emacs does some of these
> in some modes -- elisp is the best example; lisp-complete-symbol and
> eldoc are quite nice -- but for most modes this stuff is either
> missing, or the defaults are wrong.

I've actually used Eclipse a lot for Java programming, and it has many
nice features (many of which you list).  However, it's definitely a
mixed bag -- the UI is _so_ baroque and often confusing, and in general
so "rigid" (not to mention slowwwwww) that often I found myself wishing
for Emacs again.  A mixed bag.

My wish is that Emacs gets "Emacsy" versions of Eclipse's best features,
not that Emacs becomes anything like Eclipse (which has a truly awful
user interface...).

-Miles

-- 
"Whatever you do will be insignificant, but it is very important that
 you do it."  Mahatma Gandhi

Re: What a modern collaboration toolkit looks like

[Tom Tromey]

>>>>> "Miles" == Miles Bader <miles@gnu.org> writes:

Miles> I've actually used Eclipse a lot for Java programming, and it has many
Miles> nice features (many of which you list).  However, it's definitely a
Miles> mixed bag -- the UI is _so_ baroque and often confusing, and in general
Miles> so "rigid" (not to mention slowwwwww) that often I found myself wishing
Miles> for Emacs again.  A mixed bag.

Yeah.  For me the tradeoffs were compelling enough to switch -- it
made me notably more efficient.

But it is true you need a much more powerful machine to run Eclipse.
Remember the good old days when people made jokes about Emacs' size?
Eclipse uses much more memory.

And, if you're used to Emacs' high level of integration and ease of
hackability, it takes some getting used to.  I think if you are come
from a more GUI-ish world, Eclipse is only mildly sucky -- from my
GUI-using friends I hear some complaints but mostly around the edges.

Miles> My wish is that Emacs gets "Emacsy" versions of Eclipse's best features,
Miles> not that Emacs becomes anything like Eclipse (which has a truly awful
Miles> user interface...).

I'm in complete agreement.  And much of it, like java compiler stuff,
should not be done in Emacs itself, IMO.

Tom

On-the-fly compiling (was Re: What a modern collaboration toolkit looks like)

[Mark A. Hershberger]

Tom Tromey <tromey@redhat.com> writes:

> Miles> My wish is that Emacs gets "Emacsy" versions of Eclipse's best
> Miles> features, not that Emacs becomes anything like Eclipse (which
> Miles> has a truly awful user interface...).
>
> I'm in complete agreement.  And much of it, like java compiler stuff,
> should not be done in Emacs itself, IMO.

Check out flymake which has support for jikes.  I am not a Java hacker,
but I did set up flymake with Jikes when I was looking at some Java
projects.  I'd be happy to see if I can dig up that setup again, if
you're interested.

-- 
http://hexmode.com/
GPG Fingerprint: 7E15 362D A32C DFAB E4D2  B37A 735E F10A 2DFC BFF5

My happiness grows in direct proportion to my acceptance, and in
inverse proportion to my expectations.  -- Michael J. Fox

Re: On-the-fly compiling

[Stefan Monnier]

> Check out flymake which has support for jikes.  I am not a Java hacker,
> but I did set up flymake with Jikes when I was looking at some Java
> projects.  I'd be happy to see if I can dig up that setup again, if
> you're interested.

I'd be interested to see it and maybe add something like it to
flymake.el's documentation.


        Stefan

Re: On-the-fly compiling

[Lennart Borgman (gmail)]

Stefan Monnier wrote:
>> Check out flymake which has support for jikes.  I am not a Java hacker,
>> but I did set up flymake with Jikes when I was looking at some Java
>> projects.  I'd be happy to see if I can dig up that setup again, if
>> you're interested.
> 
> I'd be interested to see it and maybe add something like it to
> flymake.el's documentation.


Is Jikes maintained? What about this:

   http://sourceforge.net/project/showfiles.php?group_id=128803

Re: On-the-fly compiling

[Tom Tromey]

>>>>> "Mark" == Mark A Hershberger <mah@everybody.org> writes:

Mark> Check out flymake which has support for jikes.  I am not a Java hacker,
Mark> but I did set up flymake with Jikes when I was looking at some Java
Mark> projects.  I'd be happy to see if I can dig up that setup again, if
Mark> you're interested.

Yeah, I haven't done all my "due diligence" -- I haven't tried flymake
and I haven't tried JDEE.  Auto-building is just one feature among
many, though.  Even JDEE, AFAICT, only provides a subset of what
Eclipse does.

Note that jikes is quite far behind the times, Java-wise.  I don't
know anybody who uses it any more, because it does not support Java 5.
Retrofitting this is a major task and, I think, pointless -- there are
already 2 free, compliant Java compilers.  I think we dropped jikes
from Fedora due to obsolescence.

Tom

Re: What a modern collaboration toolkit looks like

[Richard Stallman]

    None of these features is impossible to implement in Emacs.  In fact
    many could probably be done by reusing Eclipse's Java compiler.

I would be glad to see any and all of these features added to Emacs.
Eclipse is free, so we should be able to use the Eclipse Java
compiler.  However, I would rather do it in ways that work with GCJ
and with other languages too.

Re: What a modern collaboration toolkit looks like

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

> And if you are hinting that using CVS is the reason, then I must say
> that in the 15 years I've been involved in Emacs development (using
> RCS at first, btw), I don't think I've ever heard some potential
> contributor say that she refuses to come on board because of the VCS
> we use.

Speaking as one of the youngsters in the team, I'd say that it matters
quite a bit.  There are a lot of emacs lisp projects where younger devs
are involved (e.g. EMMS), but getting something into emacs is quite
hard.  A distributed VCS would help here definitely.

The current way with posting patches on emacs-devel, getting review,
rewriting the patches, yet more review and eventually being included
(but still with no write access) can make the work much harder.

Of course I do think that the review is very good thing and that giving
write access to a person is a decision that has to be weighted
accurately, but a tool like git would free contributors from needing
that.

I could say, hey, I've developed this new foo-mode, please look at my
git repository at http://www.tsdh.de/repos/git/foo, get the review,
change it till everybody is satisfied and eventually one of the core
devs could pull the changes.

There would be no need to have write access at all.  I can alway commit
to my repository (even when I'm offline, a fact that should be a big
plus for Richard) and synching happens whenever something important has
be done and some core dev reviewed it.

There's a nice video at youtube where Linus Torvalds talks about git
where he discribes the benefits of distributed VCSs (in a very
entertaining way).

> My analysis is different: I think we are limited by a small number of
> core developers, and by the lack of head maintainer(s) who could
> devote much more time than any of us can evidently provide to coding
> and leading the rest of the developers.

IMO this would change with a VCS like git, too.  On problem with the
current situation is that possible contributors might fear that their
changes break something or won't be liked by the core devs.  So they
don't even try it at all.  With a distributed VCS it's like everybody
has his own branch where he can do what he likes, so I expect people to
hack on parts they wouldn't try normally.  And since then there will be
finished patches which actually are easily appliable and testable, the
maintainer's job would be to try the different branches and incorporate
the good stuff into the main line.

So to sum up: There are quite a few young devs that write good elisp
code, but currently they concentrate on extensions, because the core
stuff seems somewhat locked behind bureaucratical walls.  A distributed
version control system would definitely help to break them down.

Bye,
Tassilo

Re: What a modern collaboration toolkit looks like

[Eli Zaretskii]

> From: Tassilo Horn <tassilo@member.fsf.org>
> Date: Tue, 01 Jan 2008 12:28:43 +0100
> 
> The current way with posting patches on emacs-devel, getting review,
> rewriting the patches, yet more review and eventually being included
> (but still with no write access) can make the work much harder.
> [...]
> I could say, hey, I've developed this new foo-mode, please look at my
> git repository at http://www.tsdh.de/repos/git/foo, get the review,
> change it till everybody is satisfied and eventually one of the core
> devs could pull the changes.

Please explain how the former is harder than the latter.  You still
need to wait for review and approval.  OTOH, having a patch pushed
into my INBOX and staring in my face runs better chances that I will
review it than if I need to be on-line and type some commands first
just to see it.

> There's a nice video at youtube where Linus Torvalds talks about git
> where he discribes the benefits of distributed VCSs (in a very
> entertaining way).

Linus and others invented git because Linux kernel development is
radically different from Emacs development.  To start using git, we
need first get to the point the Linux kernel developers are at: lots
of developers independently developing all kinds of extensions.  _And_
we need a head maintainer who works on nothing else but integration of
features she likes into the product that is eventually released.

Please also don't forget that, unlike a Linux kernel, Emacs must have
good user-level documentation.  So decentralized development needs
also solve the problem of producing high quality manuals.

> IMO this would change with a VCS like git, too.  On problem with the
> current situation is that possible contributors might fear that their
> changes break something or won't be liked by the core devs.  So they
> don't even try it at all.

I don't see why.  Someone who wants just to try things can do that in
their sandbox; no one will ever know they did it unless they tell or
post the patches.  How is this different from using git?

> So to sum up: There are quite a few young devs that write good elisp
> code

Do you have numbers? or is "few" == 1 here?

Re: What a modern collaboration toolkit looks like

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
> To start using git, we need first get to the point the Linux kernel
> developers are at: lots of developers independently developing all
> kinds of extensions.  _And_ we need a head maintainer who works on
> nothing else but integration of features she likes into the product
> that is eventually released.

No we don't (how on earth did you reach that conclusion ?!).

Git, like most modern source control systems, is pretty much a
_superset_ of CVS, and can happily be used with a CVS-like "central
server" (where it still handily beats the pants of CVS in almost every
respect).

-Miles

-- 
Is it true that nothing can be known?  If so how do we know this?  -Woody Allen

Re: What a modern collaboration toolkit looks like

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Date: Wed, 02 Jan 2008 09:29:47 +0900
> Cc: Tassilo Horn <tassilo@member.fsf.org>, emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> > To start using git, we need first get to the point the Linux kernel
> > developers are at: lots of developers independently developing all
> > kinds of extensions.  _And_ we need a head maintainer who works on
> > nothing else but integration of features she likes into the product
> > that is eventually released.
> 
> No we don't (how on earth did you reach that conclusion ?!).

AFAIK, this is how Linux kernel development works, and that is the
single most important basis for the git philosophy.

> Git, like most modern source control systems, is pretty much a
> _superset_ of CVS, and can happily be used with a CVS-like "central
> server" (where it still handily beats the pants of CVS in almost every
> respect).

IMO, it hardly makes sense to switch, then, and it's not what Tassilo
had in mind and put in writing, AFAIU.

Re: What a modern collaboration toolkit looks like

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
>> > To start using git, we need first get to the point the Linux kernel
>> > developers are at: lots of developers independently developing all
>> > kinds of extensions.  _And_ we need a head maintainer who works on
>> > nothing else but integration of features she likes into the product
>> > that is eventually released.
>> 
>> No we don't (how on earth did you reach that conclusion ?!).
>
> AFAIK, this is how Linux kernel development works, and that is the
> single most important basis for the git philosophy.

There's a common kernel development style, and git is good at it -- but
git has been influenced by _many_ people, and as a result, supports many
different working styles quite well (and even kernel development is not
so homogeneous -- various sub-projects use a more centralized
development style, and yet can inter-operate seemlessly with the main
kernel).

>> Git, like most modern source control systems, is pretty much a
>> _superset_ of CVS, and can happily be used with a CVS-like "central
>> server" (where it still handily beats the pants of CVS in almost every
>> respect).
>
> IMO, it hardly makes sense to switch, then, and it's not what Tassilo
> had in mind and put in writing, AFAIU.

Again:  it still handily beats the pants of CVS in almost every respect
[when used in "centralized" fashion].

_And_ it gives much more flexibility to developers.  For instance, I may
normally push changes to the central repository many times a day, but if
I go on a vacation, I can bring my laptop and _continue_ commiting
changes "locally", and then push them all to the central repository when
I get back (preserving all commit boundaries of course).

Git allows many development styles to interact seamlessly.  I think
that's a good thing.

-Miles

-- 
o The existentialist, not having a pillow, goes everywhere with the book by
  Sullivan, _I am going to spit on your graves_.

Re: What a modern collaboration toolkit looks like

[Werner LEMBERG]

> For instance, I may normally push changes to the central repository
> many times a day, but if I go on a vacation, I can bring my laptop
> and _continue_ commiting changes "locally", and then push them all
> to the central repository when I get back (preserving all commit
> boundaries of course).

Yeah, this is vital for me since I'm travelling a lot with train.  It
should fit Richard's development style much, much better than CVS!


   Werner

Re: What a modern collaboration toolkit looks like

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> The current way with posting patches on emacs-devel, getting review,
>> rewriting the patches, yet more review and eventually being included
>> (but still with no write access) can make the work much harder.
>> [...]
>> I could say, hey, I've developed this new foo-mode, please look at my
>> git repository at http://www.tsdh.de/repos/git/foo, get the review,
>> change it till everybody is satisfied and eventually one of the core
>> devs could pull the changes.
>
> Please explain how the former is harder than the latter.

At least it's harder for the contributor.  Let's say my new feature is
quite complex and needs some time to get it right.  With CVS I have to
do it in one big step.  Till it's not finished and ready for inclusion I
simply cannot commit.

With git I can commit locally whenever I want.  If I have three
alternative approaches to handle something I can easily create three
local branches and switch between them to test which is better.  And if
I do somthing stupid (which I always do!) I can easily revert to a
previous version.

To do something like local branches with CVS I would need to checkout
the complete repository several times and still I could not commit to
revert after a wrong decision.  So currently I make file backups once in
a while which is really a pain.

> You still need to wait for review and approval.

Sure, but as I said, I consider that a good thing.  And if the reviewers
at the 13th review say that my last changes are completely stupid, I can
easily revert to revision 12 if we'd use git or another distributed VCS.

> OTOH, having a patch pushed into my INBOX and staring in my face runs
> better chances that I will review it than if I need to be on-line and
> type some commands first just to see it.

Ok, so I'd write a mail with my repository location and a `git diff'
output.

>> There's a nice video at youtube where Linus Torvalds talks about git
>> where he discribes the benefits of distributed VCSs (in a very
>> entertaining way).
>
> Linus and others invented git because Linux kernel development is
> radically different from Emacs development.  To start using git, we
> need first get to the point the Linux kernel developers are at: lots
> of developers independently developing all kinds of extensions.

Git (and any other distributed VCS) can be used in a CVS style with one
main repository without loosing any of its benefits.

> _And_ we need a head maintainer who works on nothing else but
> integration of features she likes into the product that is eventually
> released.

I don't see the difference between pulling from somebody (after a
review) and applying the patches attached to a mail.

Of course the core devs would have write access to the main repository,
so all of them could push their own changes into it (plus changes they
reviewed from others).  So any core dev would be a potential integrator.

> Please also don't forget that, unlike a Linux kernel, Emacs must have
> good user-level documentation.  So decentralized development needs
> also solve the problem of producing high quality manuals.

I guess that's part of the review.  "Hey, nice work.  Please come back
when the docs are finished."

>> IMO this would change with a VCS like git, too.  On problem with the
>> current situation is that possible contributors might fear that their
>> changes break something or won't be liked by the core devs.  So they
>> don't even try it at all.
>
> I don't see why.  Someone who wants just to try things can do that in
> their sandbox; no one will ever know they did it unless they tell or
> post the patches.  How is this different from using git?

As I said above: You can develop in little steps and still use all the
benefits a VCS offers (committing, reverting, branching, merging,
tagging).

>> So to sum up: There are quite a few young devs that write good elisp
>> code
>
> Do you have numbers? or is "few" == 1 here?

I know at least two beside me: David O'Toole and Michael Olson.  And at
least the latter uses git for all his projects.  But I'm sure there are
many more.

Bye,
Tassilo

Re: What a modern collaboration toolkit looks like

[Richard Stallman]

    With git I can commit locally whenever I want.  If I have three
    alternative approaches to handle something I can easily create three
    local branches and switch between them to test which is better.  And if
    I do somthing stupid (which I always do!) I can easily revert to a
    previous version.

The feature of local branches does sound useful.

    I don't see the difference between pulling from somebody (after a
    review) and applying the patches attached to a mail.

Is it possible to "pull from somebody" when his machine
is not on line?

Re: What a modern collaboration toolkit looks like

[Ævar Arnfjörð Bjarmason]

Richard Stallman <rms@gnu.org> writes:

> The feature of local branches does sound useful.
>
>     I don't see the difference between pulling from somebody (after a
>     review) and applying the patches attached to a mail.
>
> Is it possible to "pull from somebody" when his machine
> is not on line?

Yes, if that person placed (pushed) his changes somewhere before going
offline. This could have been been done by sending a patchset generated
by git-format-patch to a mailing list, by pushing to a repository that
acts as a mirror (repo.or.cz hosts such a service) to name two
possibilities.

Re: What a modern collaboration toolkit looks like

[Stefan Monnier]

>> The feature of local branches does sound useful.
>> 
>> I don't see the difference between pulling from somebody (after a
>> review) and applying the patches attached to a mail.
>> 
>> Is it possible to "pull from somebody" when his machine
>> is not on line?

> Yes, if that person placed (pushed) his changes somewhere before going
> offline. This could have been been done by sending a patchset generated
> by git-format-patch to a mailing list, by pushing to a repository that
> acts as a mirror (repo.or.cz hosts such a service) to name two
> possibilities.

It is worth noting also that the repository acting as a mirror can just
as well be the main repository: his push just adds a branch and does
not affect the "trunk".


        Stefan

Re: What a modern collaboration toolkit looks like

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Jan 01, 2008 at 10:36:30PM +0200, Eli Zaretskii wrote:
> > From: Tassilo Horn <tassilo@member.fsf.org>

[...]

> > IMO this would change with a VCS like git, too.  On problem with the
> > current situation is that possible contributors might fear that their
> > changes break something or won't be liked by the core devs.  So they
> > don't even try it at all.
> 
> I don't see why.  Someone who wants just to try things can do that in
> their sandbox; no one will ever know they did it unless they tell or
> post the patches.  How is this different from using git?

To paraphrase what Tassilo has written elsewhere in this thread: the
potential contributor will be able to survive the time in which his
potential patches aren't integrated yet -- even pulling in changes made
to the main line. With CVS this is @#&%^H^H^H^Hdaunting.

Two recent examples: multy-tty and unicode. And even there, we are
benefitting from a distributed version control system, Arch, with a
friendly user interface put on top (named Miles :-)

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFHe04nBcgs9XrR2kYRAijpAJ9FcCi2pUF7LT4q2PCrrprawIDQlACcDaNX
oJAv/TTBq/vMkJv0Kv4wTts=
=WJ5S
-----END PGP SIGNATURE-----

Re: What a modern collaboration toolkit looks like

[Richard Stallman]

    There would be no need to have write access at all.  I can alway commit
    to my repository (even when I'm offline, a fact that should be a big
    plus for Richard) and synching happens whenever something important has
    be done and some core dev reviewed it.

I am having trouble understanding what it _means_ to say that you can
do a "commit" into your own repository.  That must be something very
different from a "commit" in CVS terms.  Perhaps it is so different that
the two are not comparable at all.

Re: What a modern collaboration toolkit looks like

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> I am having trouble understanding what it _means_ to say that you can
> do a "commit" into your own repository.  That must be something very
> different from a "commit" in CVS terms.  Perhaps it is so different that
> the two are not comparable at all.

Basically, in git (and many other systems), _every working directory_
contains its own repository, stored in the ".git" subdirectory.  .git
contains the entire history of the project, which is why you can examine
log entries and old versions without being connected; it is highly
compressed so for instance in the case of Emacs, .git takes only a
little more space than the source tree itself.

When you commit using "git commit", you're committing to the .git
subdirectory.  So "git commit" means "WD changes -> .git", a local
operation.

Git then contains commands to merge between repositories (either
"pushing" or "pulling" to/from another repository).  You can push or
pull to remote repositories as well as local ones (a remote repository,
might be like "ssh://git.sv.gnu.org/srv/git/emacs.git", whereas local
repository is simply another git working directory [containing it's own
.git subdir]).

So perhaps you hack all day, periodically making commits (using "git
commit") which store your changes into the .git subdir.  Then when you
later connect to the net, you can merge the new changes in .git into the
remote emacs repository on savannah (using "git push").

-Miles

-- 
Suburbia: where they tear out the trees and then name streets after them.

Re: What a modern collaboration toolkit looks like

[Richard Stallman]

    So perhaps you hack all day, periodically making commits (using "git
    commit") which store your changes into the .git subdir.  Then when you
    later connect to the net, you can merge the new changes in .git into the
    remote emacs repository on savannah (using "git push").

It sounds like "git push" is the real analogue of CVS commit,
and that this is the closest match-up between the concepts of git
and the concepts of CVS:

   	  CVS           GIT
	  save file  =  commit
	  commit     =  pull or push

But I still don't understand what step actually alters the trunk that
users will get by default from the public repository.  Does `push' do
that?  If not `push', then what?

Re: What a modern collaboration toolkit looks like

[Óscar Fuentes]

Richard Stallman <rms@gnu.org> writes:

>     So perhaps you hack all day, periodically making commits (using "git
>     commit") which store your changes into the .git subdir.  Then when you
>     later connect to the net, you can merge the new changes in .git into the
>     remote emacs repository on savannah (using "git push").
>
> It sounds like "git push" is the real analogue of CVS commit,
> and that this is the closest match-up between the concepts of git
> and the concepts of CVS:
>
>    	  CVS           GIT
> 	  save file  =  commit
> 	  commit     =  pull or push
>
> But I still don't understand what step actually alters the trunk that
> users will get by default from the public repository.  Does `push' do
> that?  If not `push', then what?

The basis of DVCSs is that every user has one (or more) personal
repositories. You work on your own for a period of time as if you were
the only one on the project, committing changes to your
repository. Then, you decide to share your changes with the rest of the
world. For this, you "push" the changes to the "golden" central
repository, where other users "pull" them to update their personal
repositories.

It's just a matter of independent repositories that communicates with
each other. "Push" is "send my changes" and "pull" is "get other's
changes".

Using analogies with CVS here is dangerous and only help to obscure what
a DVCS is. As is the case with learning a new programming language, it's
better to forget about specific languages you know and think on terms of
how useful the language is for you. Often you see that the new language
is a big improvement because it solves a problem that you didn't
realized until you see it solved.

A very important feature is that you are not limited to communicate with
the central repository. You can make available your personal repository
to other users and so create groups of developers working together on a
issue. When the work is done, some of you push the final result into the
central repository.

Personal repositories and peer-to-peer sharing opens lots of
possibilities: you can work on a difficult issue using localy the
advantages of having a personal VCS, doing multiple commits as you hack
the problem and, finally, "pushing" to the central repository the clean,
finished work. As mentioned above, you can share your changes with other
people without touching the central repository. You can create as much
personal branches as needed for your personal use, as this is a local
operation. In fact, some DVCS encourage branching even to implement
almost trivial changes, which makes much sense if you ever work on more
than one issue at the same time.

When your repository communicates with other repo, either by getting
(pulling) or by sending (pushing) changesets, a merge is
performed. DVCSs uses sophisticated algorithms for tracking merges and
remembers which changesets are already merged on every repository. It is
possible to get or send a selection of changesets on a consistent way
(this is termed cherry-picking), that is, if you require changeset 100
and it depends on changeset 93, the system knows this and takes the
appropiate action.

-- 
Oscar

Re: What a modern collaboration toolkit looks like

[Eli Zaretskii]

> From: =?iso-8859-1?Q?=D3scar_Fuentes?= <ofv@wanadoo.es>
> Date: Sat, 05 Jan 2008 07:59:07 +0100
> Cc: Richard Stallman <rms@gnu.org>
> 
> Using analogies with CVS here is dangerous and only help to obscure what
> a DVCS is.

This cannot be helped, and resisting this tendency will only obstruct
constructive dialog.  People understand new things by analogies to
something they already know; this is how we synthesize new knowledge
and ideas.

> Personal repositories and peer-to-peer sharing opens lots of
> possibilities: you can work on a difficult issue using localy the
> advantages of having a personal VCS, doing multiple commits as you hack
> the problem and, finally, "pushing" to the central repository the clean,
> finished work. As mentioned above, you can share your changes with other
> people without touching the central repository.

Are there any tools or widely-accepted methods for figuring out what
is the main "theme" of a certain branch of a given personal
repository?  Or does Joe Random Hacker still need to use email to find
out what is available out there?

Re: What a modern collaboration toolkit looks like

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> Are there any tools or widely-accepted methods for figuring out what
> is the main "theme" of a certain branch of a given personal
> repository?  Or does Joe Random Hacker still need to use email to find
> out what is available out there?

A local repository is just a directory somewhere on your filesystem. As
such, it has a name chosen by you. A published repository is an URL that
points to some local repository. Giving meaningful names is up to you.

The users that you allow to access your repositories can remotely
inspect the logs and so gain more info about your hacking.

Usually, you'll say to your intended audience "I'm implementing feature
X and you can follow my work on protocol://my.domain/myrepos/featureX"

-- 
Oscar

Re: What a modern collaboration toolkit looks like

[Richard Stallman]

    Using analogies with CVS here is dangerous and only help to obscure what
    a DVCS is.

You may be right.  My point is that the use of the word "commit" to
describe one DVS operation does itself make an analogy with CVS.  I
found that analogy misleading.

Re: What a modern collaboration toolkit looks like

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     So perhaps you hack all day, periodically making commits (using "git
>     commit") which store your changes into the .git subdir.  Then when you
>     later connect to the net, you can merge the new changes in .git into the
>     remote emacs repository on savannah (using "git push").
>
> It sounds like "git push" is the real analogue of CVS commit,

No.  Pushing works between repositories.  It is the way to propagate
changes to others.

> and that this is the closest match-up between the concepts of git
> and the concepts of CVS:
>
>    	  CVS           GIT
> 	  save file  =  commit

No.  Saving a file will not give you all the version control history and
tools and diffs and branching and other tools that committing does under
git.  You have all that working machinery to your disposal once you have
committed.  Pushing just pushes out your commits (and not just a
snapshot) to the remote repository.  It does not change what you are
working with.  Your own repository and workflow is not affected.  You
never need to push in order to get something into better working order
for yourself.

Note that while you have not pushed out anything, git has a variety of
tools for rewriting and cleaning up your own branches/repository.  In
that manner, a new feature usually arrives in one coherent series of
commits.  Also, if you are developing a new feature, you need not push
it out to the central repository, but can still share the development
with a private set of other people.

> 	  commit     =  pull or push
>
> But I still don't understand what step actually alters the trunk that
> users will get by default from the public repository.  Does `push' do
> that?  If not `push', then what?

Pushing will, yes.  The act of pushing will make the remote trunk assume
the state of the current trunk (without dropping changes only available
in the remote trunk: in that case, git requires you to pull and merge
those first).

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: What a modern collaboration toolkit looks like

[Werner LEMBERG]

> > It sounds like "git push" is the real analogue of CVS commit,
> 
> No.  Pushing works between repositories.  It is the way to propagate
> changes to others.

This fundamental difference between CVS and git was the hardest point
for me in understanding the mechanisms.


    Werner

Re: What a modern collaboration toolkit looks like

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Sat, 05 Jan 2008 09:55:57 +0100
> Cc: tassilo@member.fsf.org, emacs-devel@gnu.org, Miles Bader <miles@gnu.org>
> 
> >    	  CVS           GIT
> > 	  save file  =  commit
> 
> No.  Saving a file will not give you all the version control history and
> tools and diffs and branching and other tools that committing does under
> git.

What tools and diffs are those?  So far, AFAIU, the only difference
between save-file and GIT commit is that with the latter, you can
start a (local) branch.  If there are other reasons for local commits,
what are they?

Re: What a modern collaboration toolkit looks like

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> What tools and diffs are those?  So far, AFAIU, the only difference
> between save-file and GIT commit is that with the latter, you can
> start a (local) branch.  If there are other reasons for local commits,
> what are they?

Well, it's, like, a commit.  :-)

That is, it's a unit of work committed to the repository.  You have a
commit log message, and the unit can either be applied or reverted.

Let's say you're working offline on the file foo.el.  First you fix a
bug dealing with issue A, and you commit that to the repository.  Then
you fix another, totally different bug, dealing with issue B, and you
commit that.

When you come online, you "push" these commits to the central
repository, which will see these two changes as two separate changes,
not just a single change.

If you're not online all the time, having a distributed SCM can be
liberating for your work flow.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: What a modern collaboration toolkit looks like

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Date: Sat, 05 Jan 2008 09:55:57 +0100
>> Cc: tassilo@member.fsf.org, emacs-devel@gnu.org, Miles Bader <miles@gnu.org>
>> 
>> >    	  CVS           GIT
>> > 	  save file  =  commit
>> 
>> No.  Saving a file will not give you all the version control history and
>> tools and diffs and branching and other tools that committing does under
>> git.
>
> What tools and diffs are those?  So far, AFAIU, the only difference
> between save-file and GIT commit is that with the latter, you can
> start a (local) branch.  If there are other reasons for local commits,
> what are they?

Being able to start a local branch at the drop of a hat is actually very
very valuable.  Anyway: You can diff between any committed versions.
You can revert particular commits.  You can checkout any previous
version by date or version.  Branching is actually quite important since
you can work on several unfinished projects at once, deciding for
yourself when and how you merge in upstream changes to keep your branch
abreast.  You can make a bloody mess of your repository and back out
again (it is actually rather hard to really lose any history with git)
without anybody else noticing.  You can merge in a particular patch set
from somebody else.

If you notice a regression, you can create a test case for it and let
git automatically biject from your local branch history until it
pinpoints what commit has been responsible for the regression.

Once you think you have reached a good state of your local branch, you
can clean up and merge and reorder the commits into sensible order, and
then push or offer them as a coherent, well-organized set of commits (so
there is no need for something like a ChangeLog cleanup) on top of some
externally available branch.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: What a modern collaboration toolkit looks like

[Richard Stallman]

    > It sounds like "git push" is the real analogue of CVS commit,

    No.  Pushing works between repositories.  It is the way to propagate
    changes to others.

At this level, that's just a detail.  The must important thing about
CVS commit is that it alters what other people will get if they ask to
get the current version from the repository.  With git, the operation
which does that is `push'.

    >    	  CVS           GIT
    > 	  save file  =  commit

    No.  Saving a file will not give you all the version control history and
    tools and diffs and branching and other tools that committing does under
    git.

Ok, but those are details.  The crucial point is that saving a file,
or git commit, alters your own data only; it does not affect what
other users will get from the published repository.

Re: What a modern collaboration toolkit looks like

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, Jan 06, 2008 at 03:09:19AM -0500, Richard Stallman wrote:

[...]

> Ok, but those are details.  The crucial point is that saving a file,
> or git commit, alters your own data only; it does not affect what
> other users will get from the published repository.

Yes and no. That depends on wether "your" repository is the one other
users refer to (a perfectly valid setup under Arch and git -- and I
guess under other distributed VCSes as well). Not that this would be a
good idea for a "big" and "loosely-knit" project, though.

So it's rather that the "commit" of central VCSese is split up into two
operations (commit: working dir --> repo; push: repo --> repo) in
distributed VCSes. On a central VCS, with just one repo, this
differentiation doesn't make kuch sense.

The analogy suggested by re-using commit is quite valid, and afaik all
distributed VCSes went this path (so it seems to be rather compelling).

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFHgKSGBcgs9XrR2kYRAj69AJ47F1Dlg0BxgKL0o5QC7Nf1LAu+qgCeI6gA
z2L3J0oMelDI70EyqYnddXU=
=niBM
-----END PGP SIGNATURE-----

Re: What a modern collaboration toolkit looks like

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     > It sounds like "git push" is the real analogue of CVS commit,
>
>     No.  Pushing works between repositories.  It is the way to propagate
>     changes to others.
>
> At this level, that's just a detail.  The must important thing about
> CVS commit is that it alters what other people will get if they ask to
> get the current version from the repository.  With git, the operation
> which does that is `push'.

Not really.  The atomic operation changing a repository is a commit
which is a commented and registered snapshot of a complete work tree
with a pointer to its parent commit (or in the case of a merge, all of
its parents).  And a commit may make it into a repository rather
equivalently by doing a commit from a work directory, by applying a
patch or patch series, or by pushing/pulling between repositories.

>     >    	  CVS           GIT
>     > 	  save file  =  commit
>
>     No.  Saving a file will not give you all the version control history and
>     tools and diffs and branching and other tools that committing does under
>     git.
>
> Ok, but those are details.  The crucial point is that saving a file,
> or git commit, alters your own data only; it does not affect what
> other users will get from the published repository.

Unless your "own data" _is_ the published repository.  Which is pretty
common the case for projects with an official repository controlled by
one or few persons, like the Linux kernel.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: What a modern collaboration toolkit looks like

[Robert J. Chassell]

    Unless your "own data" _is_ the published repository.

But in Emacs development, it is not.

As an example, consider a Medieval European merchant: he thought of a
trading voyage to Constantinople as `his'.

Several centuries later, a merchant thought of a trading voyage as
`not his' even if he owned the ship 100%, did not purchase insurance,
etc.

That is because of a change in book keeping in which a distinction was
made between those who controlled money and their nephews and cousins
who went on the voyage.  (I think the then new book keeping was
intended to make it harder for the nephews and cousins to steal
excessively; but that is neither here nor there.)

I, for one, do not want to use RMS's repository.  For one, he is often
off-line.  I prefer a site that is supposed to be on-line when I try
to connect.

No one is defending CVS; but several want to understand how to be the
equivalent of what they are already, a 16th century merchant, rather
than a 12th century merchant.  That is what this whole `commit',
`push' discussion is about.

Since some developers have work and sleep patterns that are 12 hours
different from yours, and they do not want you to change to confirm to
them, they do not want anything that is immediate.

And some are not connected and some do not want interruptions.

IRC is big fear, since it means that some people will not develop and
there are few as it is.

That means email makes sense.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: What a modern collaboration toolkit looks like

[David Kastrup]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

>     Unless your "own data" _is_ the published repository.
>
> But in Emacs development, it is not.

Emacs is not maintained with git (well, git being decentral, everybody
is free to work with it regardless).

> No one is defending CVS; but several want to understand how to be the
> equivalent of what they are already, a 16th century merchant, rather
> than a 12th century merchant.  That is what this whole `commit',
> `push' discussion is about.
>
> Since some developers have work and sleep patterns that are 12 hours
> different from yours, and they do not want you to change to confirm to
> them, they do not want anything that is immediate.
>
> And some are not connected and some do not want interruptions.
>
> IRC is big fear, since it means that some people will not develop and
> there are few as it is.
>
> That means email makes sense.

Well, your above Email doesn't.  CVS does not work by Email, git does
not work by IRC, and neither are in any manner even remotely related
with medieval merchants.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: What a modern collaboration toolkit looks like

[Robert J. Chassell]

David Kastrup <dak@gnu.org> said

    Emacs is not maintained with git ...

No, it is not.  RMS and many others obtain Emacs via CVS, but they or
he want to understand a newer version control system.

My Medieval merchants example was about understanding CVS and newer
version control systems.  And, as I said, people want `to be the
equivalent of what they are already' which in one case is to be in the
16th century and in the other is to be in the present.

    CVS does not work by Email ...

Right, it does not.  In other paragraphs, I talked about email.
Comments, like yours, come via email.

In those paragraphs, I talked about the fear that some would be
excluded because at times they are disconnected from the net, don't
want interruptions, or don't want you to adapt your work and sleep
pattern to them.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: What a modern collaboration toolkit looks like

[David Kastrup]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

> David Kastrup <dak@gnu.org> said
>
>     CVS does not work by Email ...
>
> Right, it does not.  In other paragraphs, I talked about email.
> Comments, like yours, come via email.
>
> In those paragraphs, I talked about the fear that some would be
> excluded because at times they are disconnected from the net, don't
> want interruptions, or don't want you to adapt your work and sleep
> pattern to them.

And CVS, which requires a constant net connection for working or
comparing with anything but the currently checked-out work copy, is
supposed to be less worrisome than a system where you can work with your
own private repository off-line, including all the diff and branching
machinery?

You are flaunting a fundamental weakness of CVS (and other centralized
SCMs) in _support_ of it?

I am afraid that I still can't read any sense into your argument.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: What a modern collaboration toolkit looks like

[Richard Stallman]

    Well, your above Email doesn't.  CVS does not work by Email, git does
    not work by IRC, and neither are in any manner even remotely related
    with medieval merchants.

Using IRC to communicate was part of method that ESR wanted us to
adopt.  I agree we can separate that issue from use of a DVCS.

The medieval merchants are an analogy; if you take it literally
then you don't get the point.

Re: What a modern collaboration toolkit looks like

[Stefan Monnier]

>     So perhaps you hack all day, periodically making commits (using "git
>     commit") which store your changes into the .git subdir.  Then when you
>     later connect to the net, you can merge the new changes in .git into the
>     remote emacs repository on savannah (using "git push").

> It sounds like "git push" is the real analogue of CVS commit,
> and that this is the closest match-up between the concepts of git
> and the concepts of CVS:

>    	  CVS           GIT
> 	  save file  =  commit
> 	  commit     =  pull or push

Kind of, yes, except that the "git commit" really does a "local commit"
to a local branch.  In VC we implemented a poor-man replacement by
allowing mixing various backends, where the expected use was as follows:

  Let's say you have a file under CVS which you want to modify.
  The modifications are fairly long running and you feel like you'd want
  to be able to commit every once in a while so you can go back or so you
  can diff between various intermediate stages of your work.
  
  But as it turns out you don't actually want to commit to the CVS
  either because the CVS repository is unavailable (offline, or
  read-only), or because you're not sure you'll want to install the
  change in the end, or ...

  So you register your file under RCS: the file is now both under CVS
  and under RCS at the same time.  C-x v b allows you to switch VC's
  view between the two backends.  So now you can do all your local
  commits to RCS, with ability to do diffs/revert/... without needing to
  contact the CVS repository.

  After a while, your hacking may result in something you decide
  deserves to make it into the CVS, so you go ahead and commit the new
  file to CVS.  VC actually provides you with a command that makes up
  the changelog for this commit by extracting it from the RCS file, thus
  basically transfering the local RCS branch to the CVS repository (as
  a single change rather than a bunch of little changes).

In the above context, the equivalence would be:

           CVS&RCS            Git
           save file          save file
           commit to RCS      commit
           commit to CVS      push

> But I still don't understand what step actually alters the trunk that
> users will get by default from the public repository.  Does `push' do
> that?

Yes, presuming that by "push" you mean "push to the default public
repository".


        Stefan

Re: What a modern collaboration toolkit looks like

[Richard Stallman]

    > But I still don't understand what step actually alters the trunk that
    > users will get by default from the public repository.  Does `push' do
    > that?

    Yes, presuming that by "push" you mean "push to the default public
    repository".

In CVS terms, that's commit.  To make a useful comparison between
CVS and git, we should think of this as "conceptual commit",
even though it is not called "commit" in git terminology.

Thus, I think that the relationship between merging and conceptual
commit is the same in git as it is in CVS.  In both cases you have to
merge first before you do the conceptual commit.

    In the above context, the equivalence would be:

	       CVS&RCS            Git
	       save file          save file
	       commit to RCS      commit
	       commit to CVS      push

That seems like a good explanation too.

Re: What a modern collaboration toolkit looks like

[Gregory Collins]

Richard Stallman <rms@gnu.org> writes:

> It sounds like "git push" is the real analogue of CVS commit, and that
> this is the closest match-up between the concepts of git and the
> concepts of CVS:
>
>    	  CVS           GIT
> 	  save file  =  commit
> 	  commit     =  pull or push
>
> But I still don't understand what step actually alters the trunk that
> users will get by default from the public repository.  Does `push' do
> that?  If not `push', then what?

The discussion thusfar has been centred on the nuts and bolts of
distributed version control, and I think the point that's getting
overlooked is that decentralization allows you to arbitrarily redefine
the topology of how change flows through a project.

To make this more concrete, here are some commonly-used workflow models:

1. CVS-style / star topology
----------------------------
There is a centralized "one true repository" at a known location
(e.g. http://savannah.gnu.org/.../hg/emacs-trunk). A medium-sized group
of hackers have "push" rights there. (It's the "push" that alters the
trunk here.)

This approach doesn't scale well, although for emacs the commit rate is
probably low enough that this topology is manageable. (That said, how
many times have you asked "who committed this wonky change that broke
X?" this year?)


2. "Lieutenant" / "subsystem percolation"
------------------------------------------
There is a "canonical" version of emacs that lives on savannah. (This is
always true so I'll stop mentioning it.)  The project is split by
subsystem (and possibly is split further, resulting in a tree
structure), and for each a maintainer keeps a source tree with changes
to that given subsystem. When two subsystems need to be updated
simultaneously due to an interface change, the lieutenants coordinate
amongst themselves, pulling changes between each other.

When a change is deemed ready to go to trunk (or to a parent node in the
tree), the upstream maintainer pulls these changes into her tree. Note
here that changes are only pulled, never pushed.

Very often, subsystem maintainers "merge down" changes from trunk, so
that bugfixes/stable new features from other branches are continually
integrated. Everyone works hard to ensure that changes don't break
anything upstream. (cf. the ongoing VC-mode restructuring; under this
scheme those changes would not have been pushed to trunk until they were
complete and tested.)

This approach scales VERY well (it's what linux-kernel uses, and their
code churn rate is *incredible*) but is probably wrong for emacs.


3. Mailing list w/ gatekeeper(s)
---------------------------------
This is how mercurial manages its own development. Proposed changes are
sent in patch form to a mailing list, which is dedicated to the
discussion and review of such patches. The central repository is
read-only except for a small set of integrators. When a change has been
reviewed + tested, an integration crew member pulls the patch from email
into the central tree.

This is the approach I'd suggest for emacs (and it's the one we
instituted for the project I maintain at my workplace). The main
advantages:

 - code gets reviewed by more eyes. Cf. the emacs-devel+emacs-commit
   lists; it's my observation that bad changes are often discussed +
   reviewed AFTER they've been committed to the trunk. How many
   questionable or marginal changes are slipping by, do you think?

 - VC tools streamline the process of sending + reviewing changes. I can
   type "hg email tip" from my working branch to send my last changeset
   to the list for discussion.

On the negative side, this approach becomes asymptotically less
efficient as the number of patches per day increases. However: the
beauty of distributed version control is that you can rework your
topology at will.

To get a flavour for how this process works from a cultural standpoint,
you can read the mercurial-devel mailing list archive at:

    http://selenic.com/pipermail/mercurial-devel/

Thanks,

Gregory Collins <greg@maptuit.com>

Re: What a modern collaboration toolkit looks like

[Stephen J. Turnbull]

Gregory Collins writes:

 > To make this more concrete, here are some commonly-used workflow models:

I think this discussion is premature.  Richard has indicated that he
is satisfied that the Hippocratic Principle ("First, do no harm")
*can* be satisfied by both a bug tracker and a dVCS.  Further, he
acknowledges that their potential benefits are significant *in the
current workflow*.  However, he expresses reservations that particular
tools may still be detrimental to the Emacs project's productivity, if
badly implemented.  He's absolutely right.

Thus I suggest that the project workflow discussion be postponed until
the core stakeholders are satisfied that the new tools are functioning
stably in the current workflow.  This will take only a month, at most
two, once the tools are chosen.  As you point out, a big advantage of
a dVCS is the flexibility of the workflow even after it is installed.
There is no big loss to waiting a bit, and a potential large gain: the
improved understanding of the tools that the core stakeholders will
have.

This doesn't mean that those who want to implement other workflows
have to wait, with nothing to do.  Find other developers of like mind
and start experimenting "off the main workflow".  Cf. Miles's Arch
repo, which is already providing substantial efficiencies in branch
synchronization.  I'm sure David Kastrup, for another, will be able to
use a dVCS to good effect in supporting AUCTeX (which AIUI cannot yet
be merged into Emacs because of legal considerations).

Regarding the example workflows:

 > 1. CVS-style / star topology
 > ----------------------------
 > There is a centralized "one true repository" at a known location
 > (e.g. http://savannah.gnu.org/.../hg/emacs-trunk). A medium-sized group
 > of hackers have "push" rights there. (It's the "push" that alters the
 > trunk here.)
 > 
 > This approach doesn't scale well, although for emacs the commit rate is
 > probably low enough that this topology is manageable. (That said, how
 > many times have you asked "who committed this wonky change that broke
 > X?" this year?)

At Emacs scale, the scaling problem here is the combination of lack of
a testing framework and the star topology, not just the star topology.
Python does fine with a star topology at a similar scale to Emacs, I
would say.

Since this *is* the current workflow, and changing to a dVCS (by
itself) will not immediately increase the patch flow by anything like
an order of magnitude, things will not get worse if this workflow is
continued across the change in tools.

 > 2. "Lieutenant" / "subsystem percolation"
 > ------------------------------------------
 > There is a "canonical" version of emacs that lives on savannah. (This is
 > always true so I'll stop mentioning it.)  The project is split by
 > subsystem (and possibly is split further, resulting in a tree
 > structure), and for each a maintainer keeps a source tree with changes
 > to that given subsystem. When two subsystems need to be updated
 > simultaneously due to an interface change, the lieutenants coordinate
 > amongst themselves, pulling changes between each other.
 > 
 > When a change is deemed ready to go to trunk (or to a parent node in the
 > tree), the upstream maintainer pulls these changes into her tree. Note
 > here that changes are only pulled, never pushed.
 > 
 > Very often, subsystem maintainers "merge down" changes from trunk, so
 > that bugfixes/stable new features from other branches are continually
 > integrated. Everyone works hard to ensure that changes don't break
 > anything upstream. (cf. the ongoing VC-mode restructuring; under this
 > scheme those changes would not have been pushed to trunk until they were
 > complete and tested.)
 > 
 > This approach scales VERY well (it's what linux-kernel uses, and their
 > code churn rate is *incredible*) but is probably wrong for emacs.

This is the only workflow that can scale with a lack of a formal testing
framework, but then it doesn't scale for the *people*.  It is incredibly
hard on the maintainers, and is only really justified where automated
testing is hard to do.

For Emacs in particular, at least two of the central maintainers
(Richard for all of Emacs and Alan MacKenzie for CC Mode) would be
potential bottlenecks because of their personal workflows.  Also,
several others of the plausible subsystem maintainers have expressed
misgivings which might imply that they are not interested in
functioning as pull-style gatekeepers.

Another problem is that all core Emacs developers have areas of
interest, but if a prerequisite subsystem for "their" area has a
problem, they are used to going in and fixing it unilaterally.  This
will clash with the "turf rights" that the subsystem maintainers have.
Sure, turf rights have been worked out in many cases, such as Gnus and
CC Mode, and when conflicts occur, they work out amicably (I'm
thinking of recent discussions about refactoring various libraries
maintained by the Gnus project into other parts of Emacs when
integrated into Emacs).  But AIUI in the Linux kernel workflow, the
subsystem maintainers have nearly complete hierarchical power over
access to parent systems.  It *could* work in Emacs, but it will be a
change, and I predict it would be a wrenching one.

This workflow should therefore be approached with extreme caution by
the Emacs developers.

 > 3. Mailing list w/ gatekeeper(s)
 > ---------------------------------
 > This is how mercurial manages its own development. Proposed changes are
 > sent in patch form to a mailing list, which is dedicated to the
 > discussion and review of such patches. The central repository is
 > read-only except for a small set of integrators. When a change has been
 > reviewed + tested, an integration crew member pulls the patch from email
 > into the central tree.
 > 
 > This is the approach I'd suggest for emacs (and it's the one we
 > instituted for the project I maintain at my workplace). The main
 > advantages:

You're missing an important point: the sheer size and complexity of
the Emacs codebase.  This requires more *formal* attention to testing
than Emacs has historically given it.  The problem is that in the
Emacs context, a *good* review by the gatekeeper requires a huge stock
of knowledge of the codebase plus great expense on *each* patch.
Guido van Rossum estimates that a "perfect patch" nonetheless costs
him 30-60 minutes, but this is in a context of test-driven
development.  In Emacs as it stands it will be much greater per patch.

If only a small number of gatekeepers have push access to the public
repo, it is also a major change in personal workflow for them.
Possibly excepting Richard, who IIUC already functions as a sort of
Workflow 2 gatekeeper -- except that he doesn't come close to trying
to review all patches, even though he is the final authority.

This workflow also *should* be viewed with extreme caution by the core
developers.

Re: What a modern collaboration toolkit looks like

[Gregory Collins]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Thus I suggest that the project workflow discussion be postponed until
> the core stakeholders are satisfied that the new tools are functioning
> stably in the current workflow.  This will take only a month, at most
> two, once the tools are chosen.  As you point out, a big advantage of
> a dVCS is the flexibility of the workflow even after it is installed.
> There is no big loss to waiting a bit, and a potential large gain: the
> improved understanding of the tools that the core stakeholders will
> have.

Hi Stephen,

My remarks weren't meant to urge any immediate course of action, but
rather to attempt to broaden the discussion to include possible answers
to the question "why would you bother switching?" A discussion that
centres on "how do these CVS concepts map to a distributed context?"
will tend to obscure the most compelling arguments in favour.

Clearly nothing is going to happen in a rush here (nor should it),
because even if it's decided that the horse needs a cart, it's going to
take months to decide

  a) what kind of cart
  b) two wheels or four?
  c) metal, wood, or composite?
  d) "what's wrong with saddlebags, anyways?"
  e) "You guys are soft, I walk everywhere, barefoot"
  f) "I live in Nunavut, so it's VERY IMPORTANT that the cart have
     optional skis"

  ... ad infinitum ...


>  > 2. "Lieutenant" / "subsystem percolation"
>  > ------------------------------------------
>  > ...
>
> This is the only workflow that can scale with a lack of a formal
> testing framework, but then it doesn't scale for the *people*.  It is
> incredibly hard on the maintainers, and is only really justified where
> automated testing is hard to do.

Agreed.

>  > 3. Mailing list w/ gatekeeper(s)
>  > ---------------------------------
>  > ...
>
> You're missing an important point: the sheer size and complexity of
> the Emacs codebase.  This requires more *formal* attention to testing
> than Emacs has historically given it.  The problem is that in the
> Emacs context, a *good* review by the gatekeeper requires a huge stock
> of knowledge of the codebase plus great expense on *each* patch.
> Guido van Rossum estimates that a "perfect patch" nonetheless costs
> him 30-60 minutes, but this is in a context of test-driven
> development.  In Emacs as it stands it will be much greater per patch.

If it's a choice between "60 minutes per patch" and "little or no code
review at all", I think everyone will agree that the review wouldn't
happen. "Formality of code review" is a continuum, however, and it's my
experience that you can stop a lot of bugs without pulling out the
magnifying glass and tweezers.

You may be right that the extreme hairiness of emacs code may invalidate
that assumption. I'd argue regardless that the more eyeballs you can get
on incoming patches, the better.

I'd also argue that despite some impetuous claims to the contrary, the
reports of emacs' imminent demise are greatly exaggerated.

G.

Re: What a modern collaboration toolkit looks like

[David Kastrup]

Gregory Collins <greg@maptuit.com> writes:

> I'd also argue that despite some impetuous claims to the contrary, the
> reports of emacs' imminent demise are greatly exaggerated.

Well, a distributed approach to living would be having a number of bugs
crawling about one's corpse.

Emacs certainly has no shortage of bugs.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: What a modern collaboration toolkit looks like

[Mike Mattie]

[-- Attachment #1.1: Type: text/plain, Size: 1014 bytes --]

On Tue, 08 Jan 2008 01:51:23 +0100
David Kastrup <dak@gnu.org> wrote:

> Gregory Collins <greg@maptuit.com> writes:
> 
> > I'd also argue that despite some impetuous claims to the contrary,
> > the reports of emacs' imminent demise are greatly exaggerated.
> 
> Well, a distributed approach to living would be having a number of
> bugs crawling about one's corpse.

can't help it, think cells :) you are distributed.

Emacs development already uses a distributed version control system.

1. GNU Emacs @ savannah.gnu.org

Which is equivalent to the git repository linus-2.6.

2. Emacs.app @ sourceforge.net

3. Carbon Emacs http://homepage.mac.com/zenitani/emacs-e.html

4. Aqua Emacs http://aquamacs.org/

... others ...

Which are equivalent socially to the lieutenant repositories.

If you consider each of the CVS branches to be a DVCS repo, there are more as well.
Using a tool like git would simply make all of them compatible.

> Emacs certainly has no shortage of bugs.
> 

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: What a modern collaboration toolkit looks like

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 7 Jan 2008 18:43:52 -0800, Mike Mattie <codermattie@gmail.com> said:

> 3. Carbon Emacs http://homepage.mac.com/zenitani/emacs-e.html

What's distributed at the above URL is `Carbon Emacs Package', which
is based on Carbon Emacs of course, but not Carbon Emacs itself.

> 4. Aqua Emacs http://aquamacs.org/

It is `Aquamacs Emacs', also based on Carbon Emacs.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: What a modern collaboration toolkit looks like

[Mike Mattie]

[-- Attachment #1.1: Type: text/plain, Size: 1371 bytes --]

On Tue, 08 Jan 2008 12:03:19 +0900
YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> wrote:

> >>>>> On Mon, 7 Jan 2008 18:43:52 -0800, Mike Mattie
> >>>>> <codermattie@gmail.com> said:
> 
> > 3. Carbon Emacs http://homepage.mac.com/zenitani/emacs-e.html
> 
> What's distributed at the above URL is `Carbon Emacs Package', which
> is based on Carbon Emacs of course, but not Carbon Emacs itself.
> 
> > 4. Aqua Emacs http://aquamacs.org/
> 
> It is `Aquamacs Emacs', also based on Carbon Emacs.

you are indeed correct. Those are the pages that I found with
google, simply from memory of various Emacs ports I tried for
OS X.

As far as tools go what about something like emacs.gnu.org ala
gcc.gnu.org ? A home for all the various Emacsen trees, plus
various elisp efforts not yet merged ?

It would certainly facilitate distro packaging to back the
projects with GNU quality infrastructure. Considering how
special Emacs is within the GNU project I have wondered for
a while why the hard work of Emacs developers is currently
scattered across such a wide range of sites. EmacsWiki
is a godsend but doesn't cut it as a distribution point
that distributions like Gentoo can use.

Aside from any of the other tools a emacs.gnu.org site would 
make 2008 a year to toast.

>				     YAMAMOTO Mitsuharu
> 				mituharu@math.s.chiba-u.ac.jp

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: What a modern collaboration toolkit looks like

[Richard Stallman]

    3. Mailing list w/ gatekeeper(s)
    ---------------------------------
    This is how mercurial manages its own development. Proposed changes are
    sent in patch form to a mailing list, which is dedicated to the
    discussion and review of such patches. The central repository is
    read-only except for a small set of integrators. When a change has been
    reviewed + tested, an integration crew member pulls the patch from email
    into the central tree.

    This is the approach I'd suggest for emacs (and it's the one we
    instituted for the project I maintain at my workplace). The main
    advantages:

I would be willing to try it, or a compromise between this and #1,
which would mean a larger number of people who can commit directly
to the main repository.

Re: What a modern collaboration toolkit looks like

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     There would be no need to have write access at all.  I can alway commit
>     to my repository (even when I'm offline, a fact that should be a big
>     plus for Richard) and synching happens whenever something important has
>     be done and some core dev reviewed it.
>
> I am having trouble understanding what it _means_ to say that you can
> do a "commit" into your own repository.  That must be something very
> different from a "commit" in CVS terms.  Perhaps it is so different that
> the two are not comparable at all.

No, they are pretty similar, except that everybody has his own private
repository.  The repositories get synchronized not by commit and
checkout (those happen only locally), but by pushing and pulling.  These
operations are very much optimized to deal with merge conflicts and to
figure out what changes were already committed remotely.

Apart from "remote tracking branches" which you can set up (but don't
need to), the histories of various repositories tend to be different.
Before pushing something out (or sending around patches), you will
likely "rebase" on the repository your patch is referring to.  Rebasing
means rewinding the history to a common ancestor, applying all the
patches from the remote repository, then reapplying all local patches
that are not in the remote repository.  Merge conflicts may need to get
resolved then.  Afterwards, your branch history reads like just your
local changes on top of the branch/repo/state you rebased on.

One tends to rebase local branches from time to time.  For branches
which are distributed to others, it is nicer to just merge with other
repositories/branches since that saves the others from having to do any
rewinds leading to possibly repeated merge resolutions.  While you can
tell git to keep records of past merge resolutions (so that it will
resolve the identical problem automatically the next time), it is nicer
not to force this.

So basically, commit and checkout (and merges, though with an external
source) happen locally.  Synchronization with others happens directly
between repositories by pushing and pulling, and patch distribution.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: What a modern collaboration toolkit looks like

[Alan Mackenzie]

Hi, Eric!

On Mon, Dec 31, 2007 at 08:07:12AM -0500, Eric S. Raymond wrote:
> Eli Zaretskii <eliz@gnu.org>:

> The old-timers on this list should be asking themselves why, when Emacs
> is so undeniably important, it can't attract as many developers as a
> mere fantasy game.

A few suggestions:
o - Emacs is implemented in a wierd special purpose language.

o - Emacs is already so good that it's difficult to see room for new
  features.  

o - Much core Emacs code has, despite RMS's good sense and emphasis on
  simplicity, become tortuous and difficult to get into.

o - Emacs is a victim of its own success - as its new features make it
  steadily easier to use, it becomes steadily more intricate and thus
  harder to learn.  A non-user of Emacs cannot become an Emacs hacker.

[ .... ]

> The Emacs project, though, is still operating at a scale and tempo I
> think of as being typical of the late 1980s and early 1990s.  I think
> we are limited by poor tools, and by habits of thought derived from
> those poor tools.

Hmmm.  There's something ironic about an Emacs developer blaming poor
tools.  ;-)

I'd think it's worth emphasising that CVS is _NOT_ a poor tool; it's an
exceptionally flexible, solid and reliable one, free from feature bloat,
and I'm grateful indeed to the hackers who've maintained it over the
decades.

What you mean, Eric, is that CVS is a hammer, and we could now work
better by using screws rather than nails.  What's the best screwdriver?

I've never been able to get excited by VCSs; apart from CVS, I've only
had experience with proprietary VCSs, and they have, with one exception,
been ghastly.

> I'd like to help that change.

I'm enthusiastic about this.  Go for it, Eric!  But I suggest the
following two constraints for the new tools, which might not apply to
Battle for Wesnoth:

o - They must support "batch mode" working, for RMS and others who
  concentrate fiercely on a single activity at a time.

o - They must, like Emacs, be fully usable on a text console without a
  mouse as well as in X.  There are at least 3 hackers here who prefer
  such a setup.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: What a modern collaboration toolkit looks like

[Werner LEMBERG]

> [...] I suggest the following two constraints for the new tools,
> which might not apply to Battle for Wesnoth:
> 
> o - They must support "batch mode" working, for RMS and others who
>   concentrate fiercely on a single activity at a time.

git has such a batch mode, while CVS has none.  So for Richard, git
would be a much better choice than CVS since he could commit very
small units while being off-line.


    Werner

Re: What a modern collaboration toolkit looks like

[Alan Mackenzie]

Glückwünsch zum Neuen, Werner!

On Tue, Jan 01, 2008 at 07:05:35PM +0100, Werner LEMBERG wrote:

> > [...] I suggest the following two constraints for the new tools,
> > which might not apply to Battle for Wesnoth:

> > o - They must support "batch mode" working, for RMS and others who
> >   concentrate fiercely on a single activity at a time.

> git has such a batch mode, while CVS has none.  So for Richard, git
> would be a much better choice than CVS since he could commit very
> small units while being off-line.

I don't understand what you mean, here, probably because I don't know
git.  cvs can work on arbitrary sets of files, e.g. with "cvs update".
What do you mean?

I was thinking more about the IIRC thingies:  If RMS were to take part
in online chats, he'd be slowed down to the speed of ordinary hackers, a
disastrous loss of productivity for him.  (I, of course, would be barely
able to keep up.  ;-)  So, whatever way of discussion we settle on, it
must allow people to participate in "batch mode", at their own speed.

>     Werner

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: What a modern collaboration toolkit looks like

[Werner LEMBERG]

> I don't understand what you mean, here, probably because I don't
> know git.  cvs can work on arbitrary sets of files, e.g. with "cvs
> update".  What do you mean?

You can commit a change offline (git commit).  Later on, when you are
online, you say `git pull' to get the current state of the repository,
and automatical merging happens (and the usual warnings if there are
conflicts).  Finally, you say `git push' to synchronize your git
repository with the global one.  What I like most is that a
checked-out git repository is the whole project: You have access to
all previous changes ever done -- something CVS doesn't offer.


    Werner

Re: What a modern collaboration toolkit looks like

[Richard Stallman]

    You can commit a change offline (git commit).  Later on, when you are
    online, you say `git pull' to get the current state of the repository,
    and automatical merging happens (and the usual warnings if there are
    conflicts).  Finally, you say `git push' to synchronize your git
    repository with the global one.

Is this substantially different from CVS, or is it just relabeling?
It sounds like `git push' is basically equivalent to CVS commit.

With CVS, until you commit your changes, new changes can be installed
in the repository, and when you DO get around to committing your
changes, you will have to merge them with whatever others have
installed.  Once you commit, others trying to commit will have the
burden of merging their changes with your already-committed changes.

With git, I would guess that the same situation obtains
until you do `git push' with your changes.  Thus, I think that
`git push' is the true analogue to CVS commit.

This is based on surmise rather than knowledge.  If it is wrong,
where is the mistake?

Re: What a modern collaboration toolkit looks like

[Werner LEMBERG]

[-- Attachment #1: Type: Text/Plain, Size: 1488 bytes --]

>     You can commit a change offline (git commit).  Later on, when
>     you are online, you say `git pull' to get the current state of
>     the repository, and automatical merging happens (and the usual
>     warnings if there are conflicts).  Finally, you say `git push'
>     to synchronize your git repository with the global one.
> 
> Is this substantially different from CVS, or is it just relabeling?
> It sounds like `git push' is basically equivalent to CVS commit.

Correct.

> With CVS, until you commit your changes, new changes can be installed
> in the repository, and when you DO get around to committing your
> changes, you will have to merge them with whatever others have
> installed.  Once you commit, others trying to commit will have the
> burden of merging their changes with your already-committed changes.

This is absolutely the same as with CVS, of course, but: your changes
done offline, and which git can add with trivial merging, stay as
atomic units.  Unfortunately, ChangeLog file are likely to need manual
merging each time.  Many software projects which use git no longer
maintain such a ChangeLog file manually but create it afterwards
mechanically.

There's a wonderful tool called gitk which enables you to display git
changes in a very cleverly manner.  However, this is not a TTY
application but needs GTK.  I don't know whether there exists a gitk
equivalent which runs in a terminal.

Attached is an image which shows gitk in action.


   Werner

[-- Attachment #2: gitk.png --]
[-- Type: Image/Png, Size: 46135 bytes --]

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: What a modern collaboration toolkit looks like

[Eric S. Raymond]

Werner LEMBERG <wl@gnu.org>:
> Attached is an image which shows gitk in action.

Other 3G systems have similar tools.  I believe there is at least one
repo browser that makes a point of supporting three or four of them,
which is possible because they're all using the same model of a 
revision DAG with nodes identified by hashes.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: What a modern collaboration toolkit looks like

[Richard Stallman]

    Attached is an image which shows gitk in action.

I looked at it, but I don't understand what i see.
I would need someone to show it to me and explain,
or perhaps I could figure it out by experimentation
on a project whose contents I know.

Re: What a modern collaboration toolkit looks like

[Thien-Thi Nguyen]

() Richard Stallman <rms@gnu.org>
() Wed, 02 Jan 2008 04:53:40 -0500

   This is based on surmise rather than knowledge.
   If it is wrong, where is the mistake?

here is my understanding of the difference(s):

cvs commit
 ~/src/emacs --[net]-> REPO

git commit
 ~/src/emacs --[filesystem]-> ~/src/emacs/.git/REPO

git push
 ~/src/emacs/.git/REPOSITORY --[net]-> REPO

thus, to achieve a state where changes are publically
accessible, cvs requires one operation, while git two.

(i trust the docs others have sent will explain things
further, but couldn't resist a little ASCII art... ;--).

thi

Re: What a modern collaboration toolkit looks like

[Eric S. Raymond]

Richard Stallman <rms@gnu.org>:
> Is this substantially different from CVS, or is it just relabeling?
> It sounds like `git push' is basically equivalent to CVS commit.

I have not yet studied git specifically (that's coming after I finish
the evaluations on Arch and monotone), but I believe all the modern
DVCSes handle this the same way.  In my survey paper, I'm calling
it the "commit-before-merge" model, as opposed to "merge-before-commit"
which is what CVS and Subversion do.  It seems to have originated with
monotone.

CVS and Subversion try to maintain a linear version history unless you
do explicit branching.  So when you commit a change against an out-of-date
revision, they raise a conflict; you have to merge news before being
allowed to finish the commit.

In modern DVCSes, a push never blocks. The sequence of changesets you
developed is grafted into the repo as a branch attached to the
revision you pulled from.

If no one else has committed or pushed against that revision, the line
of development remains linear.  If someone has, you have the analogue
of a CVS conflict -- the revision is now a branch point with two
histories going forward.  

Later, someone may do a merge operation that fuses those two branches
together again.  Thus, "commit-before-merge".

This is certainly the way monotone, Mercurial, and bzr operate.  As
I said, I have not yet studied git specifically but I'm pretty sure
it works the same way.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: What a modern collaboration toolkit looks like

[Stephen J. Turnbull]

*sigh*  And I just finished writing a private message saying I didn't
want to get involved.

Eric S. Raymond writes:

 > CVS and Subversion try to maintain a linear version history unless you
 > do explicit branching.  So when you commit a change against an out-of-date
 > revision, they raise a conflict; you have to merge news before being
 > allowed to finish the commit.
 > 
 > In modern DVCSes, a push never blocks.

I think you've typoed "push" for "commit".  Specifically:

This conflicts with Mercurial terminology.  *commits* never block in
Mercurial.  *Pushes* do, unless you use "hg push -f" (which creates an
alias-less head in the target repo---its only names are the revno and
the hash).

I suspect what you meant to say here is that "In a modern DVCS, a
commit never blocks".  The reason that "commit" blocks in CVS and SVN
is because in those VCSes "commit" can be considered equivalent to a
Mercurial "commit + push".  Ie, CVS and SVN commits can block because
pushes always can block, and every commit implies a push.

Proliferating new heads in the public repo is antisocial; that's what
local repos are for.  Unfortunately, (loosely speaking) CVS and SVN
don't support local repos, so there's no way to separate commit and
push for most projects.  If the push blocks, the commit must do so.

 > This is certainly the way monotone, Mercurial, and bzr operate.

If "push" wasn't a typo, please recheck your information on monotone
and bzr, too.  I find it hard to believe that they silently allow
pushes to succeed when they would create new heads; this is a recipe
for disaster.

 > As I said, I have not yet studied git specifically but I'm pretty
 > sure it works the same way.

Like Mercurial, git blocks if you try to push a branch to a ref which
is not a prefix of the branch you're pushing.

Unlike Mercurial, "git push -f" just does what you tell it to do (push
a bunch of objects and set the ref to the same commit as HEAD points
to locally), and therefore will create garbage (lost commits and their
dependent objects) in most cases.  It does not create an implicit new
head (which can have no reference except its SHA1, and thus is pretty
useless).  Neither behavior seems particularly useful to me.

BTW, to be honest, I think "commit-before-merge" is a good advertising
slogan, but it doesn't promote understanding of how dVCSes work, and
only offers the GUI/CADT/IRC/XP view of their advantages.

Re: What a modern collaboration toolkit looks like

[Eric S. Raymond]

Stephen J. Turnbull <stephen@xemacs.org>:
>  > In modern DVCSes, a push never blocks.
> 
> I think you've typoed "push" for "commit".  Specifically:

You're right, I did.
 
> BTW, to be honest, I think "commit-before-merge" is a good advertising
> slogan, but it doesn't promote understanding of how dVCSes work, and
> only offers the GUI/CADT/IRC/XP view of their advantages.

/me becomes dizzy from a surfeit of acronyms.

I coined the term mainly to contrast with the CVS/Subversion/Arch
style, which requires merge before a commit can complete.  I don't
try to make it bear a lot of analytical weight.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: What a modern collaboration toolkit looks like

[Richard Stallman]

    In modern DVCSes, a push never blocks. The sequence of changesets you
    developed is grafted into the repo as a branch attached to the
    revision you pulled from.

    If no one else has committed or pushed against that revision, the line
    of development remains linear.  If someone has, you have the analogue
    of a CVS conflict -- the revision is now a branch point with two
    histories going forward.  

    Later, someone may do a merge operation that fuses those two branches
    together again.  Thus, "commit-before-merge".

I think I understand that now, but it raises other questions.

Does this mean there is no concept of "trunk"?  When someone who is
not normally a participant in the project decides to "download the
current sources", which revision does he get?  More precisely, what
determines which revision he gets?

The operation analogous to a CVS commit to the trunk
would consist of pushing a new revision and then
whatever else is needed to make that revision the new trunk.

Re: What a modern collaboration toolkit looks like

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> Does this mean there is no concept of "trunk"?  When someone who is
> not normally a participant in the project decides to "download the
> current sources", which revision does he get?  More precisely, what
> determines which revision he gets?

Yes there is a concept of a trunk -- at least with git, each repository
can contain named branches (each a reference to the tip of some
development line), and the branch called "master" is the default for
many operations.

-Miles

-- 
Is it true that nothing can be known?  If so how do we know this?  -Woody Allen

Re: What a modern collaboration toolkit looks like

[Eric S. Raymond]

Miles Bader <miles@gnu.org>:
> Yes there is a concept of a trunk -- at least with git, each repository
> can contain named branches (each a reference to the tip of some
> development line), and the branch called "master" is the default for
> many operations.

Yes.  I suppose you could call this treating "master" specially, 
which contradicts my last post in a minor way.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: What a modern collaboration toolkit looks like

[Richard Stallman]

    Yes there is a concept of a trunk -- at least with git, each repository
    can contain named branches (each a reference to the tip of some
    development line), and the branch called "master" is the default for
    many operations.

So which is the operation that alters the current version in the
trunk?

Re: What a modern collaboration toolkit looks like

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>     Yes there is a concept of a trunk -- at least with git, each repository
>     can contain named branches (each a reference to the tip of some
>     development line), and the branch called "master" is the default for
>     many operations.
>
> So which is the operation that alters the current version in the
> trunk?

For _your_ new changes:  git commit

For getting _others_ changes from a remote repository:  git pull

There are other commands that affect things, but the above are the most
common.

For people that use git, they really do think of "git commit" as the
git analogue of "cvs commit" -- it does "most of the things" cvs commit
does.

I guess you can think of cvs commit as being split into two different
commands in git:  git commit (which does most of the work -- bundling up
the changes to your working directory, adding a log message, updating
the head of the current branch), and git push (which sends your local
changes to a remote repository).

Stephen Turnbull posted a good explanation in this thread.

-Miles

-- 
I'm beginning to think that life is just one long Yoko Ono album; no rhyme
or reason, just a lot of incoherent shrieks and then it's over.  --Ian Wolff

Re: What a modern collaboration toolkit looks like

[Eric S. Raymond]

Richard Stallman <rms@gnu.org>:
> Does this mean there is no concept of "trunk"?  When someone who is
> not normally a participant in the project decides to "download the
> current sources", which revision does he get?  More precisely, what
> determines which revision he gets?

The "current sources" is generally going to be one of the repo tip revisions
packaged into a tarball by a release manager.  This is not a VCS operation.

If you clone the repo, you get the entire history -- the entire DAG of 
revisions.  Technically speaking, there is no "trunk", no distinguished
branch that VCS operations treat specially.  If you do an update without
specifying a release or branch name, you simply get the latest 
sequential revision.

Socially, the "trunk" is probably the branch the last release tarball
was taken from.  Some of these systems support named branches.  When 
that's so, you can label a branch "trunk" if you like.  
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: What a modern collaboration toolkit looks like

[Richard Stallman]

    The "current sources" is generally going to be one of the repo tip revisions
    packaged into a tarball by a release manager.  This is not a VCS operation.

That applies if/when you make a release.  But what about between relesaes?
Currently we recommend that people "build the source from CVS", and we
don't say "from the trunk" because that is a general convention of CVS
usage.

If we used git, what convention would replace that?  Would we have to
establish our own?  Would we need to maintain a file saying which branch
to get and build?  If so, I think the operation of adding versions
to that branch would be the real analogue of a CVS commit to the urunk.

Re: What a modern collaboration toolkit looks like

[Eric S. Raymond]

Richard Stallman <rms@gnu.org>:
>> The "current sources" is generally going to be one of the repo tip revisions
>> packaged into a tarball by a release manager.  This is not a VCS operation.
> 
> That applies if/when you make a release.  But what about between relesaes?
> Currently we recommend that people "build the source from CVS", and we
> don't say "from the trunk" because that is a general convention of CVS
> usage.
> 
> If we used git, what convention would replace that?  Would we have to
> establish our own?  Would we need to maintain a file saying which branch
> to get and build?  If so, I think the operation of adding versions
> to that branch would be the real analogue of a CVS commit to the urunk.

I don't know the answer to this question in the specific context of git,
because I have yet not studied git workflow closely (I will soon).

In Mercurial, you'd say: Build from the tip of the branch named "trunk".
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: What a modern collaboration toolkit looks like

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

> Currently we recommend that people "build the source from CVS", and we
> don't say "from the trunk" because that is a general convention of CVS
> usage.
>
> If we used git, what convention would replace that?

It's the same, basically.  If you clone a git repository, your personal
repository is automatically set up to track the default branch of the
remote repository, which is normally the master branch.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: What a modern collaboration toolkit looks like

[Mike Mattie]

[-- Attachment #1.1: Type: text/plain, Size: 6701 bytes --]

On Sat, 05 Jan 2008 16:59:13 +0100
Andreas Schwab <schwab@suse.de> wrote:

> Richard Stallman <rms@gnu.org> writes:
> 
> > Currently we recommend that people "build the source from CVS", and
> > we don't say "from the trunk" because that is a general convention
> > of CVS usage.
> >
> > If we used git, what convention would replace that?
> 
> It's the same, basically.  If you clone a git repository, your
> personal repository is automatically set up to track the default
> branch of the remote repository, which is normally the master branch.
> 
> Andreas.
> 

take a look at www.kernel.org. I use git for my linux tree. 

I am what you would call the end-user in this case. My use is alot
simpler with git.

When a release is pending I check the changelogs via gitweb, do various
searches for hardware and sub-systems of interest. If I like what I see
I simply cut & paste the git url into a git-pull and merge the upstream
changes.

On a regular basis I pull from two branches, the first branch being the
official linus tree, the second is usually 2.6.x.y for patch releases.

Occasionally I need to debug a kernel problem with a pre-release. When
this happens if the developer for the sub-system is using git I can
pull fixes from his tree while we are diagnosing the problem. Once it
is fixed I don't have to revert the changes before I pull from the official
repo again, because the maintainer requests a pull from linus, it gets merged,
and git doesn't barf on previously merged changes.

In fact during this discussion I have noticed a key point that has not been mentioned.
If RMS is wondering how a project is lead with a distributed system the answer is
the convention of asking for a pull.

I don't think anyone "pushes" changes on Linus. When they have something that is in shape
for him to review they request via e-mail a pull and give the git URL. Linus is then
free to look through the history of their branch. He can see not just the work, but the history.
That includes all the changes, bugs, and features. By reading the history he can get a much
greater sense of how it developed, not just a diff. If he likes it, he pulls it. If not they
can keep at it and ask again later. When he pulls he gets the full history.

CVS is crippled in that there is no way to record changes before commit. I personally do
not like CVS like systems because it puts a huge burden on the developer that actually
works really hard to do a clean merge for review.

What I consider a clean merge for review to be is this: Broken up into changes where each
change can be described succinctly by a changelog, and the change must not break compile
or regress. 

here is a little constrast sketch:

bad commit:
add subsystem foo , with new data structure bar, modifying existing code baz to use new data structure bar.

Good commit:

1. add new data structure bar
2. modify baz to use new data structure bar
3. add subsystem foo.

Notice how in the good commit the maintainer of baz can evaluate the new data structure without wading
through my new subsystem foo which he probably doesn't care about. If CVS and DVCS systems where compared
to writing CVS would not have topics or paragraphs, just one huge body of text. Changes in DVCS systems
can be broken up, like a body of text into paragraphs so that people can understand them better.

Because CVS cannot record changes in the working copy you have to do one of two things:

A. finish the entire work and publish as a single commit. This alternative is so broken you actually
   have to backup your working copy changes yourself.
B. break the commit up into valid changes and try and maintain a diff series in the working copy
   until you can submit the sequence. Again backing up yourself.
C. use a branch.

Of course people who use CVS will say C is an entirely valid option. It does work. But it discourages
casual development and definitely would discourage me. I don't like to make proposals without
code to show. Often until the code is fleshed out I don't have the facts to make a proposal.
With CVS I have to get a commit bit, get a branch (sounds like paperwork), and finally start
hacking away. I consider this high risk because I have to declare my success (proposal + commit bit + branch)
before I know if the idea will even work.

I would much rather hack away on any distributed VCS where I can pick the good idea from the dozens
of ideas that seemed good but did not pan out. When I would go to "request pull" or merge I can
show the entire history of the development.

DVCS are not perfect, but they at least make what I call a good commit possible without having to
do what I consider absurd labor. When I have to work on a project using CVS or even SVN I spend
a huge amount of time manually slicing and dicing diffs in diff mode. If anything goes wrong in
the diff sequence I am in big trouble so I also have to keep full copies at each "change point".
At that point It's not a reversion control system for me, it's just a publishing tool. All of
the changes have to be maintained by hand in diff-mode.

What I call good commits has two key points. It feeds changes incrementally for both review and
testing. Who wants to try and test a huge chunk of code dropped in a single commit ? Doing things
the right way usually pays off even in ways you don't anticipate, like git-bisect. I have personally
used that to track down a problem with a IDE driver. I found the broken changeset in something like six
reboots. The fix was in the Linus tree within days.

I don't think it works at all to try and describe git in terms of CVS. In fact dictating how you
merge by version control system is kinda supsect as well. The goal should be to turn in high
quality merges, incrementally reviewed, incrementally merged and tested. Any change that breaks
the compile or test-harness is sin plain and simple. If a project can't maintain that standard
with their tools then their tools are a problem. If the developers are so skilled at flaking
diffs from their working copy like cavemen flaking arrowheads from stone, then there is no
problem.

On the other hand if merging changes is a problem, then there is a *big* problem. I don't think
merging is something you do for release, it's something you do to integrate the work of a team.
If you can't merge you can't work together. If anything branching is for release, not development.

My 2 cents at least. Please don't take any offense from any of these statements. No person
or caricature was harmed in the writing of this mail.

Cheers,
Mike Mattie (peanut gallery)

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: What a modern collaboration toolkit looks like

[Giorgos Keramidas]

On 2008-01-02 04:53, Richard Stallman <rms@gnu.org> wrote:
>     You can commit a change offline (git commit).  Later on,
>     when you are online, you say `git pull' to get the current
>     state of the repository, and automatical merging happens
>     (and the usual warnings if there are conflicts).  Finally,
>     you say `git push' to synchronize your git repository with
>     the global one.
>
> Is this substantially different from CVS, or is it just
> relabeling?  It sounds like `git push' is basically equivalent
> to CVS commit.

Yes, there is a substantial difference between committing in a
distributed SCM like Git, and Mercurial (the latter is the one I
am most familiar with).

A commit `attaches' a changeset to a `parent changeset', forming
a changeset graph instead of a linear history.  So if I pull from
the central Emacs repository the changes:

    [1]---[2]---[3]

and start committing on top of this, I will end up with a local
history like this:

    [1]---[2]---[3]---[4]---[5]---[6]

In the mean time, other people have the chance to commit their
own changes to the central tree, on top of the original [3]
changeset.  When I finish my work, and I `pull' from the central
tree again, the local Git history becomes:

                  ,---[7]---[8]
                 /
    [1]---[2]---[3]---[4]---[5]---[6]

A major difference in this sort of history is that *all* changes
have been safely stashed away in the local history.  The working
area of the repository/workspace can, for all intents and
purposes, be considered volatile and completely unimporant.

Having this sort of local history, I can `check out' any one of
the committed changes.  Looking at the `remote' changes I just
pulled is possible with normal `update' commands in Mercurial (a
similar command is available in Git).  This means that switching
between the `local' version and the `remote' version of the code
is as easy as:

    hg update --clean 8               ; remote version is checked out

    hg update --clean 6               ; local version is checked out

The usual commands, like `diff' also work, i.e.:

    hg diff -r 6:8                    ; look at 6 -> 8 patch

    hg diff -r 8:6                    ; look at the inverse patch

Note that a `merge' has not happened yet.  If the remote head of
the history tree looks easy enough to merge, a merge operation
can be done in two ways:

    1) Merging of the two heads, to forma history graph like:

                       ,---[7]---[8]---------[9]
                      /                      /
         [1]---[2]---[3]---[4]---[5]---[6]--'

    2) A `rebase' operation, which restores the linear history of
       the remote branch, and `rebases' all the local changesets
       on top of the remote branch:

         [1]---[2]---[3]---[7]---[8] - - - [4']---[5']---[6']

> With CVS, until you commit your changes, new changes can be
> installed in the repository, and when you DO get around to
> committing your changes, you will have to merge them with
> whatever others have installed.  Once you commit, others trying
> to commit will have the burden of merging their changes with
> your already-committed changes.

The main ease of use from the distributed SCM systems is a result
of the different from the workflow you just described.  With CVS
committers are encouraged to avoid committing local changes,
until a future moment when ``the patch will be done and fully
working''.  When they reach that future point, the onus of the
merging falls on the person who wants to commit.

With a distributed SCM system, committing is not so `scary'.
It's ok to commit often, and commit short changes.  They are
local.  They won't break the remote tree for anyone else.

Merging can also be done much more often.  This means that it's
ok to merge or rebase a pile of local changes 10 or 20 times,
while they are being developed.  If the first sort of merging
described above is chosen, then repeated merges work
incrementally, so conflicts that have been resolved in one of the
past merges don't reappear in future merges.

> With git, I would guess that the same situation obtains until
> you do `git push' with your changes.  Thus, I think that `git
> push' is the true analogue to CVS commit.

If a dSCM repository is `anointed' by the team as *the*
repository, then there are hooks which can control whether:

    * It is ok to create `remote heads' with unmerged changes
      (this is what happens for example if someone pushes the
      sample history graph shown above, before the merge of
      change [9] happens)

    * It is ok to push new `branches' in the remote tree

> This is based on surmise rather than knowledge.  If it is
> wrong, where is the mistake?

It's mostly right.  A `push' operation is that `publishes' a
change in a dSCM world.  The only difference is that a `commit'
in a centralized SCM (like CVS) does several things, which have
been split in a more fine-grained set of operations in a
distributed SCM system.  When a commit happens in CVS then:

    * A local `merge' has completed

    * CVS add, or remove commands have been completed

    * A commit sends the files to the remote server (the
      `publishing' part)

    * The local workspace state is updated to match the new state
      of the tree

In a distributed SCM a `commit' is only part of the above:

    * A changeset is recorded in the local repository storage
      area

    * Local workspace state is updated

A merge is not strictly necessary, and the changes haven't been
published anywhere else yet.

HTH,
Giorgos

Re: What a modern collaboration toolkit looks like

[Eric S. Raymond]

Giorgos Keramidas <keramida@ceid.upatras.gr>:
> Yes, there is a substantial difference between committing in a
> distributed SCM like Git, and Mercurial (the latter is the one I
> am most familiar with).

Note to RMS: Giorgios's explanation is better than mine.  I'm
just learning these systems, but he is clearly very experienced
and fluent with them.

Giorgios, can I interest you in being a reviewer for my survey
paper?  You sound like you may one of the people I need looking over
my shoulder as I try to design test and benchmarking suites for
DVCSes.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: What a modern collaboration toolkit looks like

[Giorgos Keramidas]

On 2008-01-02 21:56, "Eric S. Raymond" <esr@thyrsus.com> wrote:
>Giorgos Keramidas <keramida@ceid.upatras.gr>:
>> Yes, there is a substantial difference between committing in a
>> distributed SCM like Git, and Mercurial (the latter is the one I
>> am most familiar with).
>
> Note to RMS: Giorgios's explanation is better than mine.  I'm
> just learning these systems, but he is clearly very experienced
> and fluent with them.
>
> Giorgios, can I interest you in being a reviewer for my survey
> paper?  You sound like you may one of the people I need looking over
> my shoulder as I try to design test and benchmarking suites for
> DVCSes.

Sure.

I'm not very experienced with *all* the dSCM systems, but I will gladly
help with what I know about Mercurial, Git, and Bazaar (these are the
ones I am acquainted with, in decreasing order of experience).

I've already cloned http://thyrsus.com/hg/uvc/ because I wanted to read
the article anyway.  Please feel free to email me with any guidelines
about the review and/or other useful things.

Regards,
Giorgos

Re: What a modern collaboration toolkit looks like

[Richard Stallman]

      With CVS
    committers are encouraged to avoid committing local changes,
    until a future moment when ``the patch will be done and fully
    working''.  When they reach that future point, the onus of the
    merging falls on the person who wants to commit.

    With a distributed SCM system, committing is not so `scary'.
    It's ok to commit often, and commit short changes.  They are
    local.  They won't break the remote tree for anyone else.

I don't think it makes sense to compare these two different "commit"
operations -- it's like comparing an apple to an orange tree branch.
If you compare applies with oranges instead, the difference is
much less.

Re: What a modern collaboration toolkit looks like

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>       With CVS
>     committers are encouraged to avoid committing local changes,
>     until a future moment when ``the patch will be done and fully
>     working''.  When they reach that future point, the onus of the
>     merging falls on the person who wants to commit.
>
>     With a distributed SCM system, committing is not so `scary'.
>     It's ok to commit often, and commit short changes.  They are
>     local.  They won't break the remote tree for anyone else.
>
> I don't think it makes sense to compare these two different "commit"
> operations -- it's like comparing an apple to an orange tree branch.
> If you compare applies with oranges instead, the difference is
> much less.

I think that the comparison is quite accurate: the commit does
everything that a commit in CVS does.  The difference in workflow is not
in committing, it is in the fact that everybody has his own repository
(and all of them are equal).  The difference is that cooperation works
by synchronizing repositories (which does not even need a checked-out
work directory), not by committing to a central repository.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: What a modern collaboration toolkit looks like

[Richard Stallman]

    > I don't think it makes sense to compare these two different "commit"
    > operations -- it's like comparing an apple to an orange tree branch.
    > If you compare applies with oranges instead, the difference is
    > much less.

    I think that the comparison is quite accurate: the commit does
    everything that a commit in CVS does.  The difference in workflow is not
    in committing, it is in the fact that everybody has his own repository
    (and all of them are equal).

I think that is a confusing way to compare them.
It focuses on similarities in implementation
rather than on similarities in use and role.

Re: What a modern collaboration toolkit looks like

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     > I don't think it makes sense to compare these two different "commit"
>     > operations -- it's like comparing an apple to an orange tree branch.
>     > If you compare applies with oranges instead, the difference is
>     > much less.
>
>     I think that the comparison is quite accurate: the commit does
>     everything that a commit in CVS does.  The difference in workflow is not
>     in committing, it is in the fact that everybody has his own repository
>     (and all of them are equal).
>
> I think that is a confusing way to compare them.
> It focuses on similarities in implementation
> rather than on similarities in use and role.

But the use and role is completely the same as using a private CVS
repository: all the diff and merge and branch and commit machinery works
for single persons quite similar as with CVS.

The difference is just that there are more elaborate mechanisms than
rsync for synchronizing several private repositories.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: What a modern collaboration toolkit looks like

[Richard Stallman]

    > I think that is a confusing way to compare them.
    > It focuses on similarities in implementation
    > rather than on similarities in use and role.

    But the use and role is completely the same as using a private CVS
    repository: all the diff and merge and branch and commit machinery works
    for single persons quite similar as with CVS.

We are miscommunicating.  I'm using the word role "role" to refer to
relationship actions, such as "changing which version a user will get
when he asks for the current development version".

Re: What a modern collaboration toolkit looks like

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     > I think that is a confusing way to compare them.
>     > It focuses on similarities in implementation
>     > rather than on similarities in use and role.
>
>     But the use and role is completely the same as using a private CVS
>     repository: all the diff and merge and branch and commit machinery works
>     for single persons quite similar as with CVS.
>
> We are miscommunicating.  I'm using the word role "role" to refer to
> relationship actions, such as "changing which version a user will get
> when he asks for the current development version".

"the current development version" is not a concept for git.  No
repository is special as far as git is concerned.  The "current
development version" is a social, not a technical concept.  For example,
the git maintainer was off-line unexpectedly for some months recently.
Somebody else took over seamlessly by collecting, arranging and
coordinating patches on the git list into _his_ repository.  When the
maintainer finally came back, he more or less pulled from this person's
repository (could have been one or more persons), and the "official"
repo was more or less in synch.

There is no single point of failure.  In fact, Linux has about a dozen
serious kernel repositories maintained by different persons which all
have a different set of patches that they consider fit for use.  They
exchange patch sets, and some are accepted and some are left out, but
the special role for Linus Torvalds' kernel is just that people like his
criteria for what he applies and what he rejects (either ultimately, or
at first).

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: What a modern collaboration toolkit looks like

[Richard Stallman]

    "the current development version" is not a concept for git.  No
    repository is special as far as git is concerned.  The "current
    development version" is a social, not a technical concept.  For example,
    the git maintainer was off-line unexpectedly for some months recently.
    Somebody else took over seamlessly by collecting, arranging and
    coordinating patches on the git list into _his_ repository.

With CVS, people can get the current version of every program on
savannah in a uniform way.  What you say seems to imply that that is
not possible with git.  That seems like a big step backwards.

Within a community of people that work together, it won't be a
problem.  They will know to look THERE instead of HERE.  But users in
general can't be expected to check for that sort of thing before they
get the current development Emacs.

Re: What a modern collaboration toolkit looks like

[dhruva]

Hello,

On Jan 7, 2008 9:48 AM, Richard Stallman <rms@gnu.org> wrote:
> With CVS, people can get the current version of every program on
> savannah in a uniform way.  What you say seems to imply that that is
> not possible with git.  That seems like a big step backwards.

There can still be one _offcial_ repository from which "people" (non
core developer community) can pull from. This could be equivalent to
the current HEAD. The only difference would be that in CVS, every core
developer checks into the _official_ repository where as in a dVCS,
the maintainer can pull in the changes from the various core
developers (or core developers can push) into it.

> Within a community of people that work together, it won't be a
> problem.  They will know to look THERE instead of HERE.  But users in
> general can't be expected to check for that sort of thing before they
> get the current development Emacs.

The above work flow would allow a single point access to the latest as
it is in the current state with CVS. You could treat all other dVCS
repositories belonging to various developers and different features as
current branches in CVS. As the users know of HEAD in CVS, IMO, they
will easily (I presume) learn about "master" in GIT or "default" in
mercurial.

with best regards,
dhruva

-- 
Contents reflect my personal views only!

Re: What a modern collaboration toolkit looks like

[Sam Steingold]

> * Richard Stallman <ezf@tah.bet> [2008-01-06 23:18:05 -0500]:
>
>     "the current development version" is not a concept for git.  No
>     repository is special as far as git is concerned.  The "current
>     development version" is a social, not a technical concept.  For example,
>     the git maintainer was off-line unexpectedly for some months recently.
>     Somebody else took over seamlessly by collecting, arranging and
>     coordinating patches on the git list into _his_ repository.
>
> With CVS, people can get the current version of every program on
> savannah in a uniform way.  What you say seems to imply that that is
> not possible with git.  That seems like a big step backwards.

No, this just means that if savannah goes down, nobody can get emacs
from CVS (people can't work on emacs, can't exchange patches &c).
with DVCS, someone can announce that he is stepping in for savannah and
people would hardly notice other than by having to give a different
argument to "git pull" and "git push".

Note however that with CVS, getting CVS head and building it is hardly
more expensive than downloading a source tarball - wrt both bandwidth
and disk space.  With git, the situation is vastly different: you cannot
just get the head, you always get the whole change history, so instead
of 40MB, you will be getting and storing 200MB.  This may not be a big
deal these days for many people, but it might be a showstopper for some.

-- 
Sam Steingold (http://sds.podval.org/) on Fedora release 8 (Werewolf)
http://mideasttruth.com http://memri.org http://israelunderattack.slide.com
http://palestinefacts.org http://truepeace.org http://ffii.org
Isn't "Microsoft Works" an advertisement lie?

Re: What a modern collaboration toolkit looks like

[dhruva]

Hi,

On Jan 7, 2008 10:22 AM, Sam Steingold <sds@gnu.org> wrote:
> Note however that with CVS, getting CVS head and building it is hardly
> more expensive than downloading a source tarball - wrt both bandwidth
> and disk space.  With git, the situation is vastly different: you cannot
> just get the head, you always get the whole change history, so instead
> of 40MB, you will be getting and storing 200MB.  This may not be a big
> deal these days for many people, but it might be a showstopper for some.

FWIK, there are options to specify the depth of revision history you
want in a clone. You can reduce the data size. The GIT/Mercurial
repository frontend has an option to make a snapshot of the current
repository. People could use that feature too. IMHO, it is something
that is realizable with dVCS.

-dky

-- 
Contents reflect my personal views only!

Re: What a modern collaboration toolkit looks like

[David Kastrup]

Sam Steingold <sds@gnu.org> writes:

>> * Richard Stallman <ezf@tah.bet> [2008-01-06 23:18:05 -0500]:
>>
>>     "the current development version" is not a concept for git.  No
>>     repository is special as far as git is concerned.  The "current
>>     development version" is a social, not a technical concept.  For example,
>>     the git maintainer was off-line unexpectedly for some months recently.
>>     Somebody else took over seamlessly by collecting, arranging and
>>     coordinating patches on the git list into _his_ repository.
>>
>> With CVS, people can get the current version of every program on
>> savannah in a uniform way.  What you say seems to imply that that is
>> not possible with git.  That seems like a big step backwards.
>
> No, this just means that if savannah goes down, nobody can get emacs
> from CVS (people can't work on emacs, can't exchange patches &c).
> with DVCS, someone can announce that he is stepping in for savannah and
> people would hardly notice other than by having to give a different
> argument to "git pull" and "git push".
>
> Note however that with CVS, getting CVS head and building it is hardly
> more expensive than downloading a source tarball - wrt both bandwidth
> and disk space.  With git, the situation is vastly different: you cannot
> just get the head, you always get the whole change history, so instead
> of 40MB, you will be getting and storing 200MB.  This may not be a big
> deal these days for many people, but it might be a showstopper for some.

You just need to get the history once.  After that, only deltas are
transmitted.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: What a modern collaboration toolkit looks like

[Stefan Monnier]

> You just need to get the history once.  After that, only deltas are
> transmitted.

Until you need to checkout a new copy of the trunk, of course.
Also, many DVCS keep a copy of the repository per checked out tree,
which becomes costly when you have many checked out trees
(e.g. unicode, multi-tty, trunk, your-own, 22, lexbind, yournameit,
plus some copies for tentative hacks, ...).


        Stefan

Re: What a modern collaboration toolkit looks like

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> You just need to get the history once.  After that, only deltas are
>> transmitted.
>
> Until you need to checkout a new copy of the trunk, of course.

Huh?  Why would you need to do that?  Anyway, even if you think you need
another checked out work copy (and with git I am very rarely in that
situation), you can either clone your original repository (optionally
using hard links to its object store to save space) or at least tell git
to reuse its object store.

> Also, many DVCS keep a copy of the repository per checked out tree,
> which becomes costly when you have many checked out trees
> (e.g. unicode, multi-tty, trunk, your-own, 22, lexbind, yournameit,
> plus some copies for tentative hacks, ...).

I don't see why you would need more than one tree to work with at any
given point of time.  And even then, you can tell git to share all the
respective data.  Either using a single repository (probably the sanest
variant with regard to pulling and updates) or multiple ones.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: What a modern collaboration toolkit looks like

[Stefan Monnier]

> I don't see why you would need more than one tree to work with at any
> given point of time.

I often work for example with 4 branches: the 22 branch, the trunk, the
unicode branch, and my own branch with its local hacks.  I switch
between them often enough that using a single tree and switching within
the tree would be a real pain in the *** because of the need to rebuild
all the .o and .elc files after each switch.


        Stefan

Re: What a modern collaboration toolkit looks like

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I don't see why you would need more than one tree to work with at any
>> given point of time.
>
> I often work for example with 4 branches: the 22 branch, the trunk, the
> unicode branch, and my own branch with its local hacks.  I switch
> between them often enough that using a single tree and switching within
> the tree would be a real pain in the *** because of the need to rebuild
> all the .o and .elc files after each switch.

Hm?  Why do you build Emacs in-place, then?  I understand the need for 4
build directories, but do you really need 4 source directories?  And
even 4 repositories?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: What a modern collaboration toolkit looks like

[CHENG Gao]

*On Sun, 06 Jan 2008 23:52:53 -0500
* Also sprach Sam Steingold <sds@gnu.org>:

> Note however that with CVS, getting CVS head and building it is hardly
> more expensive than downloading a source tarball - wrt both bandwidth
> and disk space.  With git, the situation is vastly different: you cannot
> just get the head, you always get the whole change history, so instead
> of 40MB, you will be getting and storing 200MB.  This may not be a big
> deal these days for many people, but it might be a showstopper for some.

Yes you are right. Ever I tried to git clone emacs git repo at home, and
it took forever so I had to abort the mission. I got a 2m ADSL at home.
Instead I git cloned it in office, and it took only several minutes with
10M line. My experience and worry is git clone may be slow for slow
connections.

Personally I hope Emacs can be developped with DVCS like git or
Mercurial or bzr since I trust it's easier for Emacs developers to add
new features and for users to test these features. And then developers
can submit mature features/codes to some dedicated mailing list via
email (git or hg or bzr all have this feature to easily generate and
send patchs) for review by core developer(s) or a dedicated team. If
codes are accepted, they can be merged into OFFICIAL CENTRALIZED Emacs
repo, and at the same time propogated to Emacs CVS. (If I understand
correctly, it's what Bug Buddy of BZR does).

I hope Emacs can use this decentralized/centralized combination. It
makes development easier and codes can get more extensive testing since
users can test features by cloning some unofficial work-in-progress
features. And at the same time, it can maintain stability and integrity
of official repo.

I think the proper time is after merge of unicode-2 branch since then
only two or three branches need be kept - master, emacs_22_base (&
lexbind?).

-- 
Volo, non valeo

Re: What a modern collaboration toolkit looks like

[Stephen J. Turnbull]

CHENG Gao writes:

 > Yes you are right. Ever I tried to git clone emacs git repo at home, and
 > it took forever so I had to abort the mission. I got a 2m ADSL at home.
 > Instead I git cloned it in office, and it took only several minutes with
 > 10M line. My experience and worry is git clone may be slow for slow
 > connections.

There are workarounds for this.  For example, find a volunteer, send
them a SASE and a blank CD-ROM and request a copy of the .git
directory.  This costs only a few minutes of your time and a few
dollars in S&H.  Or maybe the FSF could make a few bucks with a
service like this.

It might also be faster to rsync the .git directory, although if the
.git directory is well-packed it shouldn't make much difference.

As you suggest, a CVS mirror of the official public repo could be
maintained as a convenience to nondevelopers.

Re: What a modern collaboration toolkit looks like

[CHENG Gao]

*On Tue, 08 Jan 2008 08:36:54 +0900
* Also sprach "Stephen J. Turnbull" <stephen@xemacs.org>:
> There are workarounds for this. For example, find a volunteer, send
> them a SASE and a blank CD-ROM and request a copy of the .git
> directory. This costs only a few minutes of your time and a few
> dollars in S&H. Or maybe the FSF could make a few bucks with a service
> like this.
>
> It might also be faster to rsync the .git directory, although if the
> .git directory is well-packed it shouldn't make much difference.
>
> As you suggest, a CVS mirror of the official public repo could be
> maintained as a convenience to nondevelopers.

In fact it's not problem for me. I git cloned it in office and copied it
home.
Slowness is in "Indexing objects" stage since Emacs has huge number of
objects (more than 450000 now).

-- 
The enemies of Freedom do not argue; they shout and they shoot.

Re: What a modern collaboration toolkit looks like

[Mike Mattie]

[-- Attachment #1.1: Type: text/plain, Size: 1240 bytes --]

On Tue, 08 Jan 2008 08:36:54 +0900
"Stephen J. Turnbull" <stephen@xemacs.org> wrote:

> CHENG Gao writes:
> 
>  > Yes you are right. Ever I tried to git clone emacs git repo at
>  > home, and it took forever so I had to abort the mission. I got a
>  > 2m ADSL at home. Instead I git cloned it in office, and it took
>  > only several minutes with 10M line. My experience and worry is git
>  > clone may be slow for slow connections.
> 
> There are workarounds for this.  For example, find a volunteer, send
> them a SASE and a blank CD-ROM and request a copy of the .git
> directory.  This costs only a few minutes of your time and a few
> dollars in S&H.  Or maybe the FSF could make a few bucks with a
> service like this.
> 
> It might also be faster to rsync the .git directory, although if the
> .git directory is well-packed it shouldn't make much difference.
> 
> As you suggest, a CVS mirror of the official public repo could be
> maintained as a convenience to nondevelopers.

non-developers quickly turn into developers once they hit a bug.

> 
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: What a modern collaboration toolkit looks like

[Mike Mattie]

[-- Attachment #1.1: Type: text/plain, Size: 1769 bytes --]

On Mon, 07 Jan 2008 23:40:51 +0800
CHENG Gao <chenggao@gmail.com> wrote:

> *On Sun, 06 Jan 2008 23:52:53 -0500
> * Also sprach Sam Steingold <sds@gnu.org>:
> 
> > Note however that with CVS, getting CVS head and building it is
> > hardly more expensive than downloading a source tarball - wrt both
> > bandwidth and disk space.  With git, the situation is vastly
> > different: you cannot just get the head, you always get the whole
> > change history, so instead of 40MB, you will be getting and storing
> > 200MB.  This may not be a big deal these days for many people, but
> > it might be a showstopper for some.
> 
> Yes you are right. Ever I tried to git clone emacs git repo at home,
> and it took forever so I had to abort the mission. I got a 2m ADSL at
> home. Instead I git cloned it in office, and it took only several
> minutes with 10M line. My experience and worry is git clone may be
> slow for slow connections.

good point, even in the U.S the midwest is still on dialup outside of
the major metro regions. I am on broad-band so I never checked if git
has a "resume" option to continue a clone operation that is interrupted,
or if that is integral to clone.

The second, third world is also a consideration e.g The current architect
of the parrot project lives somewhere in Africa. There is alot of talent
outside of the regions that are blinding on a connectivity map. 

Another thing that has not been mentioned is the usefulness of dropping
or limiting history. I made a slight mistake in the arguments to git
log and I ended up with a 23 Mb log buffer that went back to the 'mid 90's.

Some potential pitfalls to consider. I don't think they are show-stoppers
but they are scenarios that need consideration.



[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: What a modern collaboration toolkit looks like

[Andreas Schwab]

Mike Mattie <codermattie@gmail.com> writes:

> good point, even in the U.S the midwest is still on dialup outside of
> the major metro regions. I am on broad-band so I never checked if git
> has a "resume" option to continue a clone operation that is interrupted,
> or if that is integral to clone.

You can clone a shallow copy of the repository and deepen it later.

> Another thing that has not been mentioned is the usefulness of dropping
> or limiting history. I made a slight mistake in the arguments to git
> log and I ended up with a 23 Mb log buffer that went back to the 'mid 90's.

You can always interrupt the process.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: What a modern collaboration toolkit looks like

[Jason Earl]

Richard Stallman <rms@gnu.org> writes:

>     "the current development version" is not a concept for git.  No
>     repository is special as far as git is concerned.  The "current
>     development version" is a social, not a technical concept.  For example,
>     the git maintainer was off-line unexpectedly for some months recently.
>     Somebody else took over seamlessly by collecting, arranging and
>     coordinating patches on the git list into _his_ repository.
>
> With CVS, people can get the current version of every program on
> savannah in a uniform way.  What you say seems to imply that that is
> not possible with git.  That seems like a big step backwards.

A distributed VCS can be used just like CVS.  The fans of distributed
VCS systems like to talk about the many benefits of a distributed
system, but I don't know of a single major project that uses a dVCS
that doesn't have a canonical URL.  For example, if you wanted to
start hacking on git (assuming you had a copy of git installed
already) you could do:

git clone git://git.kernel.org/pub/scm/git/git.git/

If you wanted to hack on mercurial and you had a mercurial client
installed you would use this command:

hg clone http://selenic.com/hg/

All of the improvements to git (or mercurial) that are likely to
become part of a release eventually end up in the default branch in
much the same way that all of the improvements that are likely to end
up in a release of emacs get put into CVS.  The difference is that
dVCSes like git allow for a much more flexible workflow (especially
for people that spend a lot of time disconnected).

> Within a community of people that work together, it won't be a
> problem.  They will know to look THERE instead of HERE.  But users
> in general can't be expected to check for that sort of thing before
> they get the current development Emacs.

Folks that like distributed version control systems (and that includes
basically everyone that has tried one) like to point out that if
something happened to the canonical URL work could continue on without
it until things were sorted out.  That doesn't mean, however, that you
have to do without the canonical URL.  It simply means that you
*could* do without the canonical URL in a pinch.

If CVS is down, you are finished until things get sorted out.  With a
distributed system the failure of one branch isn't more than a minor
annoyance.

Re: What a modern collaboration toolkit looks like

[Richard Stallman]

    A distributed VCS can be used just like CVS.  The fans of distributed
    VCS systems like to talk about the many benefits of a distributed
    system, but I don't know of a single major project that uses a dVCS
    that doesn't have a canonical URL.  For example, if you wanted to
    start hacking on git (assuming you had a copy of git installed
    already) you could do:

    git clone git://git.kernel.org/pub/scm/git/git.git/

That is good.

Can you explain what that URL means?  Does the URL identify a specific
revision?  Or does the URL identify a repository?  If it identifies a
repository, how does git decide which revision to get?

Re: What a modern collaboration toolkit looks like

[Gregory Collins]

Richard Stallman <rms@gnu.org> writes:

> Can you explain what that URL means?  Does the URL identify a specific
> revision?  Or does the URL identify a repository?  If it identifies a
> repository, how does git decide which revision to get?

The URL identifies the repository. When you do a "pull", you obtain the
_set_ of all revisions that exist on the remote but don't exist in your
local tree (remember that in a distributed context every repository has
a complete history).

You can then fast-forward the state of your working directory to any of
those revisions (similar to "cvs update -r {foo}" but without a server
trip). This local update is astonishingly faster than a network update;
git in particular can update an entire source tree to a different
revision id so quickly that new users often wonder "did it just core
dump?"

G.

Re: What a modern collaboration toolkit looks like

[Richard Stallman]

    The URL identifies the repository. When you do a "pull", you obtain the
    _set_ of all revisions that exist on the remote but don't exist in your
    local tree (remember that in a distributed context every repository has
    a complete history).

What command do you use to get "the current development version"
sources out of that local copy of the repository?

Re: What a modern collaboration toolkit looks like

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>     The URL identifies the repository. When you do a "pull", you obtain the
>     _set_ of all revisions that exist on the remote but don't exist in your
>     local tree (remember that in a distributed context every repository has
>     a complete history).
>
> What command do you use to get "the current development version"
> sources out of that local copy of the repository?

[The following is about git]

When you originally create a working directory + local-repository (the
"local repository" is in the WD's ".git" subdirectory), you use the
"clone" command:

   git clone git://git.sv.gnu.org/emacs.git

The resulting working directory will contain "the current development
version"; in git that is called "master" branch.

You can subsequently use the "git pull" command to update that, getting
any changes from the remote repository:

    cd emacs
    git pull

Technically, what is happening when you give "git pull" above is that it:

  (1) Fetches updates to the "remote master branch"

  (2) Merges those updates into the "local master branch"; this merge is
  usually trivial but if there are conflicts, may require the user to
  resolve them.  The working directory will be updated in the process.

Giving "git push" essentially does the opposite -- transfers any updates
to the "local master branch" to the remote master branch.

"git commit" commits your W.D. changes to the "local master branch", 

-Miles

-- 
"Suppose we've chosen the wrong god. Every time we go to church we're
just making him madder and madder." -- Homer Simpson

Re: What a modern collaboration toolkit looks like

[Giorgos Keramidas]

On 2008-01-08 14:07, Richard Stallman <rms@gnu.org> wrote:
>     The URL identifies the repository. When you do a "pull", you obtain the
>     _set_ of all revisions that exist on the remote but don't exist in your
>     local tree (remember that in a distributed context every repository has
>     a complete history).
>
> What command do you use to get "the current development version"
> sources out of that local copy of the repository?

The current development version is identified by either a specific URL
(i.e. the unique location of an online repository st savannah) or by a
specific branch in this repository.

That is, the main "development version" of project $FOO may be:

    http://hg.savannah.gnu.org/sources/emacs/trunk

or the 'main' branch in this repository.

Given a local 'clone' of this branch, say in ~/work/emacs/trunk a user
can get the latest development version with:

    cd ~/work/emacs/trunk
    hg pull --update			; or 'hg pull -u'

This will perform both steps of (a) grabbing any changes of the remote
tree that we don't have and stashing them in the local repository
storage area, and (b) check out the latest version of the sources.

Re: What a modern collaboration toolkit looks like

[Richard Stallman]

    That is, the main "development version" of project $FOO may be:

	http://hg.savannah.gnu.org/sources/emacs/trunk

    or the 'main' branch in this repository.

    Given a local 'clone' of this branch, say in ~/work/emacs/trunk a user
    can get the latest development version with:

	cd ~/work/emacs/trunk
	hg pull --update			; or 'hg pull -u'

    This will perform both steps of (a) grabbing any changes of the remote
    tree that we don't have and stashing them in the local repository
    storage area, and (b) check out the latest version of the sources.


If I do a local commit, does that change the "latest version" in my
local repository?

If I do a pull from my local repository to the main one,
does that change the "latest version" in the shared repository?

Re: What a modern collaboration toolkit looks like

[Jason Earl]

Richard Stallman <rms@gnu.org> writes:

>     A distributed VCS can be used just like CVS.  The fans of
>     distributed VCS systems like to talk about the many benefits of
>     a distributed system, but I don't know of a single major project
>     that uses a dVCS that doesn't have a canonical URL.  For
>     example, if you wanted to start hacking on git (assuming you had
>     a copy of git installed already) you could do:
>
>     git clone git://git.kernel.org/pub/scm/git/git.git/
>
> That is good.
>
> Can you explain what that URL means?  Does the URL identify a
> specific revision?  Or does the URL identify a repository?  If it
> identifies a repository, how does git decide which revision to get?

The above command would create a copy of the entire git master
repository on your machine.  It holds all of the revisions that have
ever been pushed to that particular repository.  However, by default
it does the right thing and checks out the tip of the master branch
from that repository.  In other words, it is no more difficult to
follow the main trunk of the canonical repository with git than it is
with CVS.

The primary difference is that with a dVCS you can do quite a few
tricks that you can't do with CVS.

Jason

Re: What a modern collaboration toolkit looks like

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     "the current development version" is not a concept for git.  No
>     repository is special as far as git is concerned.  The "current
>     development version" is a social, not a technical concept.  For example,
>     the git maintainer was off-line unexpectedly for some months recently.
>     Somebody else took over seamlessly by collecting, arranging and
>     coordinating patches on the git list into _his_ repository.
>
> With CVS, people can get the current version of every program on
> savannah in a uniform way.  What you say seems to imply that that is
> not possible with git.  That seems like a big step backwards.

Huh?  Declare a repository as official, and people can sync to it and
"get the current version of every program on Savannah in a uniform way".
They can sync to any other repository (or pull changes on top of other
already pulled changes), too, without disturbing their setup.  But it is
not like they would magically get something they didn't ask for, or
would not always be able to tell what changes in addition to the
Savannah remote state they had applied in their own repository.

> Within a community of people that work together, it won't be a
> problem.  They will know to look THERE instead of HERE.  But users in
> general can't be expected to check for that sort of thing before they
> get the current development Emacs.

Huh?  I can get an rsync of Emacs CVS, check something into that copy
and publish it on a server.  Same thing.  A user can't usefully work
with two CVS repositories at once, sure, but the THERE/HERE confusion is
just the same.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: What a modern collaboration toolkit looks like

[Giorgos Keramidas]

On 2008-01-07 09:15, David Kastrup <dak@gnu.org> wrote:
>Richard Stallman <rms@gnu.org> writes:
>>     "the current development version" is not a concept for git.  No
>>     repository is special as far as git is concerned.  The "current
>>     development version" is a social, not a technical concept.  For example,
>>     the git maintainer was off-line unexpectedly for some months recently.
>>     Somebody else took over seamlessly by collecting, arranging and
>>     coordinating patches on the git list into _his_ repository.
>>
>> With CVS, people can get the current version of every program on
>> savannah in a uniform way.  What you say seems to imply that that is
>> not possible with git.  That seems like a big step backwards.
>
> Huh?  Declare a repository as official, and people can sync to it and
> "get the current version of every program on Savannah in a uniform way".
> They can sync to any other repository (or pull changes on top of other
> already pulled changes), too, without disturbing their setup.  But it is
> not like they would magically get something they didn't ask for, or
> would not always be able to tell what changes in addition to the
> Savannah remote state they had applied in their own repository.

I think there's a misunderstanding, but it's ok.

Richard, the main `new feature' of a DVCS is not that it changes
anything about the `central' repository.  It would still be possible to
name a well defined, well known place where the official Emacs source
tree lives.  Since savannah is a well known place for Emacs, that's
where the official tree should be, of course.

>> Within a community of people that work together, it won't be a
>> problem.  They will know to look THERE instead of HERE.  But users in
>> general can't be expected to check for that sort of thing before they
>> get the current development Emacs.
>
> Huh?  I can get an rsync of Emacs CVS, check something into that copy
> and publish it on a server.  Same thing.  A user can't usefully work
> with two CVS repositories at once, sure, but the THERE/HERE confusion is
> just the same.

... and this scratches the surface of the `new feature' of a DVCS.
There is still a `central' repository, which is well known and used for
the official releases.  But developers can *also* collaborate with each
other by directly exchanging changesets with each other.  They don't
have to specificlly go through a single CVS tree to do this.  They still
*can* go through the `central' repository for all their work, it's just
not mandatory.

- Giorgos

Re: What a modern collaboration toolkit looks like

[Stephen J. Turnbull]

Giorgos Keramidas writes:

 > ... and this scratches the surface of the `new feature' of a DVCS.
 > There is still a `central' repository, which is well known and used for
 > the official releases.

Technically, this is not true.  I know of several projects (the late
great Arch project, for one; SXEmacs, for another), where essentially
no pair of users who were building from source were working with the
same tree, let alone the same repository.  Official releases came from
the repository of whoever was the release manager du jour.  They were
defined by globally-valid "tags", not by repository.

The central repository is a social construct in a dVCS.  And the trunk
is a social construct in a dVCS.

However, for most projects, including Emacs, both social constructs
will emerge naturally, even automatically.  It is not something the
core Emacs stakeholders should worry about; in Emacs, it will take
care of itself.

Re: What a modern collaboration toolkit looks like

[Stephen J. Turnbull]

Richard Stallman writes:

 > I think that is a confusing way to compare them.
 > It focuses on similarities in implementation
 > rather than on similarities in use and role.

Exactly.  Let's try the use and role explanation.

Usage summary:

    cvs commit ~ git commit ; git push
    cvs update ~ git pull

Discussion:

In CVS, there normally is no local repository, and even if there were
one, CVS provides no mechanism for communication between the local
repository and the "official" one.  So to record your changes as a new
version *and* publish your changes, you simply commit:

                   you
  workspace --- cvs commit --> public repo
                               on server

To get others' changes, you pull:

                   you
  workspace <-- cvs update --- public repo
                               on server

In git (and all the others under discussion), to record your changes
as a new version, you commit, and then to publish your changes, you
push:

                   you                            you
  workspace --- git commit --> private repo --- git push --> public repo
                               on laptop                     on server

To get other's changes, you pull:

                                   you
  workspace <-- private repo <-- git pull --- public repo
                on laptop                     on server

Note that the update of the local workspace is implicit (automatically
done by "git pull").  For you personally, frequently disconnected but
(I assume) carrying a laptop, that's all you *need* to know, and
that's all you'll see of what's happening.

The omission of discussion of which branch or trunk etc is deliberate
and correct.  All VCSes have a notion of the "default branch".  All
you *need* to know is that the "default branch" of the "official
repository is the "trunk", and that the "usual way" of setting up a
local clone results in CVS-like behavior, except that to update the
trunk, you must first commit locally, then push to the official
repository.

This separation of commit from push is a huge advantage to those who
are often disconnected.

I should also mention that some dVCSes *require* that you explicitly
select the commits you wish to make.  For example, if you want git to
behave recursively the way "cvs commit" does, you need to say "git
commit -a".  However, the analog of "cvs commit file1 file2 ..." is
"git commit file1 file2 ...", so I would guess you won't find it hard
to acquire the habits.

There are many other advantages to these tools, but you can acquire
those skills at need.  You'll also *want* a deeper understanding of
the various operations before making a decision, I'm sure.  My purpose
here is merely to show how to map your current workflow into the
workflow you'd need to use with a dVCS to accomplish the same tasks.

Note that others can be doing all the wild-sounding things like "local
branching", "pulling from private repos", "cherrypicking", and
"rebasing", but you don't need to notice until it suits your purpose.

Finally, you probably already know this, but I should caution the
reader that words like "commit" and "push" alone do not necessarily
have the same meaning as "$VCS commit" and "$VCS push" do.  In fact,
the various VCSes differ quite a bit in usage, and often end up with a
set of commands implementing the same semantics but with the command
names permuted!  But those are fine points.  The basic roles of the
commands (at the eagle's eye view given above) remain intuitively
similar.

Re: What a modern collaboration toolkit looks like

[Richard Stallman]

    There are many other advantages to these tools, but you can acquire
    those skills at need.  You'll also *want* a deeper understanding of
    the various operations before making a decision, I'm sure.  My purpose
    here is merely to show how to map your current workflow into the
    workflow you'd need to use with a dVCS to accomplish the same tasks.

Thank you.  I'm willing in principle to switch to a DVCS, depending on
details.

I don't want to study them all myself, since I am busy.  And if a new
team of maintainers takes over, they may as well choose the VCS,
as long as I CAN use it.

Re: What a modern collaboration toolkit looks like

[Piet van Oostrum]

>>>>> Richard Stallman <rms@gnu.org> (RS) wrote:

>>> I don't think it makes sense to compare these two different "commit"
>>> operations -- it's like comparing an apple to an orange tree branch.
>>> If you compare applies with oranges instead, the difference is
>>> much less.

>RS>     I think that the comparison is quite accurate: the commit does
>RS>     everything that a commit in CVS does. The difference in workflow
>RS>     is not in committing, it is in the fact that everybody has his own
>RS>     repository (and all of them are equal).

>RS> I think that is a confusing way to compare them.
>RS> It focuses on similarities in implementation
>RS> rather than on similarities in use and role.

In both cases committing means that you make a permanent record of the
state of your workspace in the repository. The difference is that in CVS
there is a central repository whereas in a DVC system each user has its own
repository. In the latter case, if the developers want some central
repository they have to designate one of them as the authoritative one.
This is a social issue; AFAIK none of them has a provision to dedicate one
of the repositories as the authoritative one. If you want your commits to
migrate to the central repository you would do a push for that. So in a
certain sense the push could count as a global commit. But this is
certainly not the only possible workflow.
-- 
Piet van Oostrum <piet@cs.uu.nl>
URL: http://pietvanoostrum.com [PGP 8DAE142BE17999C4]
Private email: piet@vanoostrum.org

Re: What a modern collaboration toolkit looks like

[Nick Roberts]

 > > o - They must support "batch mode" working, for RMS and others who
 > >   concentrate fiercely on a single activity at a time.
 > 
 > git has such a batch mode, while CVS has none.  So for Richard, git
 > would be a much better choice than CVS since he could commit very
 > small units while being off-line.

More than that, I think you have a copy of the whole repository locally,
so you can look at logs, earlier revisions etc while off-line.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: What a modern collaboration toolkit looks like

[Richard Stallman]

    More than that, I think you have a copy of the whole repository locally,
    so you can look at logs, earlier revisions etc while off-line.

That sounds useful.

Re: What a modern collaboration toolkit looks like

[Eric S. Raymond]

Richard Stallman <rms@gnu.org>:
>     More than that, I think you have a copy of the whole repository locally,
>     so you can look at logs, earlier revisions etc while off-line.
> 
> That sounds useful.

It is.  All the 3Gs have this property.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: What a modern collaboration toolkit looks like

[David Kastrup]

"Eric S. Raymond" <esr@thyrsus.com> writes:

> Richard Stallman <rms@gnu.org>:
>>     More than that, I think you have a copy of the whole repository locally,
>>     so you can look at logs, earlier revisions etc while off-line.
>> 
>> That sounds useful.
>
> It is.  All the 3Gs have this property.

But I doubt all of them manage to squeeze all of Emacs' CVS history
(actually, more than that, since the Emacs' git repository also contains
the non-CVS multi-tty history AFAIK) into 200MB.

-- 
David Kastrup

Re: What a modern collaboration toolkit looks like

[Karl Fogel]

David Kastrup <dak@gnu.org> writes:
> But I doubt all of them manage to squeeze all of Emacs' CVS history
> (actually, more than that, since the Emacs' git repository also contains
> the non-CVS multi-tty history AFAIK) into 200MB.

Only ~280MB for a git clone, for what it's worth.  I used Romain
Francoise's git mirror of Emacs CVS to determine this:

   $ git clone git://git.sv.gnu.org/emacs.git
   Initialized empty Git repository in /home/kfogel/src/emacs/.git/
   remote: Generating pack...
   remote: 
   Done counting 451233 objects.
   remote: Deltifying 451233 objects...
   remote: 
   Indexing 451233 objects...
   remote: Total 451233 (delta 350726), reused 433746 (delta 336579)
    100% (451233/451233) done
   Resolving 350726 deltas...
    100% (350726/350726) done
   Checking 2778 files out...
    100% (2778/2778) done
   $ du -sh emacs
   282M	emacs
   $ 

-Karl

Re: What a modern collaboration toolkit looks like

[Andreas Schwab]

Karl Fogel <kfogel@red-bean.com> writes:

> David Kastrup <dak@gnu.org> writes:
>> But I doubt all of them manage to squeeze all of Emacs' CVS history
>> (actually, more than that, since the Emacs' git repository also contains
>> the non-CVS multi-tty history AFAIK) into 200MB.
>
> Only ~280MB for a git clone, for what it's worth.

That includes the checked out files, as it seems.  The raw repository is
about 220MB (although that is bigger than necessary, better packing can
reduce that to 182MB).

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: What a modern collaboration toolkit looks like

[Romain Francoise]

Karl Fogel <kfogel@red-bean.com> writes:

> I used Romain Francoise's git mirror of Emacs CVS [...]

Actually this service is run by Jim Meyering, I'm just a happy
user. :-)

Re: What a modern collaboration toolkit looks like

[Giorgos Keramidas]

On 2008-01-02 16:19, David Kastrup <dak@gnu.org> wrote:
>"Eric S. Raymond" <esr@thyrsus.com> writes:
>> Richard Stallman <rms@gnu.org>:
>>> More than that, I think you have a copy of the whole repository
>>> locally, so you can look at logs, earlier revisions etc while
>>> off-line.
>>>
>>> That sounds useful.
>>
>> It is.  All the 3Gs have this property.
>
> But I doubt all of them manage to squeeze all of Emacs' CVS history
> (actually, more than that, since the Emacs' git repository also contains
> the non-CVS multi-tty history AFAIK) into 200MB.

I have a locally converted `HEAD' from CVS -> Mercurial which contains
all the history of the Emacs trunk, and is now at 138 MB:

  keramida@kobe:/home/keramida/hg/emacs/head$ du -skh .hg
  138M    .hg
  keramida@kobe:/home/keramida/hg/emacs/head$

This repository doesn't contain *all* the branches which have ever
existed for Emacs, but a pair of branches won't really bloat the history
above 200 MB easily.

Both Git and Mercurial are trying hard to store large histories in an
efficient manner.  They make different trade-offs, so some things will
invariably end up different, but there is a lot of cross-pollination
between the two systems, and that's usually a good thing :)

HTH,
Giorgos

Re: What a modern collaboration toolkit looks like

[David Kastrup]

Giorgos Keramidas <keramida@ceid.upatras.gr> writes:

> On 2008-01-02 16:19, David Kastrup <dak@gnu.org> wrote:
>
>> But I doubt all of them manage to squeeze all of Emacs' CVS history
>> (actually, more than that, since the Emacs' git repository also contains
>> the non-CVS multi-tty history AFAIK) into 200MB.
>
> I have a locally converted `HEAD' from CVS -> Mercurial which contains
> all the history of the Emacs trunk, and is now at 138 MB:
>
>   keramida@kobe:/home/keramida/hg/emacs/head$ du -skh .hg
>   138M    .hg
>   keramida@kobe:/home/keramida/hg/emacs/head$
>
> This repository doesn't contain *all* the branches which have ever
> existed for Emacs, but a pair of branches won't really bloat the history
> above 200 MB easily.

Well, some of the branches have significant independent work and a
looooong history in them.  Nevertheless, the usage would appear in the
same ballpark here.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: What a modern collaboration toolkit looks like

[Richard Stallman]

Would ONE of you please email me git intro documentation?
(Please check and see if someone else has already said he
has done so, before sending it again.)

Re: What a modern collaboration toolkit looks like

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> Would ONE of you please email me git intro documentation?
> (Please check and see if someone else has already said he
> has done so, before sending it again.)

I'll be doing so.

-- 
David Kastrup

Re: What a modern collaboration toolkit looks like

[Tassilo Horn]

Richard Stallman <rms@gnu.org> writes:

> Would ONE of you please email me git intro documentation?
> (Please check and see if someone else has already said he
> has done so, before sending it again.)

I'll do so now.

Bye,
Tassilo

Re: What a modern collaboration toolkit looks like

[Alan Mackenzie]

Hi, Tassilo!

On Wed, Jan 02, 2008 at 11:05:27AM +0100, Tassilo Horn wrote:
> Richard Stallman <rms@gnu.org> writes:

> > Would ONE of you please email me git intro documentation?  (Please
> > check and see if someone else has already said he has done so,
> > before sending it again.)

> I'll do so now.

Could you post the URL too, please?

Thanks!

> Tassilo

-- 
Alan Mackenzie (Nuremberg, Germany)

Re: What a modern collaboration toolkit looks like

[Tassilo Horn]

Alan Mackenzie <acm@muc.de> writes:

Hi Alan,

>> > Would ONE of you please email me git intro documentation?  (Please
>> > check and see if someone else has already said he has done so,
>> > before sending it again.)
>
>> I'll do so now.
>
> Could you post the URL too, please?

Sure.

  http://git.or.cz/#documentation

Or to get directly to the tutorial

  http://www.kernel.org/pub/software/scm/git/docs/tutorial.html

Bye,
Tassilo

Re: What a modern collaboration toolkit looks like

[Óscar Fuentes]

Richard Stallman <rms@gnu.org> writes:

> Would ONE of you please email me git intro documentation?
> (Please check and see if someone else has already said he
> has done so, before sending it again.)

Please do not focus too much on git. AFAIK it is not the most easy to
use decentralized VCS and its support for non-*nix systems is weak.

I'll suggest you use Mercurial for learning what a decentralized VCS can
do. The basic idea is the same for all dVCS's. Of course the interface
and implementation trade-offs varies among them.

Mercurial:

http://www.selenic.com/mercurial/wiki/

Focus on UnderstandingMercurial and the Tutorial. CvsInfo may be useful
too.

Bazaar is another dVCS. On its website there are some articles
interesting articles:

http://bazaar-vcs.org/Articles

-- 
Oscar

Re: What a modern collaboration toolkit looks like

[Karl Fogel]

Óscar Fuentes <ofv@wanadoo.es> writes:
> Please do not focus too much on git. AFAIK it is not the most easy to
> use decentralized VCS and its support for non-*nix systems is weak.
>
> I'll suggest you use Mercurial for learning what a decentralized VCS can
> do. The basic idea is the same for all dVCS's. Of course the interface
> and implementation trade-offs varies among them.
>
> [...]

I'd been staying out of this thread, mostly because it's going in a
direction I like anyway :-).  But I too would love to see Emacs switch
to a dVCS like Mercurial or git.  

The dVCS model would fit Emacs development very well, and it would be
especially good for Richard, once he learns the new ropes, because of
the tremendous offline capability.  (Disclaimer: I'm a Subversion
developer, and like Subversion, but it's not the best hammer for every
nail.)

Regarding storage issues:

David Kastrup <dak@gnu.org> wrote:
> But I doubt all of them manage to squeeze all of Emacs' CVS history
> (actually, more than that, since the Emacs' git repository also contains
> the non-CVS multi-tty history AFAIK) into 200MB.

Maybe not 200MB, but still probably less than 400MB; possibly far
less.  dVCS repositories are surprisingly small for all that history
("surprising" to those who aren't used to how they do their storage,
anyway).

I tried to do a test conversion of the Emacs CVS repository, but don't
see a way to get a full repository tarball from Savannah.  If someone
can hand me one, I'll do a test conversion and report back.

-Karl

Re: What a modern collaboration toolkit looks like

[Andreas Schwab]

Karl Fogel <kfogel@red-bean.com> writes:

> I tried to do a test conversion of the Emacs CVS repository, but don't
> see a way to get a full repository tarball from Savannah.

You can rsync it (use rsync://cvs.sv.gnu.org for a list of modules).

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: What a modern collaboration toolkit looks like

[Alfred M. Szmidt]

   I tried to do a test conversion of the Emacs CVS repository, but don't
   see a way to get a full repository tarball from Savannah.  If someone
   can hand me one, I'll do a test conversion and report back.

| rsync -av cvs.gnu.org::sources/emacs .

Someone already noted that there was already a git repository of Emacs
on savannah:

| git clone git://git.sv.gnu.org/emacs.git

Re: What a modern collaboration toolkit looks like

[Karl Fogel]

"Alfred M. Szmidt" <ams@gnu.org> writes:
>    I tried to do a test conversion of the Emacs CVS repository, but don't
>    see a way to get a full repository tarball from Savannah.  If someone
>    can hand me one, I'll do a test conversion and report back.
>
> | rsync -av cvs.gnu.org::sources/emacs .
>
> Someone already noted that there was already a git repository of Emacs
> on savannah:
>
> | git clone git://git.sv.gnu.org/emacs.git

Oh, I already followed up in the original thread with the answer.
Here it is:

> David Kastrup <dak@gnu.org> writes:
> > But I doubt all of them manage to squeeze all of Emacs' CVS history
> > (actually, more than that, since the Emacs' git repository also contains
> > the non-CVS multi-tty history AFAIK) into 200MB.
> 
> Only ~280MB for a git clone, for what it's worth.  I used Romain
> Francoise's [correct: Jim Meyering's] git mirror of Emacs CVS to
> determine this:
> 
>    $ git clone git://git.sv.gnu.org/emacs.git
>    Initialized empty Git repository in /home/kfogel/src/emacs/.git/
>    remote: Generating pack...
>    remote: 
>    Done counting 451233 objects.
>    remote: Deltifying 451233 objects...
>    remote: 
>    Indexing 451233 objects...
>    remote: Total 451233 (delta 350726), reused 433746 (delta 336579)
>     100% (451233/451233) done
>    Resolving 350726 deltas...
>     100% (350726/350726) done
>    Checking 2778 files out...
>     100% (2778/2778) done
>    $ du -sh emacs
>    282M	emacs
>    $ 

-Karl

Re: What a modern collaboration toolkit looks like

[Giorgos Keramidas]

On 2008-01-02 11:48, Karl Fogel <kfogel@red-bean.com> wrote:
> I tried to do a test conversion of the Emacs CVS repository, but don't
> see a way to get a full repository tarball from Savannah.  If someone
> can hand me one, I'll do a test conversion and report back.

I use the following script to rsync the repository now and then:

  #!/bin/sh
  #
  # Mirror the CVS repository of Emacs.  Information about rsync and
  # the rsync incantation to mirror the repo, obtained from:
  #
  # Ken Raeburn, raeburn at raeburn.org
  # Message-Id: <FC340194-0902-4349-8AC8-8E5F4E891DD4@raeburn.org>
  # on emacs-devel
  #

  rsync   --delete --force --recursive \
          --links --safe-links --hard-links --times \
          --compress --progress -vv --stats \
          cvs.savannah.gnu.org::sources/emacs/ /home/emacs/

Many belated thanks to Ken Raeburn, who initially pointed me at this
method of obtaining a local CVS repository :)

Re: What a modern collaboration toolkit looks like

[Andreas Schwab]

Giorgos Keramidas <keramida@ceid.upatras.gr> writes:

>   rsync   --delete --force --recursive \
>           --links --safe-links --hard-links --times \
>           --compress --progress -vv --stats \
>           cvs.savannah.gnu.org::sources/emacs/ /home/emacs/

Don't use --hard-links, it is expensive and a CVS repository should
never contain hard links.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: What a modern collaboration toolkit looks like

[Giorgos Keramidas]

On 2008-01-03 10:14, Andreas Schwab <schwab@suse.de> wrote:
> Giorgos Keramidas <keramida@ceid.upatras.gr> writes:
> >   rsync   --delete --force --recursive \
> >           --links --safe-links --hard-links --times \
> >           --compress --progress -vv --stats \
> >           cvs.savannah.gnu.org::sources/emacs/ /home/emacs/
> 
> Don't use --hard-links, it is expensive and a CVS repository should
> never contain hard links.

Thanks, I've updated the local script :)

Re: What a modern collaboration toolkit looks like

[Eric S. Raymond]

Alan Mackenzie <acm@muc.de>:
> A few suggestions:
> o - Emacs is implemented in a wierd special purpose language.

Right.  And how many hundreds of thousands of users do we have
teaching themselves beginning elisp by doing small local
customizations to their .emacs files?  No, that won't hold water.
 
> o - Emacs is already so good that it's difficult to see room for new
>   features.  

I had to rewrite VC-mode recently because it couldn't drive modern VCSes.
When I did so I discovered that several key functions had been hacked
into a state of severe mal-design.  No, "Emacs is too good" won't 
work either.

> o - Much core Emacs code has, despite RMS's good sense and emphasis on
>   simplicity, become tortuous and difficult to get into.

There is probably something to this.

> o - Emacs is a victim of its own success - as its new features make it
>   steadily easier to use, it becomes steadily more intricate and thus
>   harder to learn.  A non-user of Emacs cannot become an Emacs hacker.

And to this.  Though why it's a problem that non-Emacs-users can't hack Emacs
when we have so many users, I don't see.

But while your last two problems contribute to the mess we're in, they're
not sufficient to explain it.

> I'd think it's worth emphasising that CVS is _NOT_ a poor tool; it's an
> exceptionally flexible, solid and reliable one, free from feature bloat,
> and I'm grateful indeed to the hackers who've maintained it over the
> decades.

Clearly you've never used a decently-designed VCS.  Do you have any idea
of the kind of horrible shite CVS can land you in if you try something
as basic as renaming a file?  

I'm gathering not, and you should perhaps be grateful for your
ignorance.  It's not just that the operation isn't supported, it's
that the crocky workarounds recommended in the CVS manual are highly
likely to corrupt your repo.

CVS's key hackers abandoned it to start the Subversion project in 2000
because they had concluded CVS was unsalvageably bad.  I've studied
how CVS works internally for a survey paper on VCSes I'm doing, and --
believe me -- they were right to do so.

> o - They must support "batch mode" working, for RMS and others who
>   concentrate fiercely on a single activity at a time.

This problem doesn't have any technical solution.  What you appear to
be thinking of as "batch mode" (disappear into a cave for months at a
time) is not compatible with the communications practices we need to
move to in order to make the Emacs project agile and responsive again.
In particular, it's incompatible with engaging our users in real-time
via IRC and other messaging channels.

There's still a role for people with a "batch mode" working style, but 
it's more in the background working on large semi-detached projects.
Project leads have to face the world.

> o - They must, like Emacs, be fully usable on a text console without a
>   mouse as well as in X.  There are at least 3 hackers here who prefer
>   such a setup.

This *does* have a technical solution: lynx.  Or links.  Text-mode
browsers aren't what I'd call pleasant compared to graphical ones, but
they are usable.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: What a modern collaboration toolkit looks like

[Alan Mackenzie]

Hi, Eric!

On Tue, Jan 01, 2008 at 02:37:32PM -0500, Eric S. Raymond wrote:
> Alan Mackenzie <acm@muc.de>:
> > A few suggestions:

[ .... ]

> > o - Emacs is already so good that it's difficult to see room for new
> > features.  

> I had to rewrite VC-mode recently because it couldn't drive modern
> VCSes.  When I did so I discovered that several key functions had been
> hacked into a state of severe mal-design.  No, "Emacs is too good"
> won't work either.

I'm trying to look at things from the point of view of an outsider.  Yes,
there's LOTS of laborious maintenance to be done, but the newbie doesn't
see this (due to the immense amount of testing in the immensely long
release cycle).  Emacs DOES need new features (refactoring, better
browsing, etc.), but those are rarely obvious to the new people we need.

[ .... ]

> > o - Emacs is a victim of its own success - as its new features make it
> >   steadily easier to use, it becomes steadily more intricate and thus
> >   harder to learn.  A non-user of Emacs cannot become an Emacs hacker.

> And to this.  Though why it's a problem that non-Emacs-users can't hack Emacs
> when we have so many users, I don't see.

It's more of a long term problem, in that the number of Emacs users might
be gradually declining.  I'm only guessing here though, I don't know.

> But while your last two problems contribute to the mess we're in, they're
> not sufficient to explain it.

Er, I never meant them to be.  I was throwing around some ideas for
discussion.

> > I'd think it's worth emphasising that CVS is _NOT_ a poor tool; it's
> > an exceptionally flexible, solid and reliable one, free from feature
> > bloat, and I'm grateful indeed to the hackers who've maintained it
> > over the decades.

> Clearly you've never used a decently-designed VCS.  Do you have any
> idea of the kind of horrible shite CVS can land you in if you try
> something as basic as renaming a file?  

Yes.

> I'm gathering not, and you should perhaps be grateful for your
> ignorance.  It's not just that the operation isn't supported, it's
> that the crocky workarounds recommended in the CVS manual are highly
> likely to corrupt your repo.

HEY, THAT'S NOT FAIR!!!!  You've distorted my post by selective deletion.
When I said CVS was good, I qualified clearly what I meant by reference
to hammers, nails and screws.  The steam engine was a wonderful invention
too, but no modern railway system would now deploy one as prime choice of
traction.

And no, I don't think I ever have used a good VCS, and you and one or two
others have just made me aware that I'm missing something worthwhile.
Cut me some slack, please.

[ .... ]

> > o - They must support "batch mode" working, for RMS and others who
> >   concentrate fiercely on a single activity at a time.

> This problem doesn't have any technical solution.  What you appear to
> be thinking of as "batch mode" (disappear into a cave for months at a
> time) is not compatible with the communications practices we need to
> move to in order to make the Emacs project agile and responsive again.
> In particular, it's incompatible with engaging our users in real-time
> via IRC and other messaging channels.

> There's still a role for people with a "batch mode" working style, but 
> it's more in the background working on large semi-detached projects.
> Project leads have to face the world.

OK, here's where you need to persuade me (?us).  There have been lots of
bugs in CC Mode where I've had to dig myself in without distractions for
hours at a time, sometimes days, to resolve; bits of Emacs are like that
- some hackers are like this.  I've been able to emerge and engage in the
mailing list.  I don't think I could do this with a rapid-fire IRC
instead of email.  Richard has said he couldn't spare the time for this
style of hacking.  I believe him.

It seems that there will be losses as well as gains from moving to IIRC.
How convinced are you that the gains will outweigh the losses?  Is there
perhaps a third way which combines the good bits and minimises the bad
bits of the other two?

> > o - They must, like Emacs, be fully usable on a text console without a
> >   mouse as well as in X.  There are at least 3 hackers here who prefer
> >   such a setup.

> This *does* have a technical solution: lynx.  Or links.  Text-mode
> browsers aren't what I'd call pleasant compared to graphical ones, but
> they are usable.

A web browser is for browsing the web, and is pretty cruddy for anything
else.  For email you'd use mutt, for documentation C-h i, for usenet tin
or slrn, and so on.  Surely there's a purpose built tty client for IRC.

> 		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: What a modern collaboration toolkit looks like

[Eric S. Raymond]

Alan Mackenzie <acm@muc.de>:
>                    Emacs DOES need new features (refactoring, better
> browsing, etc.), but those are rarely obvious to the new people we need.

I think more direct interaction between the users and the developer community
might help with this. On the Wesnoth project, most of our new devs are 
people who have been lurking on #wesnoth-dev for a while before they
send their first patch.  So they've been listening to the developers
talk among themselves about what needs done.

A public bugtracker will help here, too.  Another common entry path is
for someone who might want to get more involved to pick a feature
request, do it, and send a patch to the dev list.

> It's more of a long term problem, in that the number of Emacs users might
> be gradually declining.  I'm only guessing here though, I don't know.

I have no data on this, just an uneasy gut feeling.
 
> HEY, THAT'S NOT FAIR!!!!  You've distorted my post by selective deletion.
> When I said CVS was good, I qualified clearly what I meant by reference
> to hammers, nails and screws.

Er....I was not the only person to read your note as fairly unqualified
praise of CVS.  But never mind.

> OK, here's where you need to persuade me (?us).  There have been lots of
> bugs in CC Mode where I've had to dig myself in without distractions for
> hours at a time, sometimes days, to resolve; bits of Emacs are like that
> - some hackers are like this.  I've been able to emerge and engage in the
> mailing list.  I don't think I could do this with a rapid-fire IRC
> instead of email.  Richard has said he couldn't spare the time for this
> style of hacking.  I believe him.

I don't experience any difficulty digging in like this.  When you need to,
you tell your IRC client "/away" and it announces to the channel that you
are away from keyboard.  When you're ready to surface, skim the IRC scroll
buffer and type "/back".

If your experience is like mine, you'll find you start being able to
glance at the chatter occasionally without breaking your flow, the
same way you can sort of half-consciously monitor quiet speech around
you without breaking conversation until you hear something that tells
you you need to pay attention.

> A web browser is for browsing the web, and is pretty cruddy for anything
> else.  For email you'd use mutt, for documentation C-h i, for usenet tin
> or slrn, and so on.  Surely there's a purpose built tty client for IRC.

Oh, yes, sure. Boatloads of them.  ircii is one of the best known.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: What a modern collaboration toolkit looks like

[Mark A. Hershberger]

"Eric S. Raymond" <esr@thyrsus.com> writes:

>> It's more of a long term problem, in that the number of Emacs users might
>> be gradually declining.  I'm only guessing here though, I don't know.
>
> I have no data on this, just an uneasy gut feeling.

http://google.com/trends?q=emacs

The above chart shows that searches for the term “emacs” have been
declining over the past 3 years.  I suspect part of this is due to the
growth of IDEs like Eclipse.

This isn't proof that use of Emacs is declining, of course.  But it does
indicate that people might not be as interested to learn about it as
they were in the past.

(If you add “vim” to the chart, you can see that queries for it have
stayed more constant. The term “vi” does not have as clear a meaning —
most of the hits are for the sixth version of something.)

-- 
http://hexmode.com/
GPG Fingerprint: 7E15 362D A32C DFAB E4D2  B37A 735E F10A 2DFC BFF5

My happiness grows in direct proportion to my acceptance, and in
inverse proportion to my expectations.  -- Michael J. Fox

Re: What a modern collaboration toolkit looks like

[Richard Stallman]

    If your experience is like mine, you'll find you start being able to
    glance at the chatter occasionally without breaking your flow, the
    same way you can sort of half-consciously monitor quiet speech around
    you without breaking conversation until you hear something that tells
    you you need to pay attention.

My brain doesn't work like that.

Re: What a modern collaboration toolkit looks like

[Tassilo Horn]

Alan Mackenzie <acm@muc.de> writes:

Hi Alan,

>> > o - They must, like Emacs, be fully usable on a text console
>> > without a mouse as well as in X.  There are at least 3 hackers here
>> > who prefer such a setup.
>
>> This *does* have a technical solution: lynx.  Or links.  Text-mode
>> browsers aren't what I'd call pleasant compared to graphical ones,
>> but they are usable.

emacs-w3m is quite good.  I already used it to file some bug reports at
the kde and gentoo bugzillas.

> A web browser is for browsing the web, and is pretty cruddy for
> anything else.  For email you'd use mutt, for documentation C-h i, for
> usenet tin or slrn, and so on.  Surely there's a purpose built tty
> client for IRC.

You can do all of those jobs in a stock emacs:

  - Mail: Gnus, VM, rmail
  - News: Gnus
  - Web: emacs-w3m (ok, that's not stock...)
  - IRC: ERC, rcirc

Bye,
Tassilo

Re: What a modern collaboration toolkit looks like

[John S. Yates, Jr.]

On Tue, 1 Jan 2008 14:37:32 -0500, esr wrote:

> Do you have any idea of the kind of horrible shite CVS can
> land you in if you try something as basic as renaming a file?

Speaking from experience on multiple projects, a pernicious CVS
effect is to install a reluctance to rename.  This is tantamount
to banning any large scale refactoring.  And that is ultimately
extremely damaging to a long-lived code base under truly active
development.

/john

Re: What a modern collaboration toolkit looks like

[Eric S. Raymond]

John S. Yates, Jr. <john@yates-sheets.org>:
> Speaking from experience on multiple projects, a pernicious CVS
> effect is to install a reluctance to rename.  This is tantamount
> to banning any large scale refactoring.  And that is ultimately
> extremely damaging to a long-lived code base under truly active
> development.

Emphatically agreed.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: What a modern collaboration toolkit looks like

[Richard Stallman]

    Speaking from experience on multiple projects, a pernicious CVS
    effect is to install a reluctance to rename.  This is tantamount
    to banning any large scale refactoring.  And that is ultimately
    extremely damaging to a long-lived code base under truly active
    development.

I agree that this is a drawback of CVS, but in Emacs we have
not let it stop us from moving files around.  We've done
substantial amounts of that recently.

Re: What a modern collaboration toolkit looks like

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Jan 01, 2008 at 02:37:32PM -0500, Eric S. Raymond wrote:

[...]

> > o - They must, like Emacs, be fully usable on a text console without a
> >   mouse as well as in X.  There are at least 3 hackers here who prefer
> >   such a setup.
> 
> This *does* have a technical solution: lynx.  Or links.  Text-mode
> browsers aren't what I'd call pleasant compared to graphical ones, but
> they are usable.

I have to take issue with this last one. Whereas I'm far from 'console
bigot' (I do enjoy Emacs on X far more than on console), I cringe when I
have to use those badly done, Javascript and cookie-laden Web-2.0
interfaces. Trac -- ackphth.

GUI != browser.  And I think we'd be better off separating all those
layers and picking whatever suits us. Why not http without html? Or html
without Javascript? Texinfo-over-http anyone?

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFHe1CBBcgs9XrR2kYRAv7eAJ4yVuwhJHcnrufo5DUHrMg6X+mKeQCdFt5F
V5wPIU6NVEg0xSaRr16uu0I=
=cFNy
-----END PGP SIGNATURE-----

Re: What a modern collaboration toolkit looks like

[Richard Stallman]

    There's still a role for people with a "batch mode" working style, but 
    it's more in the background working on large semi-detached projects.
    Project leads have to face the world.

I will not choose future Emacs maintainers based on their willingness
to work in that particular way.  Any future Emacs maintainers, will
choose the tools that fit their styles and their lives, just as I
choose the ones that fit mine.

It is fine to suggest tools for use to use, but don't go beyond
suggesting.  You must take no for an answer when that is the answer
you get.

Re: What a modern collaboration toolkit looks like

[Romain Francoise]

Alan Mackenzie <acm@muc.de> writes:

> I'd think it's worth emphasising that CVS is _NOT_ a poor tool [...]

Your clock is off, today's January 1st, not April 1st.

Re: What a modern collaboration toolkit looks like

[Alan Mackenzie]

Happy New Year, Eric and Emacs!

On Sun, Dec 30, 2007 at 07:22:17AM -0500, Eric S. Raymond wrote:

> ...., I think it will be useful if I start by giving everybody a clear
> idea of the potential benefits of changing our practices.

> I'm going to describe the collaboration toolkit on another project
> where I happen to be a senior dev, called Battle For Wesnoth.  You can
> find the project at <http://www.wesnoth.org/>.

> This is a typical modern open-source project.

Emacs is an atypical, very old, piece of free software.  Wesnoth seems to
be about 5 years old.  (I haven't found the repository online.)  This has
some bearing on the differences in development processes.

> .... Here are the collaborative tools we use every day:

> * Source control with Subversion
> * A bug tracker
> * A very active IRC channel used for routine dev chatter
> * A dev mailing list, used mostly for white papers and long proposals
> * Web forums where a large user community hangs out
> * Subversion commits are echoed to IRC in real time by a monitor bot
> * Subversion commits that reference a bug append a comment to the tracker
> * A bot on IRC that you can query with a bug number and get a tracker URL.

> Here are some of the ways my workflow on Wesnoth differs from my
> workflow on Emacs:

> 1. When I do a commit of changes to several files, the entire changeset
> is saved as a unit with a single change comment attached to it.  

I would appreciate having this in Emacs.

> a) That change can be referenced, through its Subversion revision ID.  
>    (So, for example, "Hey boucman, your r22615 broke linger mode!")

Hopefully, people are considerate enough not to do this too often;
continually having to look somewhere else to get context is not nice.

> b) That change can be backed out as a unit.

That's fine if nearly all changes are independent.  In Emacs, I think,
this is not the case.  The codebase is extremely old, and clean
structuring has in many cases been lost.  (But, hey, for >20 y.o. code,
it's not bad).

Such easy backing out could lead to problems.

[ .... ]

> 2. My commit is also echoed to the IRC channel, where there are almost
> never fewer than three or four devs hanging out as they hack, chatting
> in real time.  Review tends to happen instantly.

What about fixes that are too big for instant review?  Emacs has lots of
bugs (and often fixes ;-) that are barely tractable, so that the slower
pace of email seems a better fit.

[ .... ]

> The effect of all these tools is more than the sum of its parts.

> One huge one is simply that devs can choose to spend time picking bugs
> off the tracker and nailing them, with basically zero process friction.

> Another is that we routinely hash out serious design and coding issues
> in real time, because everyone on the chat channel can share hyperlinks
> to the codebase, the commit history, the bug tracker, and posts
> on the user forums.

I've no experience of IIRC.  But doesn't this way of working mean
continually dancing from one thing to another?  I don't do that very
well.  The "hyperlinks" bit sounds like you have to look at 3 or 4 things
simultaneously to be able to synthesise a context.  How does this working
style work for difficult problems?

> Yet a third is that when we decide to do it, we can converge on a
> releasable state with almost absurd ease.  Like, Ivanovic (our release
> manager) will announce "Point release scheduled this coming Wednesday"
> and everyone will pretty much flip into bug-stomping mode.  The tracker
> bug list tends to shrink dramatically when this happens -- not only do
> we get prepared for release but *we know we've done so*.

Eric, how well do you think this could work at all for Emacs?

> More generally, development happens *fast*.  I don't have to wait weeks
> to find out whether other devs think of an idea.  Commonly I know
> within minutes.

On emacs-devel, this takes hours, not weeks.  At any given time, most
Emacs developers are either asleep or doing other things (like earning
their living).  Doesn't this quick-fire style end up excluding lots of
hackers from participation?

> The Wesnoth devs are good but not exceptionally so, and we're weighed
> down by a crappy implementation language (C++).

Yuck!!

> Nevertheless our productivity, in terms of goals achieved per hour of
> work, is quite high.  That's because our collaboration tools support
> everything we do without imposing noticeable process friction.  This
> makes us dramatically more effective as individuals and as a group than
> we could possibly be without them.

Might it also be because your code base is still young, clean and
flexible?

> Lessons for the Emacs project?  Hell, yes.  But I'm not going to write
> that rant until y'all have had a little time to absorb this description
> of how things can be.

I'll look forward to that!  We'd all welcome a process for releasing
every few months rather than twice a decade.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: What a modern collaboration toolkit looks like

[Miles Bader]

Alan Mackenzie <acm@muc.de> writes:
>> Yet a third is that when we decide to do it, we can converge on a
>> releasable state with almost absurd ease.  Like, Ivanovic (our release
>> manager) will announce "Point release scheduled this coming Wednesday"
>> and everyone will pretty much flip into bug-stomping mode.  The tracker
>> bug list tends to shrink dramatically when this happens -- not only do
>> we get prepared for release but *we know we've done so*.
>
> Eric, how well do you think this could work at all for Emacs?

I suspect that 90% of the difference in "responsiveness" between the two
projects has to do with the people (and numbers of people) involved, not
with the tools being used.

Emacs has a rather small developer base, and most of the developers are
fairly busy with other things.  A project with lots of developers that
are more intensely involved in development is naturally going to be more
reponsive.

Certainly the tools make _some_ difference, but I think ESR is
drastically overestimating how much of one.  If Emacs development were
at a faster pace (perhaps because the developer base change), then maybe
the tools would become a limiting factor, but I don't think they are now.

[BTW, one thing I think _would_ be very handy, and easy to implement,
would be an IRC channel for Emacs developers, just for those random
questions you wanna get a quick answer to sometimes... There's #emacs on
irc.freenode.net, but it's more user-level.]

-Miles

-- 
"Suppose we've chosen the wrong god. Every time we go to church we're
just making him madder and madder." -- Homer Simpson

Re: What a modern collaboration toolkit looks like

[Alan Mackenzie]

Hi, Miles!

On Mon, Dec 31, 2007 at 10:24:25PM +0900, Miles Bader wrote:
> Alan Mackenzie <acm@muc.de> writes:
> >> Yet a third is that when we decide to do it, we can converge on a
> >> releasable state with almost absurd ease.  Like, Ivanovic (our
> >> release manager) will announce "Point release scheduled this coming
> >> Wednesday" and everyone will pretty much flip into bug-stomping
> >> mode.  The tracker bug list tends to shrink dramatically when this
> >> happens -- not only do we get prepared for release but *we know
> >> we've done so*.

> > Eric, how well do you think this could work at all for Emacs?

> I suspect that 90% of the difference in "responsiveness" between the
> two projects has to do with the people (and numbers of people)
> involved, not with the tools being used.

What about the code base?

> Emacs has a rather small developer base, and most of the developers
> are fairly busy with other things.  A project with lots of developers
> that are more intensely involved in development is naturally going to
> be more reponsive.

> Certainly the tools make _some_ difference, but I think ESR is
> drastically overestimating how much of one.  If Emacs development were
> at a faster pace (perhaps because the developer base change), then
> maybe the tools would become a limiting factor, but I don't think they
> are now.

My feeling is that better tools would make a substantial difference -
perhaps 25% better productivity for me - but nothing like an order of
magnitude.

Miles, why aren't we all switching to arch?  Would it be appropriate for
Emacs now?

> [BTW, one thing I think _would_ be very handy, and easy to implement,
> would be an IRC channel for Emacs developers, just for those random
> questions you wanna get a quick answer to sometimes... There's #emacs
> on irc.freenode.net, but it's more user-level.]

Would anybody be listening?

> -Miles

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: What a modern collaboration toolkit looks like

[Eric S. Raymond]

Alan Mackenzie <acm@muc.de>:
> My feeling is that better tools would make a substantial difference -
> perhaps 25% better productivity for me - but nothing like an order of
> magnitude.

This one is hard for me to evaluate, because Wesnoth is my only C++ 
project -- more usually I work in Python and C, and my stuff here is Lisp
(I was active in the Emacs C core once, but that was long ago).  

That said, I think your 25% guess is about right as far as lines of
code goes.  But that wouldn't measure the whole gain -- because with
better tools, my coding effort is quite a bit more likely to be
directed appropriately.

(This is the particular reason bug trackers are really important.)

> Miles, why aren't we all switching to arch?  Would it be appropriate for
> Emacs now?

Please not Arch.  I just learned it; brilliant ideas, but its
interface should be be outlawed under the Geneva convention as a form
of torture.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: What a modern collaboration toolkit looks like

[Juanma Barranquero]

On Dec 31, 2007 2:24 PM, Miles Bader <miles@gnu.org> wrote:

> Emacs has a rather small developer base, and most of the developers are
> fairly busy with other things.  A project with lots of developers that
> are more intensely involved in development is naturally going to be more
> reponsive.

I don't think there's anything in Emacs that makes its developers
inherently more "busy with other things", other than, perhaps, age.
And then we go back to Eric's points about the Emacs' project
(relative) inability to attract young developers.

> Certainly the tools make _some_ difference, but I think ESR is
> drastically overestimating how much of one.

I think Eric is perhaps overestimating, but OTOH many comments in this
thread seem a bit underestimating to me. The truth is, we don't have a
crystal ball, and neither does Eric; we won't know unless/until we try
it. But he's right that other big projects seem to be doing better,
from a responsiveness POV. Now, every time that issue has been brought
to discussion, the answers have centered about Emacs having few
developers... So back to the previous point.

> [BTW, one thing I think _would_ be very handy, and easy to implement,
> would be an IRC channel for Emacs developers, just for those random
> questions you wanna get a quick answer to sometimes... There's #emacs on
> irc.freenode.net, but it's more user-level.]

Which goes to show how different people's priorities are. IRC would be
to me the less interesting of Eric's proposals. But I know there are
projects (Subversion, for example) which make use of it with good
results.

In case I'm not making myself clear, which is likely: I agree with
most of what Eric has said in this thread. Even if we cannot now
estimate whether switching tools would be a 5% or a 500% gain in
productivity, there's the almost certainly that there would be a gain,
and Emacs would make a step towards attracting more people. No, I
don't have the numbers to back up that; it's a hunch, like most
everything else said in this thread. But the simple fact that the
discussion about bug tracking software, alternatives to CVS, etc.
springs regularly in this list it's itself significant.

             Juanma

Re: What a modern collaboration toolkit looks like

[Eric S. Raymond]

Miles Bader <miles@gnu.org>:
> I suspect that 90% of the difference in "responsiveness" between the two
> projects has to do with the people (and numbers of people) involved, not
> with the tools being used.

I don't think those are separable -- I think Wesnoth has more developers
in significant part *because* its tools are better.

> Certainly the tools make _some_ difference, but I think ESR is
> drastically overestimating how much of one.

You may be right.  But we won't know until we fix our toolset and see,
and fixing our toolset would have important benefits even at our
current scale.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: What a modern collaboration toolkit looks like

[Eric S. Raymond]

Alan Mackenzie <acm@muc.de>:
> Emacs is an atypical, very old, piece of free software.  Wesnoth seems to
> be about 5 years old.  (I haven't found the repository online.)  This has
> some bearing on the differences in development processes.

Indeed.  It means we have a lot of history and bad habits to unburden
ourselves of, and that's a problem Wesnoth does not have as
acutely. (It dates from 2003.)

> > a) That change can be referenced, through its Subversion revision ID.  
> >    (So, for example, "Hey boucman, your r22615 broke linger mode!")
> 
> Hopefully, people are considerate enough not to do this too often;
> continually having to look somewhere else to get context is not nice.

In fact that particular situation is rare.  My point was that Wesnoth's
communications tools help us correct such problems quickly.  What a 
fighter pilot would call our "OODA loop" is very fast.
 
> > b) That change can be backed out as a unit.
> 
> That's fine if nearly all changes are independent.  In Emacs, I think,
> this is not the case.

It's actually very useful even when changes are intertangled.  For one
thing, it makes isolating regressions via a bisection search practical.
While this is theoretically possible under CVS, there is just enough
friction to make it something people seldom or never actually do.

> Such easy backing out could lead to problems.

I find that the problems of easy backout are far outweighed by its benefits.

As a recent example: my lieutenant on one of my other projects (GPSD) committed
a change that broke our regression tests.  It was a day and a half and about
a dozen commits later when I noticed this.  It matters that I was *immediately*
able to back out both the bad commits with high confidence that I was not
leaving the code in an inconsistent state.  (And rap him on the knuckles,
but that was a social act and not a technical one.)
 
> > 2. My commit is also echoed to the IRC channel, where there are almost
> > never fewer than three or four devs hanging out as they hack, chatting
> > in real time.  Review tends to happen instantly.
> 
> What about fixes that are too big for instant review?  Emacs has lots of
> bugs (and often fixes ;-) that are barely tractable, so that the slower
> pace of email seems a better fit.

IRC functions as a kind of triage on such changes.  If we can't resolve
a problem in real time, we fall back to the mailing list.  This happens
much less often than I myself would have expected before I became used
to this style.

I'll admit, it did take me some adjustment to get used to.  The
Wesnoth devs are mostly kids who have grown up in a post-MTV world,
used to constant multitasking.  I just turned 50.  When I first
contemplated getting involved, about nine months ago now, I had to
wrestle with some fear that (a) I would be distracted and losing focus
all the time, and (b) worse, I might discover that I was simply too
old and lacked the mental agility to keep up.

The second, especially, would have been crushing. I had to screw up my
courage to try doing things their way lest I discover myself to
be inadequate.

In fact, both fears proved groundless.  Nowadays I routinely have an IRC
client open in five tabs to three different projects, and it all just
becomes part of my flow.  I think it matters a lot that IRC chat is 
silent -- I absolutely can't imagine imagine maintaining concentration
while multiplexing that many voice channels.

And far from finding I can't keep up, I've discovered that I like the
stimulation.  I grok how the kids feel about this, because mailing-list-only
projects have started to seem slow and boring to me, too.

> I've no experience of IIRC.  But doesn't this way of working mean
> continually dancing from one thing to another?  I don't do that very
> well. 

See above.  I myself was afraid I wouldn't be able to handle this.  But 
I adapted, and now I feel really liberated by having done so.  

>       The "hyperlinks" bit sounds like you have to look at 3 or 4 things
> simultaneously to be able to synthesise a context.  How does this working
> style work for difficult problems?

Same way it does for easy ones.  The difference is that with older, slower
workflows we had to absorb all those bits of context more or less serially
and buffer them in our heads for relatively long periods of time.  I don't 
have to do that as much now -- it's more about keeping track of where the
context is and quickly swapping in the parts I need at any given time.

> > Yet a third is that when we decide to do it, we can converge on a
> > releasable state with almost absurd ease.  Like, Ivanovic (our release
> > manager) will announce "Point release scheduled this coming Wednesday"
> > and everyone will pretty much flip into bug-stomping mode.  The tracker
> > bug list tends to shrink dramatically when this happens -- not only do
> > we get prepared for release but *we know we've done so*.
> 
> Eric, how well do you think this could work at all for Emacs?

I'm going to stop waving my hands and run some numbers.  According to
sloccount, the C core of Emacs is just about twice the size of
Wesnoth's C++.  Assuming the usual quadratic rise in bug density with
LOC, the equivalent release tempo would be three months.

But I think that's an overestimate.  Our devs are more capable, and a fair
amount of the Emacs core is either effectively dead (like, say, the VMS
support) or so stable that it never needs to be touched.  Then there's
the C vs. C++ difference.  

All in all, I think six weeks is a reasonable guess for where we'd end up.

"But..." I hear you say "you're ignoring the Lisp!".  Yes, I am -- and
that's because one thing rather clear from the Changelogs and NEWS
files is that the Lisp code is not where the long-term release
blockers tend to pop up.

> > More generally, development happens *fast*.  I don't have to wait weeks
> > to find out whether other devs think of an idea.  Commonly I know
> > within minutes.
> 
> On emacs-devel, this takes hours, not weeks.  At any given time, most
> Emacs developers are either asleep or doing other things (like earning
> their living).  Doesn't this quick-fire style end up excluding lots of
> hackers from participation?

It doesn't seem to work that way in practice.  Or, at least, I don't
hear hackers bitching about not being involved in decisions.  What the
core devs (including me) seem to do is keep one eye on the project IRC channel 
more or less constantly while doing those other things.
 
> > The Wesnoth devs are good but not exceptionally so, and we're weighed
> > down by a crappy implementation language (C++).
> 
> Yuck!!

Indeed.  I've had to become competent at it.  This has been painful.

> > Nevertheless our productivity, in terms of goals achieved per hour of
> > work, is quite high.  That's because our collaboration tools support
> > everything we do without imposing noticeable process friction.  This
> > makes us dramatically more effective as individuals and as a group than
> > we could possibly be without them.
> 
> Might it also be because your code base is still young, clean and
> flexible?

It's an appealing theory, but...no.  The Wesnoth code is not at all clean
internally, and the Wesnoth devs themselves often bitch about its rigidity.

There are two reasons for this.  One is C++; enough said. The other is
that the Wesnoth devs are, on average, somewhat less capable and a lot
less experienced than Emacs's have been -- and their most serious
weakness tends to be a very limited understanding of design for
maintainability.

The result, unfortunately, is that while the Wesnoth code is much younger
than of Emacs, it has already achieved a comparable cruft level :-(.

> > Lessons for the Emacs project?  Hell, yes.  But I'm not going to write
> > that rant until y'all have had a little time to absorb this description
> > of how things can be.
> 
> I'll look forward to that!  We'd all welcome a process for releasing
> every few months rather than twice a decade.

Yeah.  That would be good.  

My worst-case estimate, with modern tools, would be a three-to-four
month release cycle. 
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: What a modern collaboration toolkit looks like

[Alan Mackenzie]

Hi, Eric!

On Mon, Dec 31, 2007 at 10:25:09AM -0500, Eric S. Raymond wrote:
> Alan Mackenzie <acm@muc.de>:
> > Emacs is an atypical, very old, piece of free software.  Wesnoth seems to
> > be about 5 years old.  (I haven't found the repository online.)  This has
> > some bearing on the differences in development processes.

> Indeed.  It means we have a lot of history and bad habits to unburden
> ourselves of, and that's a problem Wesnoth does not have as
> acutely. (It dates from 2003.)

[ .... ]

> > What about fixes that are too big for instant review?  Emacs has lots
> > of bugs (and often fixes ;-) that are barely tractable, so that the
> > slower pace of email seems a better fit.

> IRC functions as a kind of triage on such changes.  If we can't resolve
> a problem in real time, we fall back to the mailing list.  This happens
> much less often than I myself would have expected before I became used
> to this style.

Again, how can the Emacs developers do this?  Some of us live in North
America, others in Europe, East Asia and New Zealand, possibly other
places too.  We're never all going to be on line at the same time.
Surely this process would promote a minority clique who would be making
all the decisions.

> I'll admit, it did take me some adjustment to get used to.  The Wesnoth
> devs are mostly kids who have grown up in a post-MTV world, used to
> constant multitasking.  I just turned 50.

Yes, it's frightening.  I'll be 50 next month.

> When I first contemplated getting involved, about nine months ago now,
> I had to wrestle with some fear that (a) I would be distracted and
> losing focus all the time, and (b) worse, I might discover that I was
> simply too old and lacked the mental agility to keep up.

> The second, especially, would have been crushing. I had to screw up my
> courage to try doing things their way lest I discover myself to
> be inadequate.

I empathise with this, too.  I anticipate it making me feel dizzy.

> In fact, both fears proved groundless.  Nowadays I routinely have an
> IRC client open in five tabs to three different projects, and it all
> just becomes part of my flow.  I think it matters a lot that IRC chat
> is silent -- I absolutely can't imagine imagine maintaining
> concentration while multiplexing that many voice channels.

For me, silence means _nothing_ flashing or moving on the screen (except,
perhaps, a cursor), no garishness, {scroll,tool,menu} bars switched off,
and absolutely nothing like a dialog boxes exploding in my face.

[ .... ]

> > Eric, how well do you think this could work at all for Emacs?

> I'm going to stop waving my hands and run some numbers.  According to
> sloccount, the C core of Emacs is just about twice the size of
> Wesnoth's C++.  Assuming the usual quadratic rise in bug density with
> LOC, the equivalent release tempo would be three months.

> But I think that's an overestimate.  Our devs are more capable, and a fair
> amount of the Emacs core is either effectively dead (like, say, the VMS
> support) or so stable that it never needs to be touched.  Then there's
> the C vs. C++ difference.  

> All in all, I think six weeks is a reasonable guess for where we'd end up.

OK.  So we'd be modifying our goal of "bug free, exhaustively tested at
each major release".  This might be good, might be bad.

> "But..." I hear you say "you're ignoring the Lisp!".  Yes, I am -- and
> that's because one thing rather clear from the Changelogs and NEWS
> files is that the Lisp code is not where the long-term release blockers
> tend to pop up.

Really?  That surprises me, though I haven't ever really studied the
status.

> > > More generally, development happens *fast*.  I don't have to wait weeks
> > > to find out whether other devs think of an idea.  Commonly I know
> > > within minutes.

> > On emacs-devel, this takes hours, not weeks.  At any given time, most
> > Emacs developers are either asleep or doing other things (like earning
> > their living).  Doesn't this quick-fire style end up excluding lots of
> > hackers from participation?

> It doesn't seem to work that way in practice.  Or, at least, I don't
> hear hackers bitching about not being involved in decisions.  What the
> core devs (including me) seem to do is keep one eye on the project IRC
> channel more or less constantly while doing those other things.

Do these hackers live in a narrow band of time zones?

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: What a modern collaboration toolkit looks like

[Eric S. Raymond]

Alan Mackenzie <acm@muc.de>:
> > IRC functions as a kind of triage on such changes.  If we can't resolve
> > a problem in real time, we fall back to the mailing list.  This happens
> > much less often than I myself would have expected before I became used
> > to this style.
> 
> Again, how can the Emacs developers do this?  Some of us live in North
> America, others in Europe, East Asia and New Zealand, possibly other
> places too.  We're never all going to be on line at the same time.

No, and that's true on the Battle For Wesnoth project, too.  In
particular, we have for some reason a large contingent of developers
in Germany, including the release manager.  But the project founder is
West Coast US; I and a couple of the other most active senior devs are
East Coast US.  So we're spread from GMT-1 to GMT+8.

It works out, though.  We all monitor #wesnoth-dev constantly.  Well, OK,
my IRC client is often minimized, but the task-bar entry for it glows
discreetly orange when Chatzilla sees my name mentioned.  

> Surely this process would promote a minority clique who would be making
> all the decisions.

You do gradually gain status by being available when you're needed.  And 
you do lose influence when you're not around for a while.  But there's
no cliquishness about it -- all you have to do to have a place in the 
discussion is show up, really.

I went from newbie to senior dev in about four months by (a) pitching
in doing a lot of work, and (b) often being available because I was
working late at night when the Germans were waking up and joining IRC
for the day.

After a while the Germans started feeling unwilling to make large
decisions without having me in on the conversation and partly adapted
themselves to *my* schedule.  I think one of the tipping points there
was when the release manager (not a native English-speaker) started
always having me spell-check the release announcements before he
shipped them.

> For me, silence means _nothing_ flashing or moving on the screen (except,
> perhaps, a cursor), no garishness, {scroll,tool,menu} bars switched off,
> and absolutely nothing like a dialog boxes exploding in my face.

Chatzilla is your friend, then -- no flashy bits.  Avoid Xchat.
 
> OK.  So we'd be modifying our goal of "bug free, exhaustively tested at
> each major release".  This might be good, might be bad.

More likely we'd relax our standards for point releases at the six-week
marks and do maybe two or three major releases a year with careful 
testing.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: What a modern collaboration toolkit looks like

[Richard Stallman]

    You do gradually gain status by being available when you're needed.  And 
    you do lose influence when you're not around for a while.  But there's
    no cliquishness about it -- all you have to do to have a place in the 
    discussion is show up, really.

I'd prefer a culture in which status comes from being willing and
able to do the hard jobs.  It sounds like that is a reason to mainly
stick to email.

Re: What a modern collaboration toolkit looks like

[Eric S. Raymond]

Richard Stallman <rms@gnu.org>:
>     You do gradually gain status by being available when you're needed.  And 
>     you do lose influence when you're not around for a while.  But there's
>     no cliquishness about it -- all you have to do to have a place in the 
>     discussion is show up, really.
> 
> I'd prefer a culture in which status comes from being willing and
> able to do the hard jobs.  It sounds like that is a reason to mainly
> stick to email.

Did you miss the bit where I talked about going from n00b to senior dev
in four months because I pitched in and did a lot of hard work?

You can have a place in the discussion just by showing up.  But you
only develop authority by taking responsibility.  That has not 
changed, nor is it likely to.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: What a modern collaboration toolkit looks like

[dhruva]

Hi,
 Anyone pitching in for mercurial (hg)? It is available on all
platforms on which PYTHON runs. It works on OpenVMS too (not that many
people here would care). Has fewer external dependencies (git needs a
POSIX shell) and hence easy to deploy on non-UNIX platforms.

A link to the mercurial book:
http://hgbook.red-bean.com/hgbook.pdf

It is very much GIT like in its usage but IMHO, much more portable as
it is implemented in PYTHON (just like elisp code works where ever
emacs runs).

with best regards,
dhruva

-- 
Contents reflect my personal views only!

Re: What a modern collaboration toolkit looks like

[Miles Bader]

dhruva <dhruvakm@gmail.com> writes:
> It is very much GIT like in its usage but IMHO, much more portable as
> it is implemented in PYTHON (just like elisp code works where ever
> emacs runs).

Hg is sort of like "git for dummies"...

[A python dependency is _not_ an advantage IMHO...]

-Miles

-- 
`Life is a boundless sea of bitterness'

Re: What a modern collaboration toolkit looks like

[Tassilo Horn]

dhruva <dhruvakm@gmail.com> writes:

Hi,

>  Anyone pitching in for mercurial (hg)?

Before everybody posts his favourite SCM I'd say we wait until Eric
finished his comparison paper.  Then we'll have all pros and cons side
by side and choose whichever fits our needs best.

Talking about portability, git does run on anything POSIX and there's a
fork for Windows (without cygwin), which is merged into the main line
right now.  (Maybe its already finished.)

Bye,
Tassilo

Re: What a modern collaboration toolkit looks like

[David Kastrup]

Tassilo Horn <tassilo@member.fsf.org> writes:

> dhruva <dhruvakm@gmail.com> writes:
>
>>  Anyone pitching in for mercurial (hg)?
>
> Before everybody posts his favourite SCM I'd say we wait until Eric
> finished his comparison paper.  Then we'll have all pros and cons side
> by side and choose whichever fits our needs best.
>
> Talking about portability, git does run on anything POSIX and there's
> a fork for Windows (without cygwin), which is merged into the main
> line right now.  (Maybe its already finished.)

Not yet, as far as I know.  I am partial to git because it is fast,
flexible and can keep up with the history of code fragments moving
between files (not just renaming).

However, its current state for Windows developers is painful.  While I
don't use Windows myself, I do consider this sort of a showstopper.  But
git is actively headed towards supporting Windows quite well, and I
would not want to rush into a different SCM just because of the Windows
support when it appears that the severity of Windows drawbacks will go
away mostly in a not so distant future.

-- 
David Kastrup

Re: What a modern collaboration toolkit looks like

[Richard Stallman]

    However, its current state for Windows developers is painful.  While I
    don't use Windows myself, I do consider this sort of a showstopper.

It is GNU Project policy that nothing concerning Windows support
should be considered a showstopper.

Re: What a modern collaboration toolkit looks like

[John S. Yates, Jr.]

DAK> However, its current state for Windows developers is painful.  While
DAK> I don't use Windows myself, I do consider this sort of a showstopper.

RMS> It is GNU Project policy that nothing concerning Windows support
RMS> should be considered a showstopper.

This feels like a knee-jerk reaction to the appearance of the terms
Windows and showstopper in close proximity.

David was referring to rolling out use of a new DVCS, not delivering
a Gnu project release.  The show being stopped was either the specific
tool selection or the roll out schedule.

Surely you do not believe that emacs developers on Windows boxes do
nothing more than work in Windows-specific areas.

Your statement could be interpreted as saying that not only would you
offer the Windows world no quarter but furthermore that you could not
care less about disenfranchising emacs contributors stuck working in
Windows-based environments, often because of circumstances over which
they have no control.

Working on a Windows box is not equivalent to supporting proprietary
software.

Thoughtlessly obstructing the propagation of Gnu software into the
Windows world or impeding Windows-based developers from contributing
productively to Gnu projects would be difficult for me to understand.

/john

Re: What a modern collaboration toolkit looks like

[Richard Stallman]

    This feels like a knee-jerk reaction to the appearance of the terms
    Windows and showstopper in close proximity.

    David was referring to rolling out use of a new DVCS, not delivering
    a Gnu project release.  The show being stopped was either the specific
    tool selection or the roll out schedule.

Yes, I know.

    Surely you do not believe that emacs developers on Windows boxes do
    nothing more than work in Windows-specific areas.

You are correct, I don't believe that.

    Your statement could be interpreted as saying that not only would you
    offer the Windows world no quarter but furthermore that you could not
    care less about disenfranchising emacs contributors

Words such as "enfranchise" are inappropriate because they imply
recognizing someone's entitlement.  That's not what accepting
contributions consists of.

    Thoughtlessly obstructing the propagation of Gnu software into the
    Windows world or impeding Windows-based developers from contributing
    productively to Gnu projects would be difficult for me to understand.

Whatever tool we choose, and whatever drawbacks we choose in spite of,
the choice will not be thoughtless.

Re: What a modern collaboration toolkit looks like

[Werner LEMBERG]

>  Anyone pitching in for mercurial (hg)? It is available on all
> platforms on which PYTHON runs. It works on OpenVMS too (not that
> many people here would care). Has fewer external dependencies (git
> needs a POSIX shell) and hence easy to deploy on non-UNIX platforms.

What's the mercurial equivalent to gitk?


    Werner

Re: What a modern collaboration toolkit looks like

[dhruva]

Hi,

On Jan 2, 2008 7:18 PM, Werner LEMBERG <wl@gnu.org> wrote:
> What's the mercurial equivalent to gitk?

hgk (based on gitk)

-dky

-- 
Contents reflect my personal views only!

Re: What a modern collaboration toolkit looks like

[Eric S. Raymond]

Werner LEMBERG <wl@gnu.org>:
> >  Anyone pitching in for mercurial (hg)? It is available on all
> > platforms on which PYTHON runs. It works on OpenVMS too (not that
> > many people here would care). Has fewer external dependencies (git
> > needs a POSIX shell) and hence easy to deploy on non-UNIX platforms.
> 
> What's the mercurial equivalent to gitk?

Try "hg view".  Even the window layout is strikingly similar.  
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: What a modern collaboration toolkit looks like

[Giorgos Keramidas]

On 2008-01-02 14:48, Werner LEMBERG <wl@gnu.org> wrote:
> > Anyone pitching in for mercurial (hg)? It is available on all
> > platforms on which PYTHON runs. It works on OpenVMS too (not that
> > many people here would care). Has fewer external dependencies (git
> > needs a POSIX shell) and hence easy to deploy on non-UNIX platforms.
>
> What's the mercurial equivalent to gitk?

hgview.

http://lists.logilab.org/pipermail/announce/2007-February/000052.html

A screenshot is also available at: http://www.logilab.org/3438

Re: What a modern collaboration toolkit looks like

[Eric S. Raymond]

dhruva <dhruvakm@gmail.com>:
>  Anyone pitching in for mercurial (hg)?

You mail probably crossed one from me in which I noted that I 
am leaning towards Mercurial for my personal use.

It may well be that I end up recommending Mercurial for Emacs; in fact
I think that's the most likely outcome of my research.  But I am
not yet prepared to make that or any other recommendation before
finishing my survey.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: What a modern collaboration toolkit looks like

[Jari Aalto]

* Sun 2007-12-30 Eric Raymond <esr@snark.thyrsus.com> gmane.emacs.devel
* Message-Id: 20071230122217.3CA84830B9A@snark.thyrsus.com
>
> This is a typical modern open-source project.  It's not even a
> particularly large one -- no more than a dozen core devs, 58
> developers total.  Here are the collaborative tools we use every day:
>
> * Source control with Subversion

I saw discussion that a change from CVS to distributed version control
is under consideration. To shed a little light to the DCVS scene, here
is one of my presentations:

  http://www.cante.net/~jaalto/doc/version-control-systems.pdf

Follow the small knobs "*" and underlined words to find out more
information (URL links).

SUMMARY

The git seems to be overall winner. It's a clear choice for big
projects.

- Git: phase of development is staggering and in few years
  the UI/OS compatibility issues are past
  * The branching and merging "in place" (no separate directories)
    is thing that excells over any other VCS/DCVS. A Brilliant invention
    and simple to use.
  * Vibrant community: ask a question and you get instant answers to
    anything.
  * The weak point is UI: it is very complicated. Currently
    requires very steep learning curve even from users that
    have prior experience (CVS/SVN stc.)

- Bzr seems to take second place. It has a long term progression path
  and support, very strict code quality and clearly defined
  development phases.
  * I estimate that it will improved in two years time to meet
    needs of almost any user.
  * Out of the box Central / semi-central / distributed support
    (much nicer than git's)
  * The best is UI: it's very smooth, uniform, logical and
    a CVS/SVN user is immediately at home with it.
  * Weak point: performance problems with big repositories with
    lot of old history. These will however be solved soon (1 year;
    during 2008).

Despite the popularity that Hg has been chosen by "Big projects" like
OpenJDK etc., I would not incline to recommended it. Reasons: Too slow
release schedule, small dev team, unclear roadmap. My observation is
based on:

  * Page 11: "DCVS Release Schedules"
  * Page 12: "Pace of Development (1)"
  * Page 13: "Pace of Development (2)"

Jari

NOTES
--------------

VCS = Version Control System (software)
git = Git http://git-scm.org
bzr = Bazaar http://bazaar-vcs.org
hg  = Mercurial http://www.selenic.com/mercurial/

Re: What a modern collaboration toolkit looks like

[dhruva]

Hello,
 I request you all to consider the deployment scenerio too and please
do not ignore users/dev on M$.
- git needs a bunch of unix tools and the cygwin bash shell. The user
will have to start getting used to the unix way
- git needs perl (on top of shell)
- mercurial just needs python

I personally find tools with large deployment dependancies a real
problem as each component will keep getting fixes/updates.

-dky

On 1/19/08, Jari Aalto <jari.aalto@cante.net> wrote:
> * Sun 2007-12-30 Eric Raymond <esr@snark.thyrsus.com> gmane.emacs.devel
> * Message-Id: 20071230122217.3CA84830B9A@snark.thyrsus.com
> >
> > This is a typical modern open-source project.  It's not even a
> > particularly large one -- no more than a dozen core devs, 58
> > developers total.  Here are the collaborative tools we use every day:
> >
> > * Source control with Subversion
>
> I saw discussion that a change from CVS to distributed version control
> is under consideration. To shed a little light to the DCVS scene, here
> is one of my presentations:
>
>   http://www.cante.net/~jaalto/doc/version-control-systems.pdf
>
> Follow the small knobs "*" and underlined words to find out more
> information (URL links).
>
> SUMMARY
>
> The git seems to be overall winner. It's a clear choice for big
> projects.
>
> - Git: phase of development is staggering and in few years
>   the UI/OS compatibility issues are past
>   * The branching and merging "in place" (no separate directories)
>     is thing that excells over any other VCS/DCVS. A Brilliant invention
>     and simple to use.
>   * Vibrant community: ask a question and you get instant answers to
>     anything.
>   * The weak point is UI: it is very complicated. Currently
>     requires very steep learning curve even from users that
>     have prior experience (CVS/SVN stc.)
>
> - Bzr seems to take second place. It has a long term progression path
>   and support, very strict code quality and clearly defined
>   development phases.
>   * I estimate that it will improved in two years time to meet
>     needs of almost any user.
>   * Out of the box Central / semi-central / distributed support
>     (much nicer than git's)
>   * The best is UI: it's very smooth, uniform, logical and
>     a CVS/SVN user is immediately at home with it.
>   * Weak point: performance problems with big repositories with
>     lot of old history. These will however be solved soon (1 year;
>     during 2008).
>
> Despite the popularity that Hg has been chosen by "Big projects" like
> OpenJDK etc., I would not incline to recommended it. Reasons: Too slow
> release schedule, small dev team, unclear roadmap. My observation is
> based on:
>
>   * Page 11: "DCVS Release Schedules"
>   * Page 12: "Pace of Development (1)"
>   * Page 13: "Pace of Development (2)"
>
> Jari
>
> NOTES
> --------------
>
> VCS = Version Control System (software)
> git = Git http://git-scm.org
> bzr = Bazaar http://bazaar-vcs.org
> hg  = Mercurial http://www.selenic.com/mercurial/
>
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel
>

-- 
Sent from Gmail for mobile | mobile.google.com

Contents reflect my personal views only!

Re: What a modern collaboration toolkit looks like

[Miles Bader]

dhruva <dhruvakm@gmail.com> writes:
>  I request you all to consider the deployment scenerio too and please
> do not ignore users/dev on M$.

They are not ignored, merely treated as a secondary concern.

cygwin seems like a fine solution for supporting developers on windows.

-Miles

-- 
`Suppose Korea goes to the World Cup final against Japan and wins,' Moon said.
`All the past could be forgiven.'   [NYT]

Re: What a modern collaboration toolkit looks like

[Juanma Barranquero]

On Jan 20, 2008 6:10 AM, Miles Bader <miles@gnu.org> wrote:

> cygwin seems like a fine solution for supporting developers on windows.

I doubt Cygwin can be "a fine solution" for anything, but that's just me.

However, as someone already said, there's MSYS/MinGW port of git in
the works. It lacks some things (Subversion importing, daemon, most
things related to e-mail...), but it is quite useable.

That's not to say that git it is preferable over mercurial, however.
Let's first read Eric's article.

             Juanma

Re: What a modern collaboration toolkit looks like

[Miles Bader]

"Juanma Barranquero" <lekktu@gmail.com> writes:
> I doubt Cygwin can be "a fine solution" for anything, but that's just me.

There seem to be a fair number of windows users who have some sort of
gripe with cygwin, but I've never quite understood what it
is... Whenever I try cygwin, things just work, and installing it seems
completely painless.

> However, as someone already said, there's MSYS/MinGW port of git in
> the works. It lacks some things (Subversion importing, daemon, most
> things related to e-mail...), but it is quite useable.

Yes, obviously in the long run, the msys git port will probably be
preferable to the majority of developers.  What you say above seems to
indicate it's further along than I realized.

> That's not to say that git it is preferable over mercurial, however.
> Let's first read Eric's article.

When Eric finishes his "article", it will be something to consider, but
please don't give the impression that it will be some kind of definitive
statement on the issue.  Eric, besides having rather obvious lack of
experience with many of these systems, has already shown clear biases.
It's very hard for even somebody trying hard to be objective to do a
good job of such a comparison.

-Miles

-- 
I'd rather be consing.

Re: What a modern collaboration toolkit looks like

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Date: Sun, 20 Jan 2008 15:03:50 +0900
> Cc: emacs-devel@gnu.org
> 
> "Juanma Barranquero" <lekktu@gmail.com> writes:
> > I doubt Cygwin can be "a fine solution" for anything, but that's just me.
> 
> There seem to be a fair number of windows users who have some sort of
> gripe with cygwin, but I've never quite understood what it
> is...

The gripe is threefold:

  . You cannot install a single Cygwin package seamlessly, without
    pulling in a whole bunch of other packages (which could
    potentially conflict with whatever else you have on your
    machine -- a hassle, since Cygwin is subtly incompatible with
    non-Cygwin programs).

  . There can be only one Cygwin DLL on any given system.  This is a
    hassle: e.g., it practically requires that you always upgrade all
    your Cygwin packages whenever a new version is uploaded.

  . Compared to native ports, Cygwin is slow.

The first two problems mean in practice that Cygwin is a catholic
marriage, unless one has lots of time to tinker with their system.

There: now you've heard it.

> Yes, obviously in the long run, the msys git port will probably be
> preferable to the majority of developers.  What you say above seems to
> indicate it's further along than I realized.

MSYS is just a fork of Cygwin, and as such, shares most of its
problems mentioned above.  Its primary goal was to provide a _build_
environment for native MinGW ports, not a platform to produce ports
used outside of the build environment for their own good.

Re: What a modern collaboration toolkit looks like

[Juanma Barranquero]

On Jan 20, 2008 8:28 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> MSYS is just a fork of Cygwin, and as such, shares most of its
> problems mentioned above.

msysGit comes with tools from MSYS or built with MSYS (bash, bzip2,
cat, perl, etc.), but the git executables do not depend on
msys-1.0.dll; I think they are normal MinGW executables.

             Juanma

Re: What a modern collaboration toolkit looks like

[Juanma Barranquero]

On Jan 20, 2008 7:03 AM, Miles Bader <miles@gnu.org> wrote:

 > Yes, obviously in the long run, the msys git port will probably be
> preferable to the majority of developers.  What you say above seems to
> indicate it's further along than I realized.
>
> > That's not to say that git it is preferable over mercurial, however.
> > Let's first read Eric's article.
>
> When Eric finishes his "article", it will be something to consider, but
> please don't give the impression that it will be some kind of definitive
> statement on the issue.  Eric, besides having rather obvious lack of
> experience with many of these systems, has already shown clear biases.
> It's very hard for even somebody trying hard to be objective to do a
> good job of such a comparison.
>
> -Miles
>
> --
> I'd rather be consing.
>



-- 
             Juanma

Re: What a modern collaboration toolkit looks like

[Juanma Barranquero]

[Sorry for the previous empty message]

> Yes, obviously in the long run, the msys git port will probably be
> preferable to the majority of developers.  What you say above seems to
> indicate it's further along than I realized.

Well. Most basic things work: you can clone, commit, rebase, pull,
push, handle branches, etc. The basic workflow is there. What I tried
to say is not that git on Windows is near completion, but that, were
Emacs to switch to git, the msysGit functionality would be enough for
Windows developers not to be left in the cold (that was my primary
worry; whether we switch to git or mercurial or bazaar or monotone, I
don't particularly care).

> When Eric finishes his "article", it will be something to consider, but
> please don't give the impression that it will be some kind of definitive
> statement on the issue. Eric, besides having rather obvious lack of
> experience with many of these systems, has already shown clear biases.

I wasn't trying to give that impression. But as obviously Eric is
investing effort both to show better ways for the Emacs project
(whether what he points is better or not is open to discussion, but it
would be unfair to negate that he's trying to Do Good) and to evaluate
alternatives, I think it would be polite to at least hear him. Of
course he's biased. Aren't we all?

> It's very hard for even somebody trying hard to be objective to do a
> good job of such a comparison.

I don't think we need a good general comparison; more like a good
comparison from people who has a working knowledge of the dVCS tools
and, most important, knows about Emacs development.

             Juanma

Re: What a modern collaboration toolkit looks like

[Miles Bader]

"Juanma Barranquero" <lekktu@gmail.com> writes:
>> It's very hard for even somebody trying hard to be objective to do a
>> good job of such a comparison.
>
> I don't think we need a good general comparison; more like a good
> comparison from people who has a working knowledge of the dVCS tools
> and, most important, knows about Emacs development.

Many of the regular developers on this list appear to have a great deal
more experience with both (dVCS tools and Emacs development) than Eric
does...

-Miles

-- 
Road, n. A strip of land along which one may pass from where it is too
tiresome to be to where it is futile to go.

Re: What a modern collaboration toolkit looks like

[Karl Fogel]

Miles Bader <miles.bader@necel.com> writes:
> "Juanma Barranquero" <lekktu@gmail.com> writes:
>>> It's very hard for even somebody trying hard to be objective to do a
>>> good job of such a comparison.
>>
>> I don't think we need a good general comparison; more like a good
>> comparison from people who has a working knowledge of the dVCS tools
>> and, most important, knows about Emacs development.
>
> Many of the regular developers on this list appear to have a great deal
> more experience with both (dVCS tools and Emacs development) than Eric
> does...

But Eric has stepped forward to actually do the comparison work here.
(He also has enough experience in both fields for this purpose, even
if there are people here who have more with one field, the other, or
both.)

I'm looking forward to his comparison and recommendations.  I'd also
look forward to yours, of course.

-Karl

Re: What a modern collaboration toolkit looks like

[Miles Bader]

Karl Fogel <kfogel@red-bean.com> writes:
>> Many of the regular developers on this list appear to have a great deal
>> more experience with both (dVCS tools and Emacs development) than Eric
>> does...
>
> But Eric has stepped forward to actually do the comparison work here.

Certainly his comparison will be welcome input, and perhaps a good
starting point for more substantive discussion.

-Miles

-- 
`The suburb is an obsolete and contradictory form of human settlement'

Re: What a modern collaboration toolkit looks like

[Nick Roberts]

 > Certainly his comparison will be welcome input, and perhaps a good
 > starting point for more substantive discussion.

Starting point?  More substantive?  Entire version control systems have
probably been written in less time than we've spent discussing them.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: What a modern collaboration toolkit looks like

[Miles Bader]

Nick Roberts <nickrob@snap.net.nz> writes:
>  > Certainly his comparison will be welcome input, and perhaps a good
>  > starting point for more substantive discussion.
>
> Starting point?  More substantive?  Entire version control systems have
> probably been written in less time than we've spent discussing them.

Hey, if I was in control, we would have switched loooooong ago.
Certainly there's been no lack of people advocating change.

In any case, what choice do we have?  Currently there seem to be three
options:

    1) We don't want for Eric's report, and discuss what to do without it.

    2) We wait for the report, and use it as starting-point to discuss
       what to do.

    3) We wait for the report, and just accept whatever conclusions it
       comes to, without discussion.

Option (3) is clearly unacceptable.

I personally feel there's enough expertise on this list to make (1)
viable, but as others have expressed a desire to see what Eric says, and
as a concise summary of the issues might help those who are unfamiliar
with them, (2) seems like the best option.

-Miles

-- 
Laughter, n. An interior convulsion, producing a distortion of the features
and accompanied by inarticulate noises. It is infectious and, though
intermittent, incurable.

Re: What a modern collaboration toolkit looks like

[Stephen J. Turnbull]

Nick Roberts writes:

 > Starting point?  More substantive?  Entire version control systems have
 > probably been written in less time than we've spent discussing them.

One of the few actual facts confirmed on Eric's UVC-Reviewers list is
that indeed git was started on April 3 2005 and was (experimentally)
hosting the Linux kernel developers project on April 13th, 10 days
later.

Re: What a modern collaboration toolkit looks like

[Glenn Morris]

<rant>

I'm thoroughly fed up with this subject.

Is anyone trying to tell me, that switching to some hip new version
control system is going to make people start applying the patches that
currently sit around in this mailing list for weeks?

Or that when there is a shiny new bug tracker, people will suddenly
start fixing all the bugs that get reported?

I actually do think a bug tracker will be useful; I just think the
problems of Emacs development lie in other places rather than the
tools it uses. I don't care about the version control system.

For me, the problems can be summed up in the fact that the number of
people willing to write emails (and yes, that includes this one) about
what should be done vastly outweighs the number of people willing to
actually do anything.

I was trying not to comment on this pointless thread, but I've failed.

</rant>

Re: What a modern collaboration toolkit looks like

[Nick Roberts]

 > Is anyone trying to tell me, that switching to some hip new version
 > control system is going to make people start applying the patches that
 > currently sit around in this mailing list for weeks?

With GDB, developers who submit many patches are generally given
write access.  Those who only occasionally submit patches have their
patch committed by the maintainer approving it.  So IMHO Tom Tromey,
Ken Mannheimer etc should have write access and others should be able
to approve a patch.

 > Or that when there is a shiny new bug tracker, people will suddenly
 > start fixing all the bugs that get reported?

They don't get fixed but they become more traceable.  My recent bug report
about vc-dired wouldn't get lost and it could be marked as a duplicate or
related to the report Alexandru Harsanyi made about vc-workfile-unchanged-p in
mid December 2007.  ESR appears to have gone now, but with a tracker he could
review the bugs listed under VC when he returns and might choose to fix any
that caught his eye.

It's just unfortunate that RMS sees a bug list as preventing a release rather
than a database for recording new bugs and reviewing existing ones.

 > I actually do think a bug tracker will be useful; I just think the
 > problems of Emacs development lie in other places rather than the
 > tools it uses. 

They're separate issues, let's not blur them.

 > I don't care about the version control system.

I think there could also be benefits here with merging branches, changesets,
moving files etc. but it clearly also isn't a silver bullet.

 > For me, the problems can be summed up in the fact that the number of
 > people willing to write emails (and yes, that includes this one) about
 > what should be done vastly outweighs the number of people willing to
 > actually do anything.
 > 
 > I was trying not to comment on this pointless thread, but I've failed.

It's been unproductive but probably not pointless.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: What a modern collaboration toolkit looks like

[Thien-Thi Nguyen]

() Glenn Morris <rgm@gnu.org>
() Sun, 20 Jan 2008 22:16:05 -0500

   Is anyone trying to tell me, that switching to some hip new
   version control system is going to make people start applying
   the patches that currently sit around in this mailing list for
   weeks?

Although i haven't in the past, i would be willing to tell you
that, and will take time to explain why, now:

Emacs hacking requires thought to "DTRT", which is inhibiting to
me because experience leads me to ponder (mostly enjoyably, but
more germainely, always lengthily) on the history of the context
of that acronym as uttered by a specific person, to avoid getting
burned by misunderstanding.  When rms sez "DTRT", i work hard to
disambiguate its meaning from when jrhacker sez "DTRT".  Perhaps
others find it easier; i cannot speak for others.

A distributed version control system (my bias is towards git at
the moment) separates DTRT_process from DTRT_code up to the time
of publishing the change.  The effect is that i can parallelize my
pondering to some (Amdahl-limited ;--) extent, and thus check in
things faster.

Now let's turn from commit 0 in a series, to commit N.  Why is
there a commit N?  Because commit 0 was problematic in some way,
even though supreme effort was (presumably) expended to DTRT.
i.e, commit 0 did NOT DTRT; i make mistakes, i misunderstand.

A distributed version control system would mitigate this by
letting me do commit 0 locally, iterating N times until my
practice matches what is considered to be TRT.  This is basically
a restatement of the parallelized pondering paragraph above, w/
s/understanding/practice/g.

"But", you may be thinking, "what does that have to do w/ patches
that have been sitting around for weeks?"

Well, i have write privs and i am happy to check in code that DTRT
from those that do not have write privs.  But how do i know that
code DTRT?  How do i know its author has iterated enough so that
the understanding/practice reflected therein has the quality of
commit N and not quality of commit 0?

One answer to these questions starts w/ "It's none of your
business; why do you care?; your part is merely secretarial."  To
which i can only say: sorry, i do care, and will ignore arguments
in that vein.

Another answer is: "Learn the code; use the opportunity of its
passing through your brain to expand your expertise -- in that way
you will recognize if it DTRT."  To which i say: agreed mostly,
but not fully.  I can expand my understanding of such code, per
se, but w/o access to its history, the understanding is illusory
and incomplete.  There is a chance that i have merely stumbled
upon a superficial outcropping of deeper (more interesting)
issues, that my grokking is mere luck, and most dangerously, that
the overlapped (between myself and the code's author) grokking is
transitory.  "Looks good because of X", thinks ttn.  "*IS* good
because of Y", thinks its author.  Patch applied.  Fast-forward
two months; ttn hacks on the code to support X better, breaking Y.
Lose.

IMHO expanding my expertise is best done by building on the
expertise of others.  A distributed version control system
combined w/ people's disinhibition of exposing their mistakes
allows me to more quickly grok the thought that went into the
presented patch as well as the code it changes, align my thoughts
w/ it, iterate w/ the author as necessary to achieve quality of
commit N, and apply it.

In the end, my spewing here might seem like an indictment of DTRT.
Perhaps.  But i tend to think otherwise: i think "DTRT" ethos
needs to grow up and leave the nest.  This involves two things:
supporting a phase separation of D and TRT, and expansion of TRT
to not only accept mistakes, but to actively support archeological
non-punitive reflection on the actions that surround them.

thi

Re: What a modern collaboration toolkit looks like

[Juanma Barranquero]

On Jan 21, 2008 3:11 AM, Miles Bader <miles.bader@necel.com> wrote:

> Many of the regular developers on this list appear to have a great deal
> more experience with both (dVCS tools and Emacs development) than Eric
> does...

Yes. Perhaps that's why Eric asked for collaborators and reviewers for
his paper...

But, really. I haven't said we should take Eric's word as gospel [1].
I've just said we should wait and read what he writes. It seems common
courtesy, as it is him who brought the issue of Emacs development
tools back from oblivion (this time), and the only one who seems to be
investing time.

             Juanma


[1] I don't usually agree with 10% of what Eric says. The last time I
read something by him I could fully enjoy was "A Guide to the Mazes of
Menace", the Nethack guidebook. But that does not mean I don't
appreciate the energy he's throwing at this.

Re: What a modern collaboration toolkit looks like

[Nick Roberts]

 > Many of the regular developers on this list appear to have a great deal
 > more experience with both (dVCS tools and Emacs development) than Eric
 > does...

Collectively, perhaps.  Most seemed to share their point of view from the
system(s) with which they were familiar.

I can see that placing the entire revision history of Emacs in a new VCS is a
major undertaking that is not to be taken lightly.  Choosing a bug tracker, in
comparison, is trivial: if we don't like it, we stop using it.

How about just approaching that task first?  

RMS has said:

   debbugs looks plausible, but what I would really like
   is for someone to try using the various possible bug trackers,
   limiting himself to email, and report on how well each one works
   in that mode.

It looks unlikely that anyone is willing to be quite so self-sacrificing.
Is it possible for someone to set up a Debian machine that is connected to the
Internet with debbugs and just see what happens?  Or are we just going to
spend the rest of 2008, 2009,... talking about it?


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: What a modern collaboration toolkit looks like

[Richard Stallman]

Git:

      * The weak point is UI: it is very complicated. Currently
	requires very steep learning curve even from users that
	have prior experience (CVS/SVN stc.)

Does VC in Emacs overcome that problem?

    - Bzr seems to take second place. It has a long term progression path
      and support, very strict code quality and clearly defined
      development phases.

BZR may become a GNU package, which would be a reason to prefer it.

Re: What a modern collaboration toolkit looks like

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  > Git:
  > 
  >       * The weak point is UI: it is very complicated. Currently
  > 	requires very steep learning curve even from users that
  > 	have prior experience (CVS/SVN stc.)
  > 
  > Does VC in Emacs overcome that problem?

It partially does, there are (BIG) missing pieces in the vc-git
implementation: vc-update and branching are not implemented.
And the UI for those 2 things is not good at all in Git.
(The underlying functionality works very well, but it is quite hard to
use if you don't have a thorough understanding on how Git works
inside...)

For vc-update: none of vc-git, vc-bzr and vc-hg implement it. vc-update
needs work in order to support these systems properly, they want to
merge on a whole project basis instead of file basis as vc-update
currently does.


  >     - Bzr seems to take second place. It has a long term progression path
  >       and support, very strict code quality and clearly defined
  >       development phases.
  > 
  > BZR may become a GNU package, which would be a reason to prefer it.

In the past surveys that I've seen Bzr was shown to be much slower
compared with Git and Mercurial and take much more disk space. Not sure
if that changed.

BTW, Mercurial was too easily dismissed for not very serious reasons in
the message you are replying to. It is used in a few very large
projects, it still developed and it works very well.


Hope this helps.

Re: What a modern collaboration toolkit looks like

[Miles Bader]

Dan Nicolaescu <dann@ics.uci.edu> writes:
> It partially does, there are (BIG) missing pieces in the vc-git
> implementation: vc-update and branching are not implemented.
>
> For vc-update: none of vc-git, vc-bzr and vc-hg implement it. vc-update
> needs work in order to support these systems properly, they want to
> merge on a whole project basis instead of file basis as vc-update
> currently does.

Of course part of the problem is that vc-update seems like a hopelessly
antiquated interface -- who wants to do merging on a file-by-file basis?!

> And the UI for those 2 things is not good at all in Git.
> (The underlying functionality works very well, but it is quite hard to
> use if you don't have a thorough understanding on how Git works
> inside...)

What do you mean?  [There are confusing things in git, but that hardly
seems one of them...]

-Miles

-- 
`To alcohol!  The cause of, and solution to,
 all of life's problems' --Homer J. Simpson

Re: What a modern collaboration toolkit looks like

[Tom Tromey]

>>>>> "Miles" == Miles Bader <miles@gnu.org> writes:

Miles> Of course part of the problem is that vc-update seems like a hopelessly
Miles> antiquated interface -- who wants to do merging on a file-by-file basis?!

Yeah... for vc-status I think we will need a new 'update' back end
function.  Also I think we will need a "conflict" state.

Tom

Re: What a modern collaboration toolkit looks like

[Stefan Monnier]

Miles> Of course part of the problem is that vc-update seems like a hopelessly
Miles> antiquated interface -- who wants to do merging on a file-by-file basis?!

> Yeah... for vc-status I think we will need a new 'update' back end

Sounds right.

> function.  Also I think we will need a "conflict" state.

Be careful with this one: some backends allow commits with conflicts
(for later resolution).  And for many operations, it doesn't matter if
a file is locally modified or with a conflict, so in many ways
"conflict" is a sub-state of "locally modified".


        Stefan

Re: What a modern collaboration toolkit looks like

[Tom Tromey]

>>>>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> function.  Also I think we will need a "conflict" state.

Stefan> Be careful with this one: some backends allow commits with conflicts
Stefan> (for later resolution).  And for many operations, it doesn't matter if
Stefan> a file is locally modified or with a conflict, so in many ways
Stefan> "conflict" is a sub-state of "locally modified".

Thanks.

FWIW I didn't have any clue what particular semantics "conflict"
should imply.  I just think that, like pcl-cvs, it is useful to show
this as a separate state in a vc-status buffer.

Tom

Re: What a modern collaboration toolkit looks like

[Dan Nicolaescu]

Miles Bader <miles@gnu.org> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > > It partially does, there are (BIG) missing pieces in the vc-git
  > > implementation: vc-update and branching are not implemented.
  > >
  > > For vc-update: none of vc-git, vc-bzr and vc-hg implement it. vc-update
  > > needs work in order to support these systems properly, they want to
  > > merge on a whole project basis instead of file basis as vc-update
  > > currently does.
  > 
  > Of course part of the problem is that vc-update seems like a hopelessly
  > antiquated interface

That was my point.  This has been discussed a few times on the list, and
I recently added it to the TODO list in vc.el. If anyone wants to
volunteer and sit down and do it, it would be great.

  > > And the UI for those 2 things is not good at all in Git.
  > > (The underlying functionality works very well, but it is quite hard to
  > > use if you don't have a thorough understanding on how Git works
  > > inside...)
  > 
  > What do you mean?  [There are confusing things in git, but that hardly
  > seems one of them...]

checkout vs checkout --track
pull, fetch and the 50 options that each has. 
But I doubt that this is the right place to discuss these things.

BTW, if anyone wants to see the difference in UI between git and
Mercurial/Bzr, just look at the commands that are run to implement
the VC interface in vc-{git,hg,bzr}.el.

Re: What a modern collaboration toolkit looks like

[Mark A. Hershberger]

Richard Stallman <rms@gnu.org> writes:

>     - Bzr seems to take second place. It has a long term progression path
>       and support, very strict code quality and clearly defined
>       development phases.
>
> BZR may become a GNU package, which would be a reason to prefer it.

Another reason to prefer it: stand-alone bzr binaries are available and
work *now* in Windows.  I've used bzr to do some work on a Windows port
of the iHRIS system I'm working on.

-- 
http://hexmode.com/
GPG Fingerprint: 7E15 362D A32C DFAB E4D2  B37A 735E F10A 2DFC BFF5

Ideas create idols; only wonder leads to knowing.
    -- St. Gregory of Nyssa

Re: What a modern collaboration toolkit looks like

[Juanma Barranquero]

On Jan 24, 2008 3:43 PM, Mark A. Hershberger <mah@everybody.org> wrote:

> Another reason to prefer it: stand-alone bzr binaries are available and
> work *now* in Windows.

That's also true of mercurial, monotone, darcs and git, depending of
how you do define "work now".

             Juanma

Re: What a modern collaboration toolkit looks like

[dhruva]

Hi,
 I would consider the ability to convert to other repository formats
as important too. Whatever VCS gets adopted must not lose any history
data and have enough metadata to be able to convert to other VCS
formats. Though I am biased towards mercurial, there is one git
feature I consider very good. Ability to run a git server for existing
cvs clients. Though this might be contradictory to dVCS concepts (not
too sure though)

-dky

On 1/24/08, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Jan 24, 2008 3:43 PM, Mark A. Hershberger <mah@everybody.org> wrote:
>
> > Another reason to prefer it: stand-alone bzr binaries are available and
> > work *now* in Windows.
>
> That's also true of mercurial, monotone, darcs and git, depending of
> how you do define "work now".
>
>              Juanma
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel
>

-- 
Sent from Gmail for mobile | mobile.google.com

Contents reflect my personal views only!

Re: What a modern collaboration toolkit looks like

[Stephen J. Turnbull]

dhruva writes:

 > feature I consider very good. Ability to run a git server for existing
 > cvs clients. Though this might be contradictory to dVCS concepts (not
 > too sure though)

CVS would be a reasonably useful alternative protocol for update-only
workspaces except for the fact that many firewalls block port 2401.

 > On 1/24/08, Juanma Barranquero <lekktu@gmail.com> wrote:

 > > That's also true of mercurial, monotone, darcs and git, depending of
 > > how you do define "work now".

Darcs does not "work now" any platform if in "work" you include "cheap
branches".  Darcs does not "work now" on any platform, if in "work"
you include "reliably delivers pushes and pulls in time similar to
CVS."  Posts by Darcs users (some of them long-timers) that they feel
forced to abandon Darcs or to move mission-critical repos to a
different VCS are a common occurrance.

Darcs 2, now in very early beta, addresses the first concern very well
according to benchmarks published on the developers list.  Similarly,
it partially addresses the second concern based on those benchmarks.
However, it is not clear that the "exponential-time merge" problem is
being addressed, and there is no real-world experience with Darcs 2
yet (it's not even self-hosting).

I would guess that in the time frame that Emacs is making the choice,
we'll see both Darcs 2 and GHC (the Glasgow Haskell Compiler used to
build Darcs) move their repos to Darcs 2.  So don't rule Darcs out.

Re: What a modern collaboration toolkit looks like

[Juanma Barranquero]

On Jan 24, 2008 8:52 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:

> I would guess that in the time frame that Emacs is making the choice,
> we'll see both Darcs 2 and GHC (the Glasgow Haskell Compiler used to
> build Darcs) move their repos to Darcs 2.  So don't rule Darcs out.

I know this, I follow several Haskell lists, glasgow-haskell-users
among them. My point wasn't about darcs shortcomings, but to stress
than having "stand-alone binaries available and working *now* in
Windows" will hardly be a deciding factor; not because I don't think
it is important (I do), but because any reasonable candidate dVCS
already works on Windows, to a lesser or greater extent.

             Juanma

Re: What a modern collaboration toolkit looks like

[Richard Stallman]

GNU projects should use and thus support other GNU projects, as a
matter of loyalty.  So if bzr becomes a GNU package, we should use
bzr.

Re: What a modern collaboration toolkit looks like

[Alfred M. Szmidt]

   GNU projects should use and thus support other GNU projects, as a
   matter of loyalty.  So if bzr becomes a GNU package, we should use
   bzr.

For the record, we have tla which does what bzr does.

Re: What a modern collaboration toolkit looks like

[Miles Bader]

"Alfred M. Szmidt" <ams@gnu.org> writes:
>    GNU projects should use and thus support other GNU projects, as a
>    matter of loyalty.  So if bzr becomes a GNU package, we should use
>    bzr.
>
> For the record, we have tla which does what bzr does.

I'd hope bzr would be at least a _bit_ better, given that it's
explicitly an attempt to rewrite tla from scratch and fix its problems
(or at least problems as canonical perceived them).

I don't know that I like the idea of an inferior system being promoted
simply because it has an arbitrary label attached though...

-Miles

-- 
97% of everything is grunge

Re: What a modern collaboration toolkit looks like

[Richard Stallman]

    I don't know that I like the idea of an inferior system being promoted
    simply because it has an arbitrary label attached though...

Being part of the GNU Project is not an arbitrary label.

Re: What a modern collaboration toolkit looks like

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     I don't know that I like the idea of an inferior system being
>     promoted simply because it has an arbitrary label attached
>     though...
>
> Being part of the GNU Project is not an arbitrary label.

It is not a label given for technical excellence.  And as far as I am
able to see, the promotion to "GNU software" is not the result of a
competition for that title, but is granted when certain criteria are met
and an application is made.  The FSF as the authority granting the label
of "GNU" does not at the same time have developer resources it can
devote or reroute to GNU software.

There are quite a few GNU software projects that are stagnating because
of a lack of developers.  It would not magically create new contributors
when something important like Emacs development is hobbled by being tied
into a project that does not, while deserving the name GNOME, have the
impetus and capability to keep Emacs running.

A development infrastructure depending on non-free software is
unfortunate, one depending on free non-GNU software is not, as far as I
can see, problematic over one depending on a resource-starved GNU
project: one could always fork the free non-GNU software and would start
with the same manpower (namely none) than one has for a stalling GNU
project.

So I don't think we should let ourselves be guided too much by the
non-GNU/GNU distinction for development infrastructure when the GNU
software does not fit the bill and we have no way making it do so.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: What a modern collaboration toolkit looks like

[Nick Roberts]

 > > Being part of the GNU Project is not an arbitrary label.
 > 
 > It is not a label given for technical excellence.  And as far as I am
 > able to see, the promotion to "GNU software" is not the result of a
 > competition for that title, but is granted when certain criteria are met
 > and an application is made.

I have presumed that it requires assigning all copyright to the FSF which
means that projects which have no record of authorship cannot become
GNU projects.

I'm interested to know what it means to be part of the GNU Project because
I work on both Emacs and GDB but, in practice, I can see no formal synergy
between the two, or preference towards each other.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: What a modern collaboration toolkit looks like

[David Kastrup]

Nick Roberts <nickrob@snap.net.nz> writes:

>  > > Being part of the GNU Project is not an arbitrary label.
>  > 
>  > It is not a label given for technical excellence.  And as far as I am
>  > able to see, the promotion to "GNU software" is not the result of a
>  > competition for that title, but is granted when certain criteria are met
>  > and an application is made.
>
> I have presumed that it requires assigning all copyright to the FSF
> which means that projects which have no record of authorship cannot
> become GNU projects.

Emacs does not have all copyright assigned to the FSF (for example, the
MULE subsystem is copyrighted by the Japanese Government or something
like that).  So the assignment in toto is not an absolutely rigid and
exceptionless rule.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: What a modern collaboration toolkit looks like

[Johan Bockgård]

Nick Roberts <nickrob@snap.net.nz> writes:

> I have presumed that it requires assigning all copyright to the FSF
> which means that projects which have no record of authorship cannot
> become GNU projects.

    "For a program to be GNU software does not require transferring
     copyright to the FSF; that is a separate question. If you transfer
     the copyright to the FSF, the FSF will enforce the GPL for the
     program if someone violates it; if you keep the copyright,
     enforcement will be up to you."

http://www.gnu.org/help/evaluation.html

-- 
Johan Bockgård

Re: What a modern collaboration toolkit looks like

[Richard Stallman]

Some GNU packages are copyright FSF, some are not.
The developers of a package decide to transfer the copyright
or not.

Re: What a modern collaboration toolkit looks like

[Richard Stallman]

    I'm interested to know what it means to be part of the GNU Project because
    I work on both Emacs and GDB but, in practice, I can see no formal synergy
    between the two, or preference towards each other.

We should be designing them both to work well together.  For instance,
the GDB developers should pay attention to what your Emacs work needs.

(I'm not sure whether the terms "formal synergy" or "preference
towards" fit this.)

GNU Project [was: Re: What a modern collaboration toolkit looks like]

[Nick Roberts]

 >     I'm interested to know what it means to be part of the GNU Project
 >     because I work on both Emacs and GDB but, in practice, I can see no
 >     formal synergy between the two, or preference towards each other.
 > 
 > We should be designing them both to work well together.  For instance,
 > the GDB developers should pay attention to what your Emacs work needs.

Yes, but that much would be true for any other free software project
like kdevelop or cgdb.  From reading http://www.gnu.org/help/evaluation.html
it seems to basically imply availability ftp.gnu.org on and consistency in
coding, documentation and licencing.  With regard to the latter, it sounds
a bit like a certification.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: GNU Project [was: Re: What a modern collaboration toolkit looks like]

[Richard Stallman]

     > We should be designing them both to work well together.  For instance,
     > the GDB developers should pay attention to what your Emacs work needs.

    Yes, but that much would be true for any other free software project
    like kdevelop or cgdb.

Those programs are other projects, not part of our project.  It is
good to help them when possible, but GNU packages get special priority.

    From reading http://www.gnu.org/help/evaluation.html
    it seems to basically imply availability ftp.gnu.org on and consistency in
    coding, documentation and licencing.

Those are some of the specific practical conditions and requirements,
but don't neglect the forest for the trees.  Those specific practical
points are aspects of being part of one larger project.

Re: What a modern collaboration toolkit looks like

[Richard Stallman]

I think you have the wrong picture of the issue.

All the GNU packages are part of one joint project to develop an
operating system.  To achieve this we must support each other.  To
keep ourselves honest, we must use other GNU packages whenever they
are fit for use.

Re: What a modern collaboration toolkit looks like

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> I think you have the wrong picture of the issue.

That implies that there is only one right picture.

> All the GNU packages are part of one joint project to develop an
> operating system.  To achieve this we must support each other.  To
> keep ourselves honest, we must use other GNU packages whenever they
> are fit for use.

Using a package is not the same as supporting it: it actually places
additional burdens on its developers.  When there are no additional
resources moved to them as well, their package has no tangible advantage
from this sort of "support".  And when this makes the sitation worse at
the "supporting" package, the total situation is a loss for GNU.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: What a modern collaboration toolkit looks like

[Stephen J. Turnbull]

David Kastrup writes:

 > Using a package is not the same as supporting it: it actually places
 > additional burdens on its developers.  When there are no additional
 > resources moved to them as well, their package has no tangible advantage
 > from this sort of "support".  And when this makes the sitation worse at
 > the "supporting" package, the total situation is a loss for GNU.

But this has become an abstract policy discussion, because I don't
think either is true in the case in point.

bzr is well-endowed with development resources, as it is a mission-
critical part of its maintainer's[1] infrastructure, but small in
comparison to the organization as a whole.  They are not going to
notice additional burden from Emacs's use.  Nor is it going to make
the Emacs development environment worse than continued dependence on
CVS does.  I don't know of any projects that switched from CVS or
Subversion to bzr that ever looked back.


Footnotes: 
[1]  Well, of course the GNU maintainer (is there one/more yet?
couldn't find one) will not be a corporation, but for these purposes
bzr is maintained by Canonical, not by any one person.

Re: What a modern collaboration toolkit looks like

[Richard Stallman]

    > I think you have the wrong picture of the issue.

    That implies that there is only one right picture.

I don't know whether there is more than one right picture, but you're
using the wrong one.  To approach things that way would be contrary to
the responsibilities of a GNU package maintainer.  It is out of the
question.  To argue for that just shows you don't understand.

    Using a package is not the same as supporting it: it actually places
    additional burdens on its developers.

That is too narrow a picture of "support".  Using a package is a vital
form of support.

Re: What a modern collaboration toolkit looks like

[Thomas Lord]

Alfred M. Szmidt wrote:
>    GNU projects should use and thus support other GNU projects, as a
>    matter of loyalty.  So if bzr becomes a GNU package, we should use
>    bzr.
>
> For the record, we have tla which does what bzr does.
>
>   


Oops.  Though I had resolved to say next to nothing
on this list I must poke in here.

Tla helped give birth to bzr.   Bzr is completely rewritten,
as far as I know.   Bzr is defined by large amounts of creative
contribution that have nothing to do with me.   But: tla
really helped lead to bzr, fairly directly.

The point is, that it does not disrespect the GNU Arch
project to consider GNU-izing and organizing around
bzr.   That is a technical question and it is a legal, economic
and ethical question about how the project will be run
in the future -- but, if I have any authority on the matter,
adopting bzr is not per se any kind of disloyalty to tla.

tla,
-t

Re: What a modern collaboration toolkit looks like

[Nick Roberts]

> David Matuszek (star CS professor at UPenn) has been griping at me
> for years about things like features he relied upon disappearing
> during version upgrades.  He's made it very clear that he thinks this
> sort of thing is a symptom of inattention to what users are actually
> doing with the software by developers too obsessed with the next cool
> hack.  I think that counts as both software and project croticism.

Do you know if he reported these things to the mailing list?  I think we need
a reality check here:  Emacs is a voluntary project, and if users aren't
prepared to make bug reports then it's unlikely that any version control
system, no matter how good, will allow a handful to developers to avoid such
pitfalls.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: What a modern collaboration toolkit looks like

[Eric S. Raymond]

Nick Roberts <nickrob@snap.net.nz>:
> Do you know if he reported these things to the mailing list?  I think we need
> a reality check here:  Emacs is a voluntary project, and if users aren't
> prepared to make bug reports then it's unlikely that any version control
> system, no matter how good, will allow a handful to developers to avoid such
> pitfalls.

I do not know whether he reported them.  I think it likely that he did.

And, yes, users who don't report bugs is indeed one of exceedingly many problems
a better VCS and collaboration tools won't solve.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: What a modern collaboration toolkit looks like

[Trey Jackson]

 ESR wrote:
 > This started out as part of a longer essay called "On not kissing the pig".
 > But that essay grew into an epic.  Rather than dump it on the list all 
 > at once, I think it will be useful if I start by giving everybody a
 > clear idea of the potential benefits of changing our practices.

IMO, the development environment Emacs provides is very indicative of the
environment used to develop Emacs.  Namely, communication is email, and VCS
is CVS.  Those things work very well inside Emacs.

ESR is pointing out that many folks have moved on to ... more sophisticated
development methodologies (not saying better), and that, in comparison,
Emacs seems antiquated.

My take on the lessons to take from this thread (never saw ESR's promised
lessons rant):

Goal: Make changes in the way Emacs is developed in order to
1) enable more responsive Emacs development/releases
2) make Emacs development (and by extension Emacs) more attractive to new folks

For example, moving to a new VCS would ensure that the Emacs/VCS integration
works properly.  As ESR (?) found out, Emacs' version control interface
didn't map well into the newer VCSs - thereby prompting the recent rewrite.

What else could be done?  One might work on an IDE *framework* that is
useful for Emacs developers as well as other projects?  Components might
include coupling between:

- development system (code, build, run, debug, code browsing)
- version control
- bug tracking
- communication (email, IRC, web)
- task management (todo.el, planner.el)

gud.el and vc.el are examples of similar work.  Perhaps it's time for ide.el?


To be clear, I'm not advocating moving to new VCS, bug tracking system, IRC,
or *anything* just to be "hip" and "cool."  Every change must provide
benefit.  It seems that the VCS discussion has revealed some benefits found
in the newer VCSs that might be (are?) attractive to RMS & others.


So... one possible conclusion is to work on an IDE framework that can be
used by Emacs developers and potentially extended by others.

For example, concrete steps that could be taken by Emacs development team:

1) move to new VCS
   -> ensures Emacs integration with new VCS works well
2) move to bug tracking system
   -> develop IDE hooks to coordinate bug system with VCS
3) integrate communication system with bug system/VCS
   -> IDE hooks auto-communicate check-ins with email/chat
   -> hooks for analyzing communication and interacting with VC/bug tracking


Someone might then see the above framework and decide to add hooks to
integrate with planner.el to assist in task management... 


Again, I'm not advocating making any specific changes (I'm sure I have no
standing in this group as I am unknown).  Just trying to pull together where
I think this thread can lead.


TJ

ps. I think it's always good to reflect on how one approaches their tasks -
even if no changes occur.  It sounds like that's what is happening with Emacs
development.

-- 
Trey Jackson
bigfaceworm@gmail.com

"...all those moments will be lost in time
 like tears in the rain.
 Time to die."
-- Roy Batty

Re: What a modern collaboration toolkit looks like

[dhruva]

Hi,
 Though a trivial issue that many of you might not be affected (but I
am). Ability to access CVS from corporate firewalls. I did try to
inquire why system administrators block the port 2401. The standard
answer I got was they block all ports and enable/allow only those
vital (or bare minimum) ports that are required. Since I spend most
part of my time working in the corporate firewall, I would like to
have a VCS that alows me access through normal (HTTP/HTTPS) ports that
are normally open in most corporate firewalls. I am fortunate to have
a laptop that I take home and update from CVS from time to time. For
updating at work, I use the mercurial repository (HEAD branch only). I
have tried the GIT repo too and it got corrupted and I never tried to
recover it.

 I do agree this cannot be the sole reason to change the VCS but would
solve a major problem for me.

with best regards,
dhruva

-- 
Contents reflect my personal views only!

Re: What a modern collaboration toolkit looks like

[Eli Zaretskii]

> Date: Fri, 4 Jan 2008 15:16:28 +0530
> From: dhruva <dhruvakm@gmail.com>
> 
>  Though a trivial issue that many of you might not be affected (but I
> am). Ability to access CVS from corporate firewalls. I did try to
> inquire why system administrators block the port 2401.

CVS over SSH does not use 2401, it uses SSH port 22.  Does your
firewall block that as well?

> Since I spend most part of my time working in the corporate
> firewall, I would like to have a VCS that alows me access through
> normal (HTTP/HTTPS) ports that are normally open in most corporate
> firewalls.

I once had similar problems, and the gnu.org maintainers set up CVS
access through such ports; perhaps it's still there.  It all ceased to
be a problem for me when Subversion started using SSH, and I found
that most firewalls don't block SSH ports.

Re: What a modern collaboration toolkit looks like

[dhruva]

Hello,

On Jan 5, 2008 7:06 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> > Date: Fri, 4 Jan 2008 15:16:28 +0530
> > From: dhruva <dhruvakm@gmail.com>
> >
> >  Though a trivial issue that many of you might not be affected (but I
> > am). Ability to access CVS from corporate firewalls. I did try to
> > inquire why system administrators block the port 2401.
>
> CVS over SSH does not use 2401, it uses SSH port 22.  Does your
> firewall block that as well?

That is one of among the first they block as port 22 and SSH gives a
shell access to a remote machine.

> > normal (HTTP/HTTPS) ports that are normally open in most corporate
> > firewalls.
>
> I once had similar problems, and the gnu.org maintainers set up CVS
> access through such ports; perhaps it's still there.  It all ceased to

Savannah has a SSH running on 443 which I can use as I have commit
access but this will not work for the general public. There is no
anonymous access.


> be a problem for me when Subversion started using SSH, and I found
> that most firewalls don't block SSH ports.

Most corporate firewalls do block SSH port for following reasons.
1. It gives you a shell access to a remote machine out of their network
2. Since it is encrypted connection with your private key, they cannot
sniff out the contents!

So far, I have worked for 5 different employers and all of them block
port 22 and 2401 (and a bunch of other ports used by IRC, NNTP,
Yahoo/Gtalk/MSN chat...). Due to this, I was unable to take part in
some of the developer chatter on IRC.

-dky

-- 
Contents reflect my personal views only!

Re: What a modern collaboration toolkit looks like

[Eli Zaretskii]

> Date: Sat, 5 Jan 2008 20:34:22 +0530
> From: dhruva <dhruvakm@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> > CVS over SSH does not use 2401, it uses SSH port 22.  Does your
> > firewall block that as well?
> 
> That is one of among the first they block as port 22 and SSH gives a
> shell access to a remote machine.

??? That's only a danger if (1) there's an sshd installed and enabled
on the target, and (2) the intruders have them set up as legitimate
users on the target, i.e. they sent their key to the sysadmins and
those sysadmins did the necessary setup.

Am I missing something here?

Re: What a modern collaboration toolkit looks like

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
> CVS over SSH does not use 2401, it uses SSH port 22.  Does your
> firewall block that as well?

Many companies seem to block _all_ ports by default, and only unblock
something if you can convince them that it's justified, where
"justified" is interpreted rather narrowly ("it will make my life more
pleasant" usually doesn't count of course)...

They can't block http and https of course, because everybody would quit.

-Miles

-- 
`Life is a boundless sea of bitterness'

Re: What a modern collaboration toolkit looks like

[Gianluca Della Vedova]

Trey Jackson <bigfaceworm <at> gmail.com> writes:


> Goal: Make changes in the way Emacs is developed in order to
> 1) enable more responsive Emacs development/releases
> 2) make Emacs development (and by extension Emacs) more attractive to new folks
> 
IMHO the single most important step for achieving (2) is switching to a modern
bug tracker. I believe I am representative of a large set of Emacs users that
are willing to fill in bug reports and maybe send documentation and/or trivial
patches, but I find the current state too cumbersome and the environment might
be intimidating sometimes.

Moreover a real bug tracker gives a clear (to outsiders like me) idea of which
bugs could be fixed also by newcomers, hence easing their entrance into the
Emacs development world.

At http://amortizedanalysis.wordpress.com/2008/01/04/emacs-development/ I have
written a more detailed (and more boring) article on some possible improvements
(IMHO).

Hope to help,

--
Gianluca

Re: What a modern collaboration toolkit looks like

[Richard Stallman]

gud.el was the beginning of an Emacs IDE.
Nick Roberts has greatly extended its capabilities
in Emacs 22.  What more should we add?

Re: What a modern collaboration toolkit looks like

[Trey Jackson]

[-- Attachment #1.1: Type: text/plain, Size: 1354 bytes --]

On Jan 5, 2008 6:30 AM, Richard Stallman <rms@gnu.org> wrote:

> gud.el was the beginning of an Emacs IDE.
> Nick Roberts has greatly extended its capabilities
> in Emacs 22.  What more should we add?
>

The graphical improvements to GUD are nice, but as far as I can see, the new
features are limited to viewing GUD data.
The other things that could be added are being discussed, and I thought I'd
listed a couple of possibilities.

project management (files & build)
bug tracking (see the other threads)
task management (planner.el, todo-mode, etc.)
code browsing (yes, it exists, but as add-ons)
manage window configurations (Eclipse calls them perspectives)
integrating profiling tools - and analyzing the results


An IDE can be so much more than a debugger.
And, yes, Emacs can run make, launch the application, debug the application,
send email.
But an organization of those capabilities (and more) might lead to something
greater than the sum of the parts.

Again, I'm only suggesting to think about such items, and if the emacs
developers would see pieces that are useful to themselves, then do it.  I
think someone who develops software tools s/he doesn't use her/himself leads
to useless tools.


TJ

-- 
Trey Jackson
bigfaceworm@gmail.com
"Like any truly useful program, `hello' contains a built-in mail reader."
-- GNU's Bulletin, July 1996

[-- Attachment #1.2: Type: text/html, Size: 1786 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: What a modern collaboration toolkit looks like

[Nick Roberts]

 > The graphical improvements to GUD are nice, but as far as I can see, the new
 > features are limited to viewing GUD data.
 > The other things that could be added are being discussed, and I thought I'd
 > listed a couple of possibilities.
 > 
 > project management (files & build)
 > bug tracking (see the other threads)
 > task management (planner.el, todo-mode, etc.)
 > code browsing (yes, it exists, but as add-ons)
 > manage window configurations (Eclipse calls them perspectives)
 > integrating profiling tools - and analyzing the results
 > 
 > 
 > An IDE can be so much more than a debugger.
 >...

If you are offering to write code to do some of these tasks that's great.  If
not, then the danger of making the discussion so general is that it detracts
from the specific proposals and nothing gets done.  I think the priority must
be first to use a modern bug tracker and VCS for Emacs development.
Integrating these and other features into Emacs are more substantial tasks that
can be done when volunteers are found.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: What a modern collaboration toolkit looks like

[Trey Jackson]

[-- Attachment #1.1: Type: text/plain, Size: 2158 bytes --]

On Jan 5, 2008 10:58 PM, Nick Roberts <nickrob@snap.net.nz> wrote:

> If you are offering to write code to do some of these tasks that's great.
>  If
> not, then the danger of making the discussion so general is that it
> detracts
> from the specific proposals and nothing gets done.  I think the priority
> must
> be first to use a modern bug tracker and VCS for Emacs development.
> Integrating these and other features into Emacs are more substantial tasks
> that
> can be done when volunteers are found.


It's good to have priorities.

My point was simply that an IDE is (often) more than a disparate collection
of utilities.  Emacs has a set of powerful utilities, but when a user sits
down to Emacs and opens up a C/C++/elisp/whatever source file, s/he just
gets that file.

In other IDEs (Eclipse, Kdevelop, MSVStudio, whatever), there's a wider
array of functionality presented to the user: build system, class browsing,
bug tracking, etc...  If a goal is to make Emacs development attractive to
new folks, one way might be to make Emacs present more of an IDE.  Why do
people like Kdevelop, MSVS, Eclipse, etc.?  I don't really know - I only use
Emacs, I'm just saying it might be useful to take a step back and think
about it.

The discussion regarding VCS and bug tracking is great, and I'm sure that'd
help both emacs-devel and to attract newer developers.

As I said in each of the previous email, I'm not telling emacs-devel to run
out and implement an IDE framework, but instead, just think about it - MAYBE
it is something that emacs-devel would find useful to use.

From the discussion, it doesn't sound like people have taken a step back to
see what might be changed about emacs-devel in a long time, and ESR's
initial email was a good catalyst.  Perhaps someone will think about other
IDE functionality and be inspired.  If so, great, if not, no big deal.  But
to shut your ears to even thinking about it b/c I haven't ponied up
resources to do something (that hasn't even been proposed)...

TJ

-- 
Trey Jackson
bigfaceworm@gmail.com
"Like any truly useful program, `hello' contains a built-in mail reader."
-- GNU's Bulletin, July 1996

[-- Attachment #1.2: Type: text/html, Size: 2671 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: What a modern collaboration toolkit looks like

[Nick Roberts]

 > > If you are offering to write code to do some of these tasks that's great.
 > >  If not, then the danger of making the discussion so general is that it
 > >  detracts from the specific proposals and nothing gets done.  I think the
 > >  priority must be first to use a modern bug tracker and VCS for Emacs
 > >  development.  Integrating these and other features into Emacs are more
 > >  substantial tasks that can be done when volunteers are found.
 > 
 > 
 > It's good to have priorities.
 > 
 > My point was simply that an IDE is (often) more than a disparate collection
 > of utilities. 
 >...

If that was your point then perhaps you should start a new thread.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: What a modern collaboration toolkit looks like

[Richard Stallman]

    The graphical improvements to GUD are nice, but as far as I can see, the new
    features are limited to viewing GUD data.

Isn't that what an IDE is?  Something to let you look at execution
data and source code in a convenient coordinated way?

    project management (files & build)

What does that mean?  Is it some alternative to makefiles?

    bug tracking (see the other threads)
    task management (planner.el, todo-mode, etc.)
    code browsing (yes, it exists, but as add-ons)
    manage window configurations (Eclipse calls them perspectives)

I would like to know more about this.  Emacs lacks convenient features
to usefully save and adjust window configurations, and it would be nice
to add that as a general feature.

Re: What a modern collaboration toolkit looks like

[Trey Jackson]

[-- Attachment #1.1: Type: text/plain, Size: 2467 bytes --]

On Jan 6, 2008 10:09 AM, Richard Stallman <rms@gnu.org> wrote:

>    The graphical improvements to GUD are nice, but as far as I can see,
> the new
>    features are limited to viewing GUD data.
>
> Isn't that what an IDE is?  Something to let you look at execution
> data and source code in a convenient coordinated way?


As in my other email, an IDE is often more - pulling together bug tracking,
plug-ins for profilers, code browsers, project planning, etc.  The improved
GUD is nice, but other IDEs have a lot more.   (if you want to want to go
that route))


>    project management (files & build)
>
> What does that mean?  Is it some alternative to makefiles?
>

Yeah, a number of IDEs have this (GreenHills, MSVS).  I find them awkward
and confusing.  My understanding is that the IDE then knows about all the
files in the 'project' and can automatically generate tags, do class
browsing, and other such things.

I only mentioned that because it's functionality that exists elsewhere.  I
don't see a use for it in GNU tools.


>    bug tracking (see the other threads)
>    task management (planner.el, todo-mode, etc.)
>    code browsing (yes, it exists, but as add-ons)
>    manage window configurations (Eclipse calls them perspectives)
>
> I would like to know more about this.  Emacs lacks convenient features
> to usefully save and adjust window configurations, and it would be nice
> to add that as a general feature.
>

I don't know much about it, just that it appears that you can set up window
configurations for each task, e.g. the window arrangement for the new
GUD-ui, one for actually coding (perhaps with class browser (ECB?)), one for
interacting with VCS, etc.  This does appear to be a high return on
investment kind of project.

One page for documentation on it is:
http://wiki.eclipse.org/FAQ_How_do_I_create_fixed_views_and_perspectives%3Fwhich
gives a sense that you can have fixed configurations and changeable...
This may involve more of a "mode" approach to interacting with Emacs, but
that could be OK given the complex tasks being acted on in these
situations.  I never looked at Gnus to see how it manages window
configurations (nor gud-ui, nor...)


side note: this is why I brought up the whole IDE subject, because perhaps
some of the functionality would be found to be useful...

TJ

-- 
Trey Jackson
bigfaceworm@gmail.com
"Like any truly useful program, `hello' contains a built-in mail reader."
-- GNU's Bulletin, July 1996

[-- Attachment #1.2: Type: text/html, Size: 3501 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: What a modern collaboration toolkit looks like

[Nick Roberts]

Trey Jackson writes:
 > On Jan 6, 2008 10:09 AM, Richard Stallman <rms@gnu.org> wrote:
 > 
 > >    The graphical improvements to GUD are nice, but as far as I can see,
 > > the new
 > >    features are limited to viewing GUD data.
 > >
 > > Isn't that what an IDE is?  Something to let you look at execution
 > > data and source code in a convenient coordinated way?
 > 
 > 
 > As in my other email, an IDE is often more - pulling together bug tracking,
 > plug-ins for profilers, code browsers, project planning, etc.  The improved
 > GUD is nice, but other IDEs have a lot more.   (if you want to want to go
 > that route))

Projects like Eclipse will always have "a lot more" because they have millions
of dollars of investment behind them.

 > >    project management (files & build)
 > >
 > > What does that mean?  Is it some alternative to makefiles?
 > >
 > 
 > Yeah, a number of IDEs have this (GreenHills, MSVS).  I find them awkward
 > and confusing.  My understanding is that the IDE then knows about all the
 > files in the 'project' and can automatically generate tags, do class
 > browsing, and other such things.

And if you want to move your code to another IDE presumably it's difficult
because the metadata storing the project information is unique to each IDE.

 >...
 > >    manage window configurations (Eclipse calls them perspectives)
 > >
 > > I would like to know more about this.  Emacs lacks convenient features
 > > to usefully save and adjust window configurations, and it would be nice
 > > to add that as a general feature.
 > >
 > 
 > I don't know much about it, just that it appears that you can set up window
 > configurations for each task, e.g. the window arrangement for the new
 > GUD-ui, one for actually coding (perhaps with class browser (ECB?)), one for
 > interacting with VCS, etc.  This does appear to be a high return on
 > investment kind of project.

Eclipse can use perspectives because it's an IDE, and no more: the user can't
suddenly decide to write an e-mail, read news or view images.  I know
ECB uses dedicated windows just like gdb-ui.el to constrain the display, I'm
not sure that they would work well together.  It may be a high return but I
don't think it's a trivial task to make something workable.

 > ...
 > side note: this is why I brought up the whole IDE subject, because perhaps
 > some of the functionality would be found to be useful...

I don't think anyone would disagree.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: What a modern collaboration toolkit looks like

[Stefan Monnier]

[ ...blabla ... IDE ... blabla ... IDE ...]

Please change the title of your this thread,


        Stefan

Re: What a modern collaboration toolkit looks like

[Werner LEMBERG]

I'm not sure whether this has come up before, but here you can find
links where Keith Packard discusses the reasons why he selected git
for X.org

  http://keithp.com/blogs/Tyrannical_SCM_selection/
  http://keithp.com/blogs/Repository_Formats_Matter/


     Werner