unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Miles Bader <miles@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: deleting rcs keywords from emacs sources
Date: Tue, 23 Mar 2004 08:13:16 -0500	[thread overview]
Message-ID: <20040323131316.GA29657@fencepost> (raw)
In-Reply-To: <20040323122810.7979.JMBARRANQUERO@wke.es>

On Tue, Mar 23, 2004 at 12:41:31PM +0100, Juanma Barranquero wrote:
> Now, if we switched from CVS to Subversion, we could have our cake and
> eat it too (in Subversion, keywords don't cause spurious
> conflicts/differences).

Keywords are just a generally stupid idea, so that's hardly an advantage
(even more so in a system with tree-wide version numbers, like subversion --
there the right thing to is just put the version number hacks in your
Makefile).

> I know there are Emacs maintainers whose preferred VC tool is arch, and
> I've only heard good things about it, but it suffers at least two
> problems, IMHO of course: there is no arch port to Windows

I don't use windows so it's hard for me to judge, but I believe there are
several ports of tla to windows, it's just that none of them is free from
dependencies on particular non-standard environment (cygwin or various
microsoft environments, etc).

> and the decentralized model arch supports, though interesting, is quite
> different from the one in CVS

Yes -- it's much, much (much) better than CVS (and subversion).  This is
_not_ an advantage of subversion.

> while Subversion is modelled to be "a better CVS". Switching to Subversion
> would be, I think, a lot less painful.

Actually I suspect that arch would is likely easier, despite the differences
-- its network model is extremely flexible and simple, and it has none of the
special hosting requirements that subversion does.

I say "is" because as you might know, there's _already_ an emacs arch archive
(synchronized with CVS), which could take over from CVS quickly if the
developers wanted that (the main sticking point being that it's running on
fencepost, not on savannah, so anyone that wanted commit access would need to
have ssh access there; moving to savannah would probably be pretty
straightforward except that _everything_ involving savannah is slow :-)

> Yeah, this is an off-side plea to at least consider the idea of
> switching to SVN. The Apache people is carefully doing it, one repo at a
> time, and it seems like the experience is being very positive.

You might want to check the emacs-devel archives: there was a big thread on
this about 10 months ago -- and at that time I was tentatively on the
subversion, for many of the reasons you gave above.  Now that I've seen
personally how superior arch is, I'm firmly in the arch camp.

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

  reply	other threads:[~2004-03-23 13:13 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-23  6:46 deleting rcs keywords from emacs sources Miles Bader
2004-03-23  7:47 ` Eli Zaretskii
2004-03-23 10:56   ` Kim F. Storm
2004-03-23  9:51 ` spiegel
2004-03-23 10:16   ` Miles Bader
2004-03-23 11:41   ` Juanma Barranquero
2004-03-23 13:13     ` Miles Bader [this message]
2004-03-23 14:01       ` Juanma Barranquero
2004-03-23 14:35         ` Miles Bader
2004-03-23 14:58           ` Juanma Barranquero
2004-03-23 15:14             ` Stefan Monnier
2004-03-23 15:36               ` Juanma Barranquero
2004-03-23 23:38                 ` deleting rcs " David Kastrup
2004-03-24  5:34             ` deleting rcs keywords " Richard Stallman
2004-03-23 15:04         ` Stefan Monnier
2004-03-23 15:39           ` Wheter to switch to another VC, and which one Juanma Barranquero
2004-03-23 16:25             ` Stefan Monnier
2004-03-23 16:43               ` Masatake YAMATO
2004-03-23 17:17                 ` Stefan Monnier
2004-03-23 17:31                   ` Masatake YAMATO
2004-03-23 18:50                     ` Stefan Monnier
2004-03-24  0:17             ` Kim F. Storm
2004-03-23 23:35               ` Miles Bader
2004-03-24 10:52                 ` Kim F. Storm
2004-03-24 10:24                   ` Miles Bader
2004-03-24 17:48               ` Stefan Monnier
2004-03-23 18:17       ` deleting rcs keywords from emacs sources Nick Roberts
2004-03-23 18:07     ` Nick Roberts
2004-03-24  5:34 ` Richard Stallman
2004-03-25  8:17   ` Miles Bader
  -- strict thread matches above, loose matches on Subject: below --
2004-03-23 18:46 spiegel
2004-03-23 21:47 ` Miles Bader
2004-03-25  7:45   ` Andre Spiegel
2004-03-26 16:45     ` Richard Stallman
2004-03-26 18:10       ` Stefan Monnier
2004-03-26 18:46       ` David Kastrup
2004-03-28  1:36         ` Richard Stallman
2004-03-26 19:05       ` Robert J. Chassell
2004-03-26 19:37       ` Andre Spiegel
2004-03-28  1:36         ` Richard Stallman
2004-03-28 11:10           ` Andre Spiegel
2004-03-29 20:56             ` Richard Stallman
2004-03-30 14:22               ` Andre Spiegel
2004-03-31 15:05                 ` Richard Stallman

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=20040323131316.GA29657@fencepost \
    --to=miles@gnu.org \
    --cc=emacs-devel@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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).