On Nov 15, 2006, at 2:22 AM, Peter Lundblad wrote:
> 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.
Yes -- so this would include import, copy etc.
>
>> (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.
Frankly this is a study item, as I'm not familiar enough with the
hooks. The *intent* here is for existing workflows and hooks to run
without any change. If we already have a hook script that expects to
be able to "see" all revision property activity, then a question
arises: should it see the new revision property activity (retains
behavior based on data input) or should it only be called as
currently (retains exact semantics of current version but allows
revision properties to slip through).
>
>> 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.
Agreed. And the quotes in the above are as you noted.
>
>> -- 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:-)
Yes, I was aware of that, and that it implied a much more database-
like lookup/search facility (another day...).
>
>> 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.
Lack of familiarity with the code base, so I was erring on the
cautious side. I would prefer if the client was smart enough to
figure the server was down-level and not even try to send revprops;
but again lack of internals knowledge at this point means I don't
know if thats possible.
--Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 15 18:02:59 2006