(and a reply all button too)
---------- Forwarded message ----------
From: Phyrefly <email@example.com>
Date: 20-Nov-2006 23:47
Subject: Re: Is label support in future release?
To: Tim Hill <firstname.lastname@example.org>
Can I add a (1b) to this: For a project that is simple enough not to
need branching, the current tagging implementation of tagging, rather
than labelling, adds complexity even for hard-core coders, and with
that complexity comes the possibility of error. It introduces an
artificial need to use a piece of functionality that would otherwise
not be used at all. In my repo, there is one copy of each file(as
someone described it, "in the space dimension", obviously many
revisions of it). Now in order for me to have a particular rev
available by an easier-to-remember form than the actual rev# itself, I
am forced to make a second copy of that code, and therefore a second
HEAD, and therefore the possibility of people working on the wrong
one. This potentially simple piece of functionality requires the use
of an exceedingly complex one, with all its potential errors.
On 20/11/06, Tim Hill <email@example.com> wrote:
> 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?
>  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
>  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".
>  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.
> 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: 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
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Nov 21 00:48:49 2006