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

Re: Feature Request: Revision Properties at Commit Time

From: Peter Lundblad <plundblad_at_google.com>
Date: 2006-11-15 11:22:36 CET

I like this proposals with a few comments.

Tim Hill writes:
> (1) Add command-line syntax to the SVN COMMIT command to allow
> setting of arbitrary revision properties at commit.
I guess you mean all commands that do a commit, including copy, move
and delete as well as commit itself.

> (3) Relaxing the current rules that disable revision properties to
> allow (1) and (2) even if revision property modifications are
> disabled (pre-revprop-change & post-revprop-change hooks). The hooks
> should still be invoked during the checkin, *but* if they are not
> implemented, commit-time revprops are still allowed.
Why should these hooks be called here? That would be inconsistent with
what happens to svn:log, svn:date and svn:author when committing today and
also would be redundant since the commit related hooks can always take
action if they want to.

> A possible command-line syntax might be:
> svn commit .... --revpropset name="value" # set revprop "name" to
> "value"

You could be more precise regarding the syntax here. I imagine the quotes
are not really part of the syntax, but used to make the shell include
the space in the argument, right?

> svn commit .... --revpropset name:file # set revprop "name" to
> contents of "file"

We support colons in prop names, so this doesn't work. Could have
--revpropset-file instead.

> -- Formal and semi-formal "revision labels" come for free

Do you mean labels as in tags? Then, they don't, because we don't have
a quick way too look up revisions matching certain revprops. Anyway, that's
another (possibly long) thread:-)

> The proposer (me) is not sufficiently familiar with the internals of
> Subversion to assess the development work required; presumably the
> biggest issues would be modification / enhancement of the various
> APIs to support the commit-time properties and changes to the commit
> protocol to the server to support these in a backward compatible
> manner (the command-line parsing changes are probably trivial by
> comparison). It is therefore difficult to characterize the cost/
> benefit ratio from a development standpoint.
I don't think extending the APIs is any hard at all. Just a bunch of API
revving and protocol work. We need to make sure the server throws an
error if the feature is not supported, though.

Ben Collins-Sussman writes:
> On 11/14/06, David Glasser <glasser@mit.edu> wrote:
> > adding a "set_edit_props" callback to the delta editor vtable, which
> > at the very least involves rewriting a bunch of a code to use a new
> > version of the table.
> +1, this is the Right Way To Do it.

Or just tack it onto svn_ra_get_commit_editor2, replacing the passed
in log message with a new hash of props. Right, this doesn't scale if
people add thousands of megabyte revprops at commit time, but this is the
case of our whole property implementation.

//lundblad -- continuing his 18 month old fight to avoid having to rev the

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 15 11:23:15 2006

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