Hi,
Wanted to open discussion for a new svn feature here...
FEATURE PROPOSAL
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
tools/bindings.
(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
"value"
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.
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
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.
Comments? Does this suck, has it got legs?
--Tim
---------------------------------------------------------------------
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