It's not yet time to anoint git, or anything else

It's not yet time to anoint git, or anything else

[Eric S. Raymond]

I'm glad there is active discussion of distributed VCSes happening 
on the list, as I strongly believe we should move to one in the 
near future.  

But I think it's worth noting that pretty much all the good things
being said about git apply equally to other DVCSes such as Mercurial, bzr,
monotone, darcs, and Codeville.  All of these have very similar basic
models based on commit-before-merge and push/pull operations.  

It is not yet time to anoint git (or anything else) as a winner, even
by implication.  We will need to carefully consider the strengths and
weaknesses of each of these systems in relation to the specific needs
of the Emacs project.

I am working on an in-depth technical survey of this space.  You
can pull it at from a Mercurial repo at <http://thyrsus.com/hg/uvc/>.
As that indicates, I am leaning towards Mercurial for my own work --
but I intend to do a lot of research and testing before making a
final decision, and the results of my research will go into
that paper.

So far, I have done comparative evaluations of SCCS, RCS, CVS,
Subversion, Arch, and Monotone.  I intend to do similar ones of SVK,
git, bzr, darcs, Mercurial, and Codeville.  If I can get an evaluation
copy I will do Bitkeeper as well -- yes, it has a closed--source
license and there is thus no way I would recommend it, but it is of
some historical importance.

I also intend to write a test suite that will exercises all of these
in some known problem areas, especially near renames.  If I can 
come up with any way to do meaningful benchmarks, I will do that too.

So far, the only conclusion I am prepared to assert is that monotone,
darcs, and Codeville are not at present production-quality tools. I
am surveying them anyway because they have some important ideas in
them, and it is possible that they might become production-quality
tools in the future.

This leaves git, bzr, and Mercurial as near-term candidates for
production use from among the DVCSes.  All three have strikingly
similar functional models, though git is perhaps a bit more distant
from Mercurial and bzr than the latter two are from each other.

When my survey is done, we'll be in an extremely strong position to
make a selection based on hard facts and rigorous comparative analysis.
Until then, it's not time to choose among them or get too attached 
to any particular one.

(I would, by the way, welcome collaborators and reviewers to help
finish the survey.  It's a large job.  More hands would help.)
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

"Say what you like about my bloody murderous government," I says,
"but don't insult me poor bleedin' country."	-- Edward Abbey

Re: It's not yet time to anoint git, or anything else

[Miles Bader]

"Eric S. Raymond" <esr@snark.thyrsus.com> writes:
> When my survey is done, we'll be in an extremely strong position to
> make a selection based on hard facts and rigorous comparative analysis.

That's a pipe-dream, Eric.

-Miles

-- 
My spirit felt washed.  With blood.  [Eli Shin, on "The Passion of the Christ"]

Re: It's not yet time to anoint git, or anything else

[Ted Zlatanov]

On Wed,  2 Jan 2008 08:24:58 -0500 (EST) "Eric S. Raymond" <esr@snark.thyrsus.com> wrote: 

ESR> But I think it's worth noting that pretty much all the good things
ESR> being said about git apply equally to other DVCSes such as Mercurial, bzr,
ESR> monotone, darcs, and Codeville.  All of these have very similar basic
ESR> models based on commit-before-merge and push/pull operations.  

Has there ever been an ELisp-based VCS?  Should we at least consider it?
The advantages are significant for this group of developers, and it
would certainly benefit other users.  The major disadvantage (besides
having to write the code), I imagine, is incompatibility with other
VCSs, and that can be addressed by a bridge to CVS/Git/Arch/etc as
deemed appropriate (similar to the git-svn bridge).

Ted

Re: It's not yet time to anoint git, or anything else

[Tassilo Horn]

Ted Zlatanov <tzz@lifelogs.com> writes:

Hi Ted,

> ESR> But I think it's worth noting that pretty much all the good
> ESR> things being said about git apply equally to other DVCSes such as
> ESR> Mercurial, bzr, monotone, darcs, and Codeville.  All of these
> ESR> have very similar basic models based on commit-before-merge and
> ESR> push/pull operations.
>
> Has there ever been an ELisp-based VCS?  Should we at least consider
> it?  The advantages are significant for this group of developers, and
> it would certainly benefit other users.  The major disadvantage
> (besides having to write the code), I imagine, is incompatibility with
> other VCSs, and that can be addressed by a bridge to CVS/Git/Arch/etc
> as deemed appropriate (similar to the git-svn bridge).

I'd say that this would be a monster-job where we simply don't have the
man-power to do that.  And I don't see what those significant advantages
would be.  Could you elaborate on that?

IMO an elisp solution would bring at least those drawbacks:

  - huge effort to write and maintain it
  - since we get it right and reliable it may take very long
  - worse performance than a highly optimized C solution
  - since emacs is single-threaded any VC operation would block emacs

So my opinion is that we'd be better off to use one of the excellent
existing dVCSs.

Bye,
Tassilo

Re: It's not yet time to anoint git, or anything else

[David Kastrup]

Tassilo Horn <tassilo@member.fsf.org> writes:

> Ted Zlatanov <tzz@lifelogs.com> writes:
>
> Hi Ted,
>
>> ESR> But I think it's worth noting that pretty much all the good
>> ESR> things being said about git apply equally to other DVCSes such as
>> ESR> Mercurial, bzr, monotone, darcs, and Codeville.  All of these
>> ESR> have very similar basic models based on commit-before-merge and
>> ESR> push/pull operations.
>>
>> Has there ever been an ELisp-based VCS?  Should we at least consider
>> it?  The advantages are significant for this group of developers, and
>> it would certainly benefit other users.  The major disadvantage
>> (besides having to write the code), I imagine, is incompatibility with
>> other VCSs, and that can be addressed by a bridge to CVS/Git/Arch/etc
>> as deemed appropriate (similar to the git-svn bridge).
>
> I'd say that this would be a monster-job where we simply don't have
> the man-power to do that.

git consists of low-level commands (plumbing) and user-level commands
(porcelain).  The plumbing can be used for implementing a number of
different workflows if one wants to.

-- 
David Kastrup

Re: It's not yet time to anoint git, or anything else

[Ted Zlatanov]

On Wed, 02 Jan 2008 15:54:36 +0100 Tassilo Horn <tassilo@member.fsf.org> wrote: 

TH> Ted Zlatanov <tzz@lifelogs.com> writes:

>> Has there ever been an ELisp-based VCS?  Should we at least consider
>> it?  The advantages are significant for this group of developers, and
>> it would certainly benefit other users.  The major disadvantage
>> (besides having to write the code), I imagine, is incompatibility with
>> other VCSs, and that can be addressed by a bridge to CVS/Git/Arch/etc
>> as deemed appropriate (similar to the git-svn bridge).

TH> I'd say that this would be a monster-job where we simply don't have the
TH> man-power to do that.  And I don't see what those significant advantages
TH> would be.  Could you elaborate on that?

- clean VC mode integration
- no extra utilities
- self-contained, extensible code
- designed to meet the developers' needs
- most of us like ELisp better than the other languages used to implement VCSs 

I'm sure we could come up with more, but I thought the above were
obvious so I didn't list them explicitly.

TH> IMO an elisp solution would bring at least those drawbacks:

TH>   - huge effort to write and maintain it

I don't think the effort is *huge* since there's so many existing VCS
implementations.  It's certainly not trivial and I already mentioned
that writing the code was a major disadvantage.

TH>   - since we get it right and reliable it may take very long

I didn't suggest it was an easy path, I only asked if we should consider
it.  So far everyone thinks we shouldn't, and that's a valid answer.  I
am glad we at least discussed it.

TH>   - worse performance than a highly optimized C solution

This is always a concern with ELisp code, and fortunately Emacs supports
linking to C functions and libraries when needed.

TH>   - since emacs is single-threaded any VC operation would block emacs

Yes, that's a significant drawback with any large-scale code implemented
in Emacs.

Thanks
Ted

Re: It's not yet time to anoint git, or anything else

[Tassilo Horn]

Ted Zlatanov <tzz@lifelogs.com> writes:

Hi Ted,

> TH>   - huge effort to write and maintain it
>
> I don't think the effort is *huge* since there's so many existing VCS
> implementations.  It's certainly not trivial and I already mentioned
> that writing the code was a major disadvantage.

I'm not sure here, but I don't think a reliable VCS is an easy task.  On
Linus' google talk he said that when he tried to choose an existing VCS
he could hardly find one that could guarantee that what comes out is
exactly as that was put in.  I don't know how trustworthy the statement
is, but it rings my alarm bells.

> TH>   - worse performance than a highly optimized C solution
>
> This is always a concern with ELisp code, and fortunately Emacs
> supports linking to C functions and libraries when needed.

Are you talking about that FFI patch that's pending because Richard
isn't sure about legal issues?

Bye,
Tassilo

Re: It's not yet time to anoint git, or anything else

[Ted Zlatanov]

On Wed, 02 Jan 2008 20:28:14 +0100 Tassilo Horn <tassilo@member.fsf.org> wrote: 

TH> Are you talking about that FFI patch that's pending because Richard
TH> isn't sure about legal issues?

No, just general C library and function use.

Ted

Re: It's not yet time to anoint git, or anything else

[Richard Stallman]

The free world is already doing pretty well in VCS development.
I don't think another VCS is a high priority.  I would encourage
people rather to put their effort into areas where we are behind.

Re: It's not yet time to anoint git, or anything else

[Alan Mackenzie]

Hi, Eric!

On Wed, Jan 02, 2008 at 08:24:58AM -0500, Eric S. Raymond wrote:
> I'm glad there is active discussion of distributed VCSes happening 
> on the list, as I strongly believe we should move to one in the 
> near future.  

Look forward to that!

> But I think it's worth noting that pretty much all the good things
> being said about git apply equally to other DVCSes such as Mercurial, bzr,
> monotone, darcs, and Codeville.  All of these have very similar basic
> models based on commit-before-merge and push/pull operations.  

As an aside, have you any idea why has this happened?  Having several
products essentially the same can give a good choice, but having many of
them is a waste of effort, both for those writing them, those evaluating
them, and those who have to relearn when moving from one of them to
another.  It will also surely confuse people, and thus disincline
projects from moving from (previously ;-) good systems like CVS.

> I am working on an in-depth technical survey of this space.  You
> can pull it at from a Mercurial repo at <http://thyrsus.com/hg/uvc/>.

Any chance of putting a copy up as a straight file?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: It's not yet time to anoint git, or anything else

[Miles Bader]

Alan Mackenzie <acm@muc.de> writes:
> As an aside, have you any idea why has this happened?  Having several
> products essentially the same can give a good choice, but having many of
> them is a waste of effort

Because people get attached to various features they like, and though all
these systems offer roughly _comparable_ models, they differ
significantly in the details.  People care about details, it turns out...

-Miles

-- 
A zen-buddhist walked into a pizza shop and
said, "Make me one with everything."

Re: It's not yet time to anoint git, or anything else

[Eric S. Raymond]

Alan Mackenzie <acm@muc.de>:
> > But I think it's worth noting that pretty much all the good things
> > being said about git apply equally to other DVCSes such as Mercurial, bzr,
> > monotone, darcs, and Codeville.  All of these have very similar basic
> > models based on commit-before-merge and push/pull operations.  
> 
> As an aside, have you any idea why has this happened?  Having several
> products essentially the same can give a good choice, but having many of
> them is a waste of effort, both for those writing them, those evaluating
> them, and those who have to relearn when moving from one of them to
> another.  It will also surely confuse people, and thus disincline
> projects from moving from (previously ;-) good systems like CVS.

I don't completely understand the history yet; that's one of the things
I'm researching and hope to document.  What seems to have happened is 
something like this:

1. Basic DVCS ideas were pioneered by BitKeeper and Arch between 1998
and 2002.  (However, the fundamental ideas have been around somewhat longer;
I myself floated a proposal for an Arch-like DVCS in 1995.  RMS may 
remember this, he was on the distribution list.)

2. A lot of people looked at Arch and BitKeeper, thought "Cool!" and
ran off in different experimental directions starting from those feature
sets.

3. One of those experiments was Monotone.  It introduced
commit-before-merge and the generalized DAG repo with revisions IDed
by cryptographic hash sometime before 2005.  (Graydon Hoare, monotone's
author, told me the Codeville guys arrived at the same ideas
independently.)

4. Monotone failed to take over the world essentially because its
performance sucked on the day the BitKeeper fiasco came to a head in
2005 and Linus rejected it.  (It got better, subsequently, but that
was too late.)

5. Subsequently, after 2005, bzr and git and Mercurial all picked up
on the basic ideas in the monotone design.  This is why they look
so similar to each other.  (darcs is a bit of a weird outlier.)

The reasons we now have three very similar post-monotone systems
rather than one are essentially political rather than technical.
I don't think all three are going to survive long-term.

> > I am working on an in-depth technical survey of this space.  You
> > can pull it at from a Mercurial repo at <http://thyrsus.com/hg/uvc/>.
> 
> Any chance of putting a copy up as a straight file?

Yes, but only when it gets to 0.9 level.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: It's not yet time to anoint git, or anything else

[Romain Francoise]

"Eric S. Raymond" <esr@snark.thyrsus.com> writes:

> It is not yet time to anoint git (or anything else) as a winner,
> even by implication.  We will need to carefully consider the
> strengths and weaknesses of each of these systems in relation to
> the specific needs of the Emacs project.

An important aspect for us is how well the system is supported on
Savannah.  Git has an advantage here because we already have an
official Git repo of Emacs on Savannah, with complete history dating
back to 1985.  We just have to make it read-write.

   http://git.sv.gnu.org/gitweb/?p=emacs.git

Re: It's not yet time to anoint git, or anything else

[David Kastrup]

Romain Francoise <romain@orebokech.com> writes:

> "Eric S. Raymond" <esr@snark.thyrsus.com> writes:
>
>> It is not yet time to anoint git (or anything else) as a winner,
>> even by implication.  We will need to carefully consider the
>> strengths and weaknesses of each of these systems in relation to
>> the specific needs of the Emacs project.
>
> An important aspect for us is how well the system is supported on
> Savannah.  Git has an advantage here because we already have an
> official Git repo of Emacs on Savannah, with complete history dating
> back to 1985.  We just have to make it read-write.
>
>    http://git.sv.gnu.org/gitweb/?p=emacs.git

I think that Miles' merge-commits should also be parsed from the log and
used as input data for git-filter-branch --parent-filter.  Once that is
done, git should be able to track all modification history to its
original source, even though we never had this information in CVS in the
first place.

This is one of the strongest points of gits in my opinion: it keeps only
a set of snapshots and a minimal ancestry graph (namely the parent
commits for each commit) for the commit history.  All the rest is
reconstructed on-demand.

And since we don't actually have this original data in our CVS archive,
git's ability to reconstruct this (which includes tracking the crutches
we have to use in lieu of file renames in CVS) is quite attractive.

-- 
David Kastrup

Re: It's not yet time to anoint git, or anything else

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> Romain Francoise <romain@orebokech.com> writes:
>> An important aspect for us is how well the system is supported on
>> Savannah.  Git has an advantage here because we already have an
>> official Git repo of Emacs on Savannah, with complete history dating
>> back to 1985.  We just have to make it read-write.
>>
>>    http://git.sv.gnu.org/gitweb/?p=emacs.git
>
> I think that Miles' merge-commits should also be parsed from the log and
> used as input data for git-filter-branch --parent-filter.  Once that is
> done, git should be able to track all modification history to its
> original source, even though we never had this information in CVS in the
> first place.

I'm still maintaining a git tree that contains all the arch merges.  I'm
using a modified git-cvsimport script that automatically grafts all
these merge points.

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: It's not yet time to anoint git, or anything else

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> I think that Miles' merge-commits should also be parsed from the log and
> used as input data for git-filter-branch --parent-filter.  Once that is
> done, git should be able to track all modification history to its
> original source, even though we never had this information in CVS in the
> first place.

I have now published my git mirror on repo.or.cz
<http://repo.or.cz/w/emacs.git>.  Note that this is a newly created
import, it won't have any objects in common with the mirror on Savannah.
It contains all the automatically detected merges plus a whole bunch of
manually grafted ones.

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: It's not yet time to anoint git, or anything else

[David Kastrup]

Andreas Schwab <schwab@suse.de> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> I think that Miles' merge-commits should also be parsed from the log and
>> used as input data for git-filter-branch --parent-filter.  Once that is
>> done, git should be able to track all modification history to its
>> original source, even though we never had this information in CVS in the
>> first place.
>
> I have now published my git mirror on repo.or.cz
> <http://repo.or.cz/w/emacs.git>.  Note that this is a newly created
> import, it won't have any objects in common with the mirror on Savannah.
> It contains all the automatically detected merges plus a whole bunch of
> manually grafted ones.

Perhaps we need to design a "Miles&more" procedure by which we will get
grafts generated automatically for the "official" git mirror from
appropriately formatted commit messages.  How did you implement the
grafts?  Will they survive cloning?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: It's not yet time to anoint git, or anything else

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> Perhaps we need to design a "Miles&more" procedure by which we will get
> grafts generated automatically for the "official" git mirror from
> appropriately formatted commit messages.

There are more differences between these trees than just the merges.  I
have also updated the list of authors, and due to the way cvsps works
some of the commits are in a slightly different order.

> How did you implement the grafts?  Will they survive cloning?

They are genuine merge commits.  

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: It's not yet time to anoint git, or anything else

[Eric S. Raymond]

Romain Francoise <romain@orebokech.com>:
> "Eric S. Raymond" <esr@snark.thyrsus.com> writes:
> 
> > It is not yet time to anoint git (or anything else) as a winner,
> > even by implication.  We will need to carefully consider the
> > strengths and weaknesses of each of these systems in relation to
> > the specific needs of the Emacs project.
> 
> An important aspect for us is how well the system is supported on
> Savannah.  Git has an advantage here because we already have an
> official Git repo of Emacs on Savannah, with complete history dating
> back to 1985.  We just have to make it read-write.
> 
>    http://git.sv.gnu.org/gitweb/?p=emacs.git

Hmmm...Romain, how is this maintained, is it with hook scripts from
the CVS repo?  Also, is ChangeLog information in the git history or as
separate files?

I believe lossless repo conversions to Mercurial and bzr from git are
possible.  And I seriously doubt the Savannah admins will refuse toi
support either if we request it.

So, this is very good news -- it will make moving easier.  But it
does not actually constrain what we choose.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: It's not yet time to anoint git, or anything else

[Romain Francoise]

"Eric S. Raymond" <esr@thyrsus.com> writes:

> Hmmm...Romain, how is this maintained, is it with hook scripts
> from the CVS repo?  Also, is ChangeLog information in the git
> history or as separate files?

The update process is just 'git cvsimport' run from cron every 30
minutes, I think.

Right now it's a direct conversion of the CVS repo, so the ChangeLog
files are still there and the git commit message is copied from the
corresponding CVS commit message.