Re: svn commit: r29412 - in trunk: subversion/mod_dav_svn subversion/mod_dav_svn/reports tools/server-side

glasser_at_tigris.org writes:
> - The svnserve command set is a good vocabulary for svn operational
> actions; there's no reason to have a second vocabulary that is
> mostly but not entirely the same.

I'm not sure consistency between meant-for-admins-to-see commands and
internal protocol commands is a good enough motivation to make the
former worse (see below).

> - When svnserve grows logging, it would make sense to use its command
> set as the vocabulary; making these format changes would allow the
> two servers to share the same log format.

(see above :-) )

> The specific changes made:
>
> list-dir => get-dir
> revprop-change => change-rev-prop
> revprop-list => rev-proplist
> blame => get-file-revs
> remote-status => status
> diff-or-merge => diff
>
> (I would also like to get rid of prop-list, and in exchange add
> props?/text? fields to get-dir and a new get-file.)

I'm not so hot on the revprop changes...

"revprop-VERB" is easy to understand, because "rev" and "prop" are
bound together more tightly than "revprop" and "VERB" are, which is
what we want. Whereas "rev-proplist" is a tiny bit ambiguous: if you
don't have the docs in front of you, you might not know whether it's
listing revprops, or listing all the regular props that changed in a
given rev, or what.

I realize it's easy to guess the correct answer, but why make things
even one iota harder for admins?

If we could go back and change the ra_svn protocol itself, that would
be great. Of course, we can't, but that doesn't mean we have to
spread its unclarities any further.

Similar arguments apply to "diff-or-merge".

When svnserve grows logging, it too should log admin-friendly
commands, even if that means making a few extra transformations.

> (It may also be worth logging get-locations and
> get-location-segments, especially given that the latter has
> complicated performance characteristics.)

Agreed.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-02-20 23:51:51 CET