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

The various Emacs interfaces to SVN

From: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2002-08-20 17:56:54 CEST

Michael Alan Dorman <mdorman@debian.org> writes:
> > Or, if you have never taken a peek inside 'svn-dev.el', go check out
> > the function 'svn-log-message' - it does pretty much the same thing.
> Ah. I shall have to check that out. I missed svn-dev.el somehow.

Hmmm. Time to paint the Big Picture here:

There are now at least three ways to for Emacs and SVN to talk to each

   * tools/dev/svn-dev.el
       Written earliest, rudimentary functionality, mainly meant to
       support Subversion development specifically, but with vague
       intentions about becoming more general someday.

   * tools/client-side/vc-svn.el
       Jim Blandy wrote this to use the Emacs VC interface, which is
       designed around editing a single file at a time. Jim is aware
       that this is not the ideal way to work with Subversion (or CVS,
       for that matter), but his first goal was compatibility with the
       Emacs VC interface. This package does do some nifty things,
       like showing status in the modeline.

   * svn.el, at http://xsteve.nit.at/prg/emacs
       Similar to pcl-cvs, but (apparently) written from scratch, not
       based on the pcl-cvs code.

So: VC operates most naturally on a single file at a time, whereas
pcl-foo operates most naturally on multiple files at once. Each *can*
work the other way, but it's a little awkward.

Nowadays, both vc and pcl-cvs are distributed with Emacs. They exist
independently in the Emacs tree, eyeing each other warily, knowing
full well that they overlap heavily, and that if justice prevails they
will someday be merged. Why? Because there are times when one needs
to operate on directory trees, and times when one needs to operate on
single files, and there's no point having two completely separate
packages for these two complementary yet compatible styles of working.

Of course, merging them is a non-trivial task, and certainly not the
inherent responsibility of someone writing an SVN mode for Emacs.
However, if things continue as they are, then:

   - The VC interface gets svn support, but is rarely used because it
     doesn't really suit a lot of svn operations...

   - A *new* PCL-style code base gets written, probably duplicating a
     lot of what pcl-cvs does, but not sharing code with it nor with
     VC. Sigh...

   - Users have to make seemingly arbitrary choices about which
     package to load, i.e., which interface style to use, because who
     has time to learn every available package?

This way lies only madness :-).

Please, please: if you're going to spend a lot of effort writing an
Emacs mode for Subversion, consider instead *first* tackling the
VC/pcl-foo merge problem in Emacs, then when that's done, add svn
support into the new interface (much the way Jim did with vc-svn.el,
but now the api will be richer and better able to support Subversion).

The Emacs developers will welcome you. If you join the emacs-devel
list and say that you'd like to fix the current state of vc interface
horrendousness, I'll bet there will be very few objections. And I
know at least one person who will cheer :-).

Or, possibly, everyone else is in the same boat that Jim and I are in:
we have time to cobble together some Elisp using the current
half-baked interfaces, but not time to solve the root problem of Emacs
not offering a single, sufficiently rich api for revision control.
Yes, if we're *all* in that boat, then I guess we'll just continue
dumping code at the problem... But it's only more duplication to sort
out later. So if you see me sobbing in the corner, you know why.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 20 18:15:04 2002

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.