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

Feature Request: Revision Properties at Commit Time

From: Tim Hill <drtimhill_at_comcast.net>
Date: 2006-11-14 19:31:38 CET


Wanted to open discussion for a new svn feature here...

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.

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.

Benefits include:
-- 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

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.

Comments? Does this suck, has it got legs?


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 14 19:54:45 2006

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