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:-)
> IMPACT OF FEATURE
> 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
editor;)
---------------------------------------------------------------------
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