Re: Emacs-devel Digest, Vol 47, Issue 14

Re: Emacs-devel Digest, Vol 47, Issue 14

[Eric S. Raymond]

From: David Kastrup <dak@gnu.org>
> 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.

I don't think you need to worry too hard.  Conversions among git, bzr 
and hg are easy and (if the documentation to be ebelieved) lossless. Thus,
if we chose any one of them and regretted it, we won't have a lot of 
trouble switching to either of the others later on.

From: Ted Zlatanov <tzz@lifelogs.com>
> Has there ever been an ELisp-based VCS?  Should we at least consider it?

I think not.  The existing designs seem to be of high quality.
This wheel doesn't need to be reinvented.

From: ?scar Fuentes <ofv@wanadoo.es>
> Subject: Re: What a modern collaboration toolkit looks like
> To: emacs-devel@gnu.org
> Message-ID: <tzlw2thp.fsf@telefonica.net>
> Content-Type: text/plain; charset=us-ascii
> 
> 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 agree with both these criticisms.  git's interface is rather baroque;
not pull-your-hair-out awful like Arch's, but not good.
 
> I'll suggest you use Mercurial for learning what a decentralized VCS can do.

I second this recommendation.  I am not yet sure Mercurial is the
overall best-of-breed, but it is the most accessible of the big three
(git, bzr, hg) and seems to have the best UI design.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Emacs-devel Digest, Vol 47, Issue 14

[David Kastrup]

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

> I second this recommendation.  I am not yet sure Mercurial is the
> overall best-of-breed, but it is the most accessible of the big three
> (git, bzr, hg) and seems to have the best UI design.

Before making a decision, one should try the candidates on the Emacs
repository data which will constitute our real workload.

The Emacs history is very unusual in size and structure.  If a system
becomes glacially slow for common operations, or swallows inordinate
amounts of disk space, memory or bandwidth, this will seriously impact
the usability.

Actually, this needs to be checked under different operating systems
(and their file systems) too.  At least with git, the profiling and
tuning of the operations happens mostly on GNU/Linux and this shows.

-- 
David Kastrup

Re: Emacs-devel Digest, Vol 47, Issue 14

[Eric S. Raymond]

David Kastrup <dak@gnu.org>:
> "Eric S. Raymond" <esr@thyrsus.com> writes:
> 
> > I second this recommendation.  I am not yet sure Mercurial is the
> > overall best-of-breed, but it is the most accessible of the big three
> > (git, bzr, hg) and seems to have the best UI design.
> 
> Before making a decision, one should try the candidates on the Emacs
> repository data which will constitute our real workload.

Agreed.  In fact, you may have solved a problem for me by pointing
this out -- I've been casting around for a large real-world codebase to
do comparative benchmarks against, and Emacs might do nicely.
 
> The Emacs history is very unusual in size and structure. 

It's larger than most, certainly.  What do you mean by unusual 
in "structure"?

> Actually, this needs to be checked under different operating systems
> (and their file systems) too.  At least with git, the profiling and
> tuning of the operations happens mostly on GNU/Linux and this shows.

Yes, performance on other systems is reputed to be poor.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Emacs-devel Digest, Vol 47, Issue 14

[David Kastrup]

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

> David Kastrup <dak@gnu.org>:
>> "Eric S. Raymond" <esr@thyrsus.com> writes:
>> 
>> > I second this recommendation.  I am not yet sure Mercurial is the
>> > overall best-of-breed, but it is the most accessible of the big three
>> > (git, bzr, hg) and seems to have the best UI design.
>> 
>> Before making a decision, one should try the candidates on the Emacs
>> repository data which will constitute our real workload.
>
> Agreed.  In fact, you may have solved a problem for me by pointing
> this out -- I've been casting around for a large real-world codebase to
> do comparative benchmarks against, and Emacs might do nicely.
>  
>> The Emacs history is very unusual in size and structure. 
>
> It's larger than most, certainly.  What do you mean by unusual 
> in "structure"?

Very long, linear branches, very small commit granularity, no rename or
merge information except in the logs.  For the final import, one will
want to extract this information in some manner or other (most but not
all of the currently missing information should have originated from
Miles' arch repository and can possibly be reclaimed from there, too).

-- 
David Kastrup

Re: Emacs-devel Digest, Vol 47, Issue 14

[Eric S. Raymond]

David Kastrup <dak@gnu.org>:
> Very long, linear branches, very small commit granularity, no rename or
> merge information except in the logs.

OK.  None of this actually strikes me as really unusual.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Emacs-devel Digest, Vol 47, Issue 14

[Sascha Wilde]

David Kastrup <dak@gnu.org> wrote:

> "Eric S. Raymond" <esr@thyrsus.com> writes:
>
>> I second this recommendation.  I am not yet sure Mercurial is the
>> overall best-of-breed, but it is the most accessible of the big three
>> (git, bzr, hg) and seems to have the best UI design.
>
> Before making a decision, one should try the candidates on the Emacs
> repository data which will constitute our real workload.

FWIW: I maintain an hg mirror of emacs head and my personal emacs branch
here:  http://hg.intevation.org/
so testing mercurial with real world Emacs data is simple...

cheers
sascha
-- 
Sascha Wilde   -.-. ..- .-. .. --- ... .. - -.-- 
               -.- .. .-.. .-.. . -.. 
               - .... .
               -.-. .- -

Re: Emacs-devel Digest, Vol 47, Issue 14

[Martin Geisler]

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

Sascha Wilde <wilde@sha-bang.de> writes:

> David Kastrup <dak@gnu.org> wrote:
>
>> "Eric S. Raymond" <esr@thyrsus.com> writes:
>>
>>> I second this recommendation. I am not yet sure Mercurial is the
>>> overall best-of-breed, but it is the most accessible of the big
>>> three (git, bzr, hg) and seems to have the best UI design.
>>
>> Before making a decision, one should try the candidates on the Emacs
>> repository data which will constitute our real workload.
>
> FWIW: I maintain an hg mirror of emacs head and my personal emacs
> branch here: http://hg.intevation.org/
> so testing mercurial with real world Emacs data is simple...

Cool! Cloning this took 14 minutes and gave me 86115 revisions with the
story back to 1985. That is steady stream of 11 commits every day! :-)

The repository alone uses 143 MiB. Quite comfortable after 22 years of
development, IMHO. I don't know how much data the mirror is missing in
other branches, though.

The working copy for the current tip uses 97 MiB.

-- 
Martin Geisler

VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multi-Party Computation) to Python. See: http://viff.dk/.

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 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: Emacs-devel Digest, Vol 47, Issue 14

[Sascha Wilde]

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

Martin Geisler <mgeisler@mgeisler.net> wrote:
> Sascha Wilde <wilde@sha-bang.de> writes:
>> FWIW: I maintain an hg mirror of emacs head and my personal emacs
>> branch here: http://hg.intevation.org/
>> so testing mercurial with real world Emacs data is simple...
>
> Cool! Cloning this took 14 minutes and gave me 86115 revisions with the
> story back to 1985. That is steady stream of 11 commits every day! :-)

:-)

> The repository alone uses 143 MiB. Quite comfortable after 22 years of
> development, IMHO. I don't know how much data the mirror is missing in
> other branches, though.

The repository currently only contains a mirror of HEAD.

I will make a complete mirror containing all branches available
eventually, but this needs other tools than those I'm currently using
and will take a serious amount of time for the initial conversion...

cheers
sascha
-- 
Sascha Wilde
Nota bene: wenn Word für Längeres geeignet wäre, würde es schließlich
nicht Word, sondern Sentence, Page oder Article heißen
 	-- Matthias Mühlich in dctt

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 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

Mercurial CVS mirror (was: Emacs-devel Digest, Vol 47, Issue 14)

[Martin Geisler]

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

Sascha Wilde <wilde@sha-bang.de> writes:

> Martin Geisler <mgeisler@mgeisler.net> wrote:
>> Sascha Wilde <wilde@sha-bang.de> writes:
>
> The repository currently only contains a mirror of HEAD.
>
> I will make a complete mirror containing all branches available
> eventually, but this needs other tools than those I'm currently using
> and will take a serious amount of time for the initial conversion...

Yeah, I can imagine. But thanks for converting HEAD, it's fun to see so
much data in Mercurial, especially data going so far back in time.

-- 
Martin Geisler

VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multi-Party Computation) to Python. See: http://viff.dk/.

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 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