OK, here's my thinking... Any change to the repo is accompanied by a log
message, which is free-form, and additional "structured" data (e.g.
date, rev number etc.). At present, SVN is rather weak (IMHO) in the
"structured" data department, and as a result there are many
best-practices and recommendations that over-load the message field with
semi-formal data that are then quasi-searchable. (quasi because the
system cannot make strong guarantees about log message contents in the
same way it can about structured data).
Now, how could I implement a label system? There are many ways, but
let's consider three:
(1) Tags, the present system.
(2) Using comments in the message log.
(3) Using a *well-known* external property (e.g. svn:labels).
We know about #1: it's essentially based upon (a) a branch naming
convention and (b) an informal agreement to not modify the branch,
possibly reinforced with pre-commit scripts. #2 is really just a
conventional use of log messages, something like "label: foobar" that
has some chance of being searchable. #3 is one way of moving the label
data into a structured form (there are of course many others).
I regard both #1 and #2 as second-class because they rely upon
conventions that are not visible to, or enforced by, the tool-chain. I
don't like this because (a) developers today already have 1,000
conventions to try to remember (and often don't), and (b) this kind of
clerical work is exactly what a computer is supposed to be for anyway.
The pre-commit script helps, but doesn't really get around the problem
-- I've seen several repos with ordinary branches stored in tags (huh?).
#3 becomes first-class by virtue of the property being well-known both
to users AND the tool-chain. It's more than just a convention, so (e.g.)
the -r switch can use a label as an argument, and it might even be
desirable to add an "svn label" command to create/edit them. As a
result, when I search for (say) label "FOO" and get told it doesn't
exist, I categorically know it *really* doesn't exist. With #2 I might
be looking at a typo or a screw-up on the part of the developer.
More broadly, the issue is one of overloading. I once worked for a
*very* large s/w company that used a bug-tracking system with many. many
thousands of bugs in it. As processes got more complex, the "title"
field was overloaded with all sorts of odd in-band abbreviations for
status, priority, and god-knows what else, with a result that no-one
understood anything and you needed a magic-decoding ring to make sense
of it all. The more I read up on SVN and the more it matures the more
worried I become that the log message field is destined for the same
mess. (it's already being used to link SVN to bug tracking, track
merges, labels, branches, and who knows what else). This tells me that
SVN needs a better way to handle commit-time information (fields,
properties or whatever), *one* of which would be labels, imho. It also,
ultimately, means that the --revision switch in effect expands to a
"select" switch that can query the repo for a revision based upon
various criteria.
Why is this good? Because it eliminates drudge work for developers,
because it frees the message log field for informal comments, and not
quasi-data and because it encourages automation. At present, I have
several processes I *cannot* automate easily in SVN because the "best
practice" follows the familiar "search the log for the infomation, and
type in the rev# into the -r switch" form. This is error-prone to automate.
ok, you probably think I'm mad now :)
--Tim
Ben Collins-Sussman wrote:
>
> I'm not sure I understand. Why would a property-change commit be
> more likely to be noticed than a tag-directory commit? You seem to
> have some definiton of 'first class' and 'second class' here that
> isn't explained. In my mind, users would get commit emails whenever
> something changed, no matter what it is.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu May 12 22:47:51 2005