Agreed.
There is, of course, another alternative to this approach:
standardize the log message format and make it "known" to the tools.
For example, make the log message XML. The existing "plain text" log
message could then be bumped to a field in the XML and other fields
could be defined using the same formal command-line syntax.
The advantage here of course is this is a client-only change: no
server change and no protocol change. Backward compatibility would be
more awkward, since the clients/api libs would need to distinguish
legacy from xml comments and handle accordingly. In addition, there
are no issues with revprop hooks compatibility (although, of course,
log message parsing would have to change).
On the downside, XML always seems to get fat very fast, and I'm no
great fan of some of the more cryptic & obscure formatting implied by
this.
--Tim
On Nov 15, 2006, at 8:13 AM, Peter Lundblad wrote:
> Michael Haggerty writes:
>> Peter Lundblad wrote:
>> Speaking of which, should one be able to use this feature to set
>> svn:log
>> (i.e., serving as an alias for the "-m" and "-F" options)? What
>> about
>> svn:date and svn:author (i.e., overriding the defaults for these
>> options)?
>>
> Good points. For svn:log, I don't have an opinion, really. They
> are just redundant ways to do the same thing.
>
> For svn:date, no, because the date is reset when the transaction is
> finally committed and we depend on the dates being in order.
>
> svn:author: no, because this is determined by authentication in many
> cases.
>
> Regards,
> //Peter
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
---------------------------------------------------------------------
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:11:26 2006