I've already posted this as a feature request on the dev list. Below
is the email I sent to the list. it generated some discussion, and it
was also pointed out there is already a bug posted against this
feature, #1976. You can find additional information in the archives.
At present, Subversion supports "revision properties" (aka
unversioned properties) that can be set against a specific revision.
This feature is considered (correctly) to be potentially dangerous,
since it retroactively changes a revision, with all the potential for
chaos that this implies. For this reason, revision properties are
disabled by default.
There exists, however, _one_ instant in time when revision properties
can be safely attached to a revision: at the time the revision was
created, i.e. at commit time. Since commits are atomic, this implies
that the revision properties must be submitted during the commit.
Therefore, I am suggesting the following changes to svn:
(1) Add command-line syntax to the SVN COMMIT command to allow
setting of arbitrary revision properties at commit.
(2) Making necessary API changes to support this feature in other
(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.
A possible command-line syntax might be:
svn commit .... --revpropset name="value" # set revprop "name" to
svn commit .... --revpropset name:file # set revprop "name" to
contents of "file"
Multiple --revpropset switches should be allowed in a single command.
RATIONALE FOR PROPOSAL
At present, the only revision-level metadata usable in a general way
at commit time is the log message. Although intended as a "comment"
field, the log message is frequently over-loaded with semi-formal
syntax to assist in various workflows, including such items as bug
numbers, build information, branch and merge tracking etc. The
proliferation of these items leads to "prayer-based parsing" of the
log messages and (of course) the elimination of this field for its
original use (as a comment!). It will also be observed that the very
proliferation of these second-class syntax tricks is itself an
indication of the need for the kind of formalized revision-level
metadata that revision properties provide.
-- Elimination of "magic decoding ring" syndrome for log messages:
they are plain-old comments again
-- Richer meta-data at commit time allows tools to record better
audit trails (e.g. bug tracking)
-- Formal and semi-formal "revision labels" come for free
-- Better meta-data at commit allows pre-revprop-change hook to be
smarter about custom commit processing
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.
From a user perspective, the feature is totally backward compatible:
no changes to existing workflows, commands, scripts etc are required.
On Nov 29, 2006, at 5:30 AM, Robert Graf-Waczenski wrote:
>> -----Original Message-----
>> From: Gerco Ballintijn [mailto:email@example.com]
>> Sent: Mittwoch, 29. November 2006 12:12
>> To: 'Subversion Users'
>> Subject: Re: Simple Label=RevisionID Discussion
>> Maybe the discussion of this narrow request/idea should be moved
>> to the developers list to get the attention it deserves?
> Any volunteers for writing a thread summary and cross-posting it to
> the devs list?
> To unsubscribe, e-mail: firstname.lastname@example.org
> For additional commands, e-mail: email@example.com
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Nov 29 20:26:06 2006