You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Eric S. Raymond" <es...@snark.thyrsus.com> on 2005/02/22 17:18:33 UTC
State of vc-svn.el
Some months ago one of the listmembers here who was aware that I am
the original author of Emacs VC mode asked me to review the vc-svn.el
written by Jim Blandy that ships with Subversion.
I have not forgotten this request, and it just worked its way far
enough up my queue to get some action. I have looked at both the
Blandy version and the version by Stefan Monnier that now ships with
Emacs.
Here are my findings:
1. The Monnier version was synced with the Blandy version at revision
5801, and has evolved since.
2. The Blandy version changed at revs r9195, r6632, and r6173. The
last substantive change was at r5799.
3. Both have a serious problem in that they only do commits one file
at a time. To fix this, the VC framework itself needs to have a
notion of committing a group of files.
My conclusion is that:
(a) The three small changes to the Blandy version since r5801 should
be ported to the Monnier version.
(b) VC should learn to use a new optional method, vc-group-commit, that commits
a group of files with a single change comment. And to fall back
on individual-file checkins when that optional method is absent.
(c) The Monnier vc-svn.el should be enhanced to supply this method.
(d) The Blandy version should be dropped.
In furtherance of (c), there is a hint in the way Emacs calls svn ci
that when svn ci is given path arguments, it commits only changes in
the files named by those arguments (as opposed to shipping changes
for the entire working copy).
However, neither the help text for svn ci nor the Subversion book
addresses this. (The failure to explain how path arguments are used
is a documentation bug.) Is it in fact the case?
If so, enhancing VC to do the right thing will be easy.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
The biggest hypocrites on gun control are those who live in upscale
developments with armed security guards -- and who want to keep other
people from having guns to defend themselves. But what about
lower-income people living in high-crime, inner city neighborhoods?
Should such people be kept unarmed and helpless, so that limousine
liberals can 'make a statement' by adding to the thousands of gun laws
already on the books?"
--Thomas Sowell
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: State of vc-svn.el
Posted by kf...@collab.net.
"Eric S. Raymond" <es...@snark.thyrsus.com> writes:
> Some months ago one of the listmembers here who was aware that I am
> the original author of Emacs VC mode asked me to review the vc-svn.el
> written by Jim Blandy that ships with Subversion.
>
> I have not forgotten this request, and it just worked its way far
> enough up my queue to get some action. I have looked at both the
> Blandy version and the version by Stefan Monnier that now ships with
> Emacs.
Thank you thank you thank you for tackling this. I've also been
wanting this mess to be cleaned up for a long time, but, unlike you,
hadn't gotten around to actually doing anything about it :-).
> Here are my findings:
>
> 1. The Monnier version was synced with the Blandy version at revision
> 5801, and has evolved since.
>
> 2. The Blandy version changed at revs r9195, r6632, and r6173. The
> last substantive change was at r5799.
>
> 3. Both have a serious problem in that they only do commits one file
> at a time. To fix this, the VC framework itself needs to have a
> notion of committing a group of files.
>
> My conclusion is that:
>
> (a) The three small changes to the Blandy version since r5801 should
> be ported to the Monnier version.
>
> (b) VC should learn to use a new optional method, vc-group-commit, that commits
> a group of files with a single change comment. And to fall back
> on individual-file checkins when that optional method is absent.
>
> (c) The Monnier vc-svn.el should be enhanced to supply this method.
>
> (d) The Blandy version should be dropped.
Totally agree with your conclusions. And (d) can happen anytime after
(a), there's no need for it to wait on (b) and (c).
> In furtherance of (c), there is a hint in the way Emacs calls svn ci
> that when svn ci is given path arguments, it commits only changes in
> the files named by those arguments (as opposed to shipping changes
> for the entire working copy).
>
> However, neither the help text for svn ci nor the Subversion book
> addresses this. (The failure to explain how path arguments are used
> is a documentation bug.) Is it in fact the case?
Yes, that's right. In other words:
$ svn ci -m "log msg"
commits all the changes in your working copy, but
$ svn ci -m "log msg" path1 another/path some/other/path
commits just the named paths, and does not commit whatever other local
modifications might be lurking in your working copy.
If the book doesn't explain this, it should.
> If so, enhancing VC to do the right thing will be easy.
That's great news.
Let us know when to drop vc-svn.el from our repository and start
pointing to the one in the Emacs tree as the canonical version.
How all this relates to pcl-cvs.el / psvn.el, I don't know. If VC
grows decent support for checkin groups, then it will overlap the
PCL-CVS / PSVN functionality (the former is in the FSF Emacs tree, and
the latter in the Subversion tree, IIRC). I don't think this overlap
is necessarily a bad thing, it's just something to stay aware of.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: State of vc-svn.el
Posted by kf...@collab.net.
"Peter S. Housel" <ho...@acm.org> writes:
> The last time I tried Stefan Monnier's version of vc-svn.el from the
> Emacs source repository it didn't work in Emacs 21.3, due to changes
> in the surrounding infrastructure. Shouldn't it be kept around, or
> the emacs trunk version backported?
>
> Karl has just now (r13119) installed a placeholder vc-svn.el pointing
> to the Emacs repository.
Good point.
If someone discovers that an older version of vc-svn.el is needed to
work with Emacs 21.3, I think our best course is to document that
similarly to r13119, and point to that older version (whether it be in
our repository's history or the FSF's repository).
Peter, do you have time to figure out which version we should point to
in this way? (I don't use vc-svn.el, myself.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: State of vc-svn.el
Posted by "Peter S. Housel" <ho...@acm.org>.
> "Eric S. Raymond" <es...@thyrsus.com> writes:
>> Stefan Monnier <mo...@iro.umontreal.ca>:
>> > > (a) The three small changes to the Blandy version since r5801 should
>> > > be ported to the Monnier version.
>> >
>> > They don't seem to be applicable.
>>
>> I rather thought that might be the case, but I had not eyeballed them
>> closely enough to be sure. If you are, then that means the Blandy
>> version can be dropped now.
>
> I'll treat this as enough confirmation to drop it. After all, if it
> turns out to be wrong, the relevant changes can still be pulled from
> history.
>
> Blown away in r13113.
The last time I tried Stefan Monnier's version of vc-svn.el from the Emacs
source repository it didn't work in Emacs 21.3, due to changes in the
surrounding infrastructure. Shouldn't it be kept around, or the emacs trunk
version backported?
Karl has just now (r13119) installed a placeholder vc-svn.el pointing to the
Emacs repository.
-Peter-
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: State of vc-svn.el
Posted by kf...@collab.net.
"Eric S. Raymond" <es...@thyrsus.com> writes:
> Stefan Monnier <mo...@iro.umontreal.ca>:
> > > (a) The three small changes to the Blandy version since r5801 should
> > > be ported to the Monnier version.
> >
> > They don't seem to be applicable.
>
> I rather thought that might be the case, but I had not eyeballed them
> closely enough to be sure. If you are, then that means the Blandy
> version can be dropped now.
I'll treat this as enough confirmation to drop it. After all, if it
turns out to be wrong, the relevant changes can still be pulled from
history.
Blown away in r13113.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: State of vc-svn.el
Posted by "Eric S. Raymond" <es...@thyrsus.com>.
Addressing the second point first...
Stefan Monnier <mo...@iro.umontreal.ca>:
> > (a) The three small changes to the Blandy version since r5801 should
> > be ported to the Monnier version.
>
> They don't seem to be applicable.
I rather thought that might be the case, but I had not eyeballed them
closely enough to be sure. If you are, then that means the Blandy
version can be dropped now.
> > 3. Both have a serious problem in that they only do commits one file
> > at a time. To fix this, the VC framework itself needs to have a
> > notion of committing a group of files.
>
> It's not just commits, but also merge-news, update, diff, ... everything.
> The VC-dired part tries to provide multiple-file operations but in my
> experience it just doesn't work acceptably.
Yeah, I know. It actually worked better when I wrote the original
mode in 1992 -- for example you could say C-x v u in a VC-dired buffer
and confirm just once to have all the marked files reverted in one go.
But sometime during one of the many re-factorings of the code that got
lost. I remember flaming the then-maintainer about that sometime
around 1997-1998 a few years after FSF took ove the code, but it never
got fixed.
> There needs to be serious
> re-design here and it's non trivial if we want it to work for Subversion,
> CVS, Arch, ... until now people have just provided other interfaces instead
> (psvn.el, pcl-cvs, xtla, ...). That makes the job even more difficult since
> we now have to compete against custom-taylored code.
I don't actually think this will be very hard. The key idea here is this:
1. We write a new function called something like vc-get-target-group. It
returns a list of filenames -- all the currently marked ones if in a VC-dired
buffer, a singleton list of the current buffer filename otherwise.
2. All the VC framework methods call (vc-get-target-group) and hand
the resulting list down to whatever backend methods they call. This
is a change from current practice which is to hand down a single file.
4. Each backend method has to know what to do with a list of files. For
file-oriented systems like RCS or SCCS, that's just to iterate through
the list applying the backend operation. For tree-oriented systems like
Subversion and arch, something more interesting happens.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: State of vc-svn.el
Posted by Stefan Monnier <mo...@iro.umontreal.ca>.
> 3. Both have a serious problem in that they only do commits one file
> at a time. To fix this, the VC framework itself needs to have a
> notion of committing a group of files.
It's not just commits, but also merge-news, update, diff, ... everything.
The VC-dired part tries to provide multiple-file operations but in my
experience it just doesn't work acceptably. There needs to be serious
re-design here and it's non trivial if we want it to work for Subversion,
CVS, Arch, ... until now people have just provided other interfaces instead
(psvn.el, pcl-cvs, xtla, ...). That makes the job even more difficult since
we now have to compete against custom-taylored code.
> (a) The three small changes to the Blandy version since r5801 should
> be ported to the Monnier version.
They don't seem to be applicable.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: State of vc-svn.el
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2005-02-22 at 12:18, Eric S. Raymond wrote:
> In furtherance of (c), there is a hint in the way Emacs calls svn ci
> that when svn ci is given path arguments, it commits only changes in
> the files named by those arguments (as opposed to shipping changes
> for the entire working copy).
> However, neither the help text for svn ci nor the Subversion book
> addresses this. (The failure to explain how path arguments are used
> is a documentation bug.) Is it in fact the case?
Yes, assuming the arguments are files. If they are directories, then
everything under those directories will be committed, unless the -N
(--non-recursive) option is given.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: State of vc-svn.el
Posted by Jay Berkenbilt <ej...@ql.org>.
"Eric S. Raymond" <es...@snark.thyrsus.com> wrote:
> Some months ago one of the listmembers here who was aware that I am
> the original author of Emacs VC mode asked me to review the vc-svn.el
> written by Jim Blandy that ships with Subversion.
>
> I have not forgotten this request, and it just worked its way far
> enough up my queue to get some action. I have looked at both the
> Blandy version and the version by Stefan Monnier that now ships with
> Emacs.
This is really good news. :-)
I posted a small patch to vc-svn-checkout that adds destfile support
so that C-x v ~ and ediff both work properly. I hope you'll either
consider accepting that patch or fixing it in the right way if I got
it wrong. You can find my original message in the list archives
sometime in the past week or so or else look at issue 2225. The
current vc-svn-checkout could raises an error if editable is nil. My
patch changes it to ignore editable if destfile is given, but
otherwise, it still raises an error. It would probably be better for
it to simply ignore this flag or else to make the resulting file or
buffer read only.
There are two other issues with vc-svn.el that I was going to try to
fix and send patches for:
* annotate (C-x v g) isn't currently supported even though svn blame
exists
* if you use vc-register to register a file that is neither in a
subversion working copy, in a CVS sandbox, or in a directory that
contains RCS, you get an error:
apply: Error running Subversion to add `a'
If vc-svn.el is not present, it just defaults to checking in the
file with RCS, which is more sensible. Anyway, I'm not sure what
the right behavior is, but getting an error from vc-svn.el isn't
it. :-) I'm sure this would be easy to fix. It's probably as
simple as implementing vc-svn-responsible-p and
vc-svn-could-register.
If you'd like me to work on either of these, let me know. I was
probably going to take a crack at both this weekend, but if you're
going to be working on the code, maybe I don't need to.
--
Jay Berkenbilt <ej...@ql.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org