OK, before going further on this long thread, I'd like to clarify
_my_ understanding of the issues: As I see it, the tags/labels
arguments break into two areas:
(1) Complexity Issues. These arguments do not dispute per se the
functionality of tags, rather the difficulty of their use for certain
target Subversion audiences. These are mainly "sledgehammer to crack
a nut" arguments for those opposed to tags.
(2) Completeness Issues. These arguments claim, rightly or wrongly,
that tags do not fully address functionality needed for one or more
legitimate Subversion workflows. I think there are two sub-branches
of this argument: (2a) is the "strong" argument that states (again,
rightly or wrongly) that there are workflows that _cannot_ be handled
with tags. (2b) is the "weak" argument that states that there are
workflows that are made too complex or fragile when using tags as
currently implemented by Subversion.
(3) Richness Issues. These arguments essentially relate to in-house
workflows that want richer metadata to track, for example, cross-
reference information between tools, workflow data, auditing etc etc.
Generally, these arguments speak to the current over-loading of log
messages and the difficulties with parsing such ad-hoc metadata.
While some of these arguments (imho) have merit, I think they are a
distinct discussion, so I propose to ignore them here, apart from
noting that pretty much all these would be fixed by allowing revprops
to be created atomically at commit time (and its variants).
Issues (1) and (2b) are subjective in nature, depending upon your
viewpoint of complexity and/or the target user; these issues do
overlap, but I would like to treat them as distinct for now. Issue
(2a) should be objective, in that either there are use cases that
show a functional hole or there are not.
(Regarding issue (1), I have argued that for certain legitimate
members of a development team who are not hard-core developers
(graphic designers, tech writers etc), the complexity of Subversion
commands and workflows (specifically around tagging), is past the
threshold of pain. I do this not from theory but direct, repeated,
and sometimes painful, experience. I have seen several replies to my
posts along the lines of "just tell them foo...", which are _so_ wide
of the mark that it would be funny if it weren't for the decreasing
amount of hair on my head as a result of this. Such "suggestions"
fall into the same category as "the best way to write software is to
leave the bugs out"; technically accurate but not practical.)
I now want to put a peg in the sand: I wish to argue that a workflow
of the form: "(a) scan log messages, (b) locate rev#, (c) manually
paste rev# into a subversion command" is a confirming example of
issue (2b) if it is carried out in the normal day-to-day workflow.
If we accept this, then I argue that a confirming use case of the
form you state below would also imply a fall-back position to the
workflow noted in the previous paragraph, as the only possible
workaround. And further, from the stated position that this is a
confirming case of (2b), that this confirms that tags, in their
current implementation, are not complete in the "weak" (but still
very real) sense of the word.
Does this make sense, so far?
Now for the good news (?). I do not think that anyone has identified
an example of (2a) in this thread or elsewhere, myself included. This
doesn't, of course, mean there isn't one -- just that no-one has
clearly presented one. So I don't think your challenge below is met.
So what's all the fuss? We are left, really with (2b) (and, to an
extent, (1) also), Since this is a subjective argument, we all keep
going around in circles. It's a judgement call, based primarily on
familiarity with "the Subversion way" and/or personal bias in the way
things should be done.
So, what would I like, in an ideal world, and why?
[1] First-class tags. That is, have Subversion enforce the
immutability of tags without user-supplied hook scripts. Yes, I'm
aware that the design of this is non-trivial to get "right". But
heck, even TortoiseSVN tries for this by shouting before you mutate a
tag.
[2] The ability to create a tag at commit time in one single atomic
operation, via some sort of --tag switch to svn commit. This would
certainly take care of issue (1) for me and would, I suspect, make
(2b) go away for a lot of people. And, yes, I'm aware that this is
also a tricky feature to get "right".
[3] The ability to create revprops at commit time (including other
commands that imply a commit) so that revs can be decorated with
richer metadata WITHOUT the need to allow (dangerous) revprop changes
to existing revisions via hook scripts. This would solve issue (3)
and also take the pressure off log messages. It would also put
Subversion slap-bang in the middle of many workflows where automatic
tool-chain interaction is vital.
So, that's my 2c worth.
--Tim
On Nov 20, 2006, at 8:30 AM, Nikki Locke wrote:
>
> I speak from a position of some ignorance here, but which subversion
> commands will accept a revision number (or, in the proposal, a
> label) but
> will NOT accept a tag in the same place in the command line, to
> mean the
> same thing?
>
> --
> Nikki Locke, Trumphurst Ltd. PC & Unix consultancy & programming
> http://www.trumphurst.com/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Nov 20 23:47:24 2006