[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Subversion support in Emacs 23

From: Eric S. Raymond <esr_at_thyrsus.com>
Date: 2007-10-10 21:11:28 CEST

Karl Fogel <kfogel@red-bean.com>:
> We should stop maintaining anything in our tree that is "the same as"
> what's now in Emacs ("the same as" == "a branch of", "an earlier
> version of", etc). But any unrelated packages in our tree that just
> happen to do the same job should be left right where they are,
> assuming our copy is the master. I think we have both kinds.

Of course. I was thinking mainly of the rather nasty vc-svn.el you guys
forked from an old version of the VC CVS support. It won't even work
anymore, not since I changed the back-end API to know about filesets.
> Now if we could only persuade the Emacs maintainers (meaning RMS :-) )
> to get the project off CVS and onto something modern -- I don't care
> if it's Subversion or Hg or git or what. (Actually, I've kind of been
> hoping for Hg or git, so I could get some experience with them on a
> real-world project involving many collaborators. But we appear to be
> stuck on CVS, with no use bringing up to topic again, sigh...)

Hmmmm...is a matter of fact, I have it on my to-do-list to bring that
up on emacs-devel once the dust from the transition to new VC has
settled a bit. My choice would be Mercurial; haven't used it yet, but I
can tell from reading the design documents that the guy who wrote it
thinks like me. But I'd be delighted if they just went as far as
moving to Subversion.

I'll tilt at this windmill a bit. On the one hand, nobody's chances of
budging RMS when he's got his stubborn on can really be called good --
but on the other hand my track record at it is, relative to most
who've tried, pretty strong.

		Eric S. Raymond
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 10 21:11:04 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.