all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: David Kastrup <dak@gnu.org>
To: rms@gnu.org
Cc: emacs-devel@gnu.org, jasonr@f2s.com,
	Paul Pogonyshev <pogonyshev@gmx.net>
Subject: Re: source repository
Date: Wed, 04 Jul 2007 08:52:11 +0200	[thread overview]
Message-ID: <86tzskpso4.fsf@lola.quinscape.zz> (raw)
In-Reply-To: <E1I5vmI-0001gF-8k@fencepost.gnu.org> (Richard Stallman's message of "Tue\, 03 Jul 2007 23\:43\:42 -0400")

Richard Stallman <rms@gnu.org> writes:

>     Oh.  A pity Emacs still uses so old system.  I got used to Subversion
>     lately.
>
> We did not switch to Subversion because the people who develop
> Subversion are not sympathetic to the ideas of the free software
> movement.  That is a sufficient reason, given that CVS works fine.

It doesn't for continuously managing multiple branches of development.
There is a reason why Miles does most of the work in that area using
arch.

And the sympathy of CVS developers does not buy us much when there is
no active development or bug fixes for our sakes.  Of course, we would
not want to depend on a system with unsympathetic developers when it
is likely that we will depend on their further support or when their
system is not licensed as free software (which more or less implies a
perpetual dependency).  The Linux/Bitkeeper situation was such a one.

I actually use the outcome of that clash, the git system, for managing
local multiple branches and merges, and it works quite well.  Since it
is completely decentralized (it does not require something like arch
tags and can even cater for the history of split files and functions
moved into different files), people can use it without the need of a
centralized repository.

However, git's exchange functions with Subversion are much better than
those interacting with CVS, so I actually prefer working on Subversion
to working on git, even though Subversion does not really offer better
merge support.

One major point going for git is merge tracking: it keeps track of how
you resolve merge failures, and can apply the same solution when
merging branches in a similar situation.

git's developers, it being the Linux kernel source management system,
are a diverse bunch, mostly tending to agnosticism towards the cause
of free software.  However, they are responsive about problem reports,
and they have to use the system actively to manage a large-scale
multi-person project with lots of branching and sand-boxed
development.  And git is released as free software (GPLv2 rather than
Subversion's Apache/BSD).  Personally, I consider the "anarchism" of
it, namely that it is actually more or less each developer's personal
choice, not dependent on a central repository, whether or not he uses
git for working with others and preparing patches, an advantage.

-- 
David Kastrup

  reply	other threads:[~2007-07-04  6:52 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-03 11:42 source repository Paul Pogonyshev
2007-07-03 11:57 ` Jason Rumney
2007-07-03 12:14   ` Paul Pogonyshev
2007-07-03 12:57     ` dhruva
2007-07-03 19:57       ` Karl Fogel
2007-07-04  4:18         ` dhruva
2007-07-03 19:43     ` Eli Zaretskii
2007-07-04  4:26       ` Stephen J. Turnbull
2007-07-04  5:09         ` Nick Roberts
2007-07-04  7:01           ` David Kastrup
2007-07-04  7:14             ` dhruva
2007-07-04  7:33               ` David Kastrup
2007-07-04  9:13           ` Stephen J. Turnbull
2007-07-05  1:30             ` Richard Stallman
2007-07-04 21:22         ` Eli Zaretskii
2007-07-04 21:47           ` David Kastrup
2007-07-05  1:02           ` Stephen J. Turnbull
2007-07-06 15:41         ` merge of multi-tty (was: source repository) Reiner Steib
2007-07-07 16:41           ` Stephen J. Turnbull
2007-07-08 16:56           ` Richard Stallman
2007-07-08 18:57             ` merge of multi-tty Stefan Monnier
2007-07-09 14:29               ` Richard Stallman
2007-07-16 23:41         ` source repository Giorgos Keramidas
2007-07-17  9:15           ` dhruva
2007-07-17 10:29             ` Giorgos Keramidas
2007-07-04  9:54       ` Dan Nicolaescu
2007-07-04 10:11         ` Masatake YAMATO
2007-07-21 17:27           ` vc-dired (was: Re: source repository) Dan Nicolaescu
2007-07-21 18:09             ` vc-dired Masatake YAMATO
2007-08-26  1:51               ` vc-dired Dan Nicolaescu
2007-07-22  3:12             ` vc-dired Stefan Monnier
2007-07-23 18:18               ` vc-dired Dan Nicolaescu
2007-07-28  7:06                 ` vc-dired Masatake YAMATO
2007-07-28  8:02                   ` vc-dired David Kastrup
2007-07-28 18:14                     ` vc-dired Masatake YAMATO
2007-07-28 17:09                   ` vc-dired Dan Nicolaescu
2007-07-04  3:43     ` source repository Richard Stallman
2007-07-04  6:52       ` David Kastrup [this message]
2007-07-04  7:11       ` Karl Fogel
2007-07-04  7:36         ` Jim Blandy
2007-07-05  1:30         ` Richard Stallman
2007-07-05  3:24           ` Karl Fogel
2007-07-05  6:21             ` Yavor Doganov
2007-07-04  3:43   ` Richard Stallman
2007-07-04  9:57   ` Alan Mackenzie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86tzskpso4.fsf@lola.quinscape.zz \
    --to=dak@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=jasonr@f2s.com \
    --cc=pogonyshev@gmx.net \
    --cc=rms@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.