ok, I'm throwing in the towel. I'm seeing people advocating bad
arguments in favor of the status quo and dismissing good arguments
for any form of change that might help the situation. There is too
much confirmation bias here for a useful dialog.
Fact: Tags are *not* a complete solution. If they were, the svn book
would not have example after example where rev numbers are plucked
from the log and then manually pasted back into a workflow. Either
the svn book is wrong or the tagging system is wrong. You cannot have
it both ways.
Fact: Tags *are* too complex for many non-technical (but competent)
professionals. I encounter these issues all the time. This is not a
"all you have to do is tell them foo" theoretical argument; its what
I actually *see* on a regular basis. It is as silly to argue that a
skilled graphic artist should become a subversion expert as that a
subversion dev suddenly becomes a skilled graphic artist. Neither
will happen.
Fact: I've been told, on many occasions, that Subversion is designed
as a set of fundamental primitives that avoid forcing policy onto a
workflow (which is good). Yet every time someone mentions that the
tool doesn't fit what they need the answer is they are using the
wrong workflow! If Subversion is designed for a particular workflow,
let's document it, optimize the tool for that workflow, and be done
with it.
Tags are broken/incomplete, for numerous reasons. Examples:
-- Tags are supposedly immutable. Yet the toolchain does not enforce
this. Yes, I'm aware *I* can do that with a hook, but what sort of
argument is that?
-- Tags overload the directory hierarchy metaphor. Designing a
rational directory layout for large or complex projects is a
challenge enough anyway. Having to factor in the trunk/tag/branch
structure adds very significantly to this complexity.
Well designed software/tool systems exhibit the virtue that simple
problems are solved simply and complex problems are solved using more
complex techniques, hopefully with linear scaling. As currently
designed, Subversion fails this for simple workflows (e.g. a simple
linear development cycle). It doesn't ... I repeat: it *doesn't*
work. I know that, I've watched teams trying to use it, and _wanting_
to use it, but failing because they are being forced to use overly
ornate techniques on simple problems.
At heart, Subversion is a historical database. But for some reason
there seems to be huge resistance to annotating this database in ways
that seem useful to people. Labels: not allowed! Revision properties:
disabled by default, and anyway they cannot be set during a commit,
leading to silly catch-22 issues with state. Log messages: so
overloaded parsing them is an exercise in unwarranted optimism.
As a source repository that contains the "crown jewels" of many
projects, I would have expected the ability to annotate the database
in ways that are meaningful for my workflows, and then query the
database using those annotations. Apparently, however, this is
thought of as a bad thing by the subversion community. So be it; but
the net result will be to significantly limit Subversion's
applicability.
ok, rant over: it's Friday night and I'm off for a beer! Cheers!
--Tim
On Nov 17, 2006, at 5:37 PM, Les Mikesell wrote:
> On Fri, 2006-11-17 at 18:48, Tim Hill wrote:
>>>
>>>> My point is I *have* to commit the copy and the fix at the same
>>>> time,
>>>> else how can the tag truly reflect the point in time where the fix
>>>> occurred? If I commit the fix and *then* create the tag I have two
>>>> distinct commits, and there always exists the possibility of
>>>> another
>>>> commit sneaking in between the first and the second:
>>>
>>> I don't get it. Why wouldn't you commit to the trunk (if you even
>>> want the change to appear there), then copy your working copy to
>>> the tag so there is no chance of anything changing that you don't
>>> want in the tag.
>>
>> Eh? So I have a tag that claims to reflect a change, but on closer
>> inspection the change did *not* occur at that commit? Sounds like a
>> nice confusing mess to me.
>
> The change _does_ exist in the tag. That is, the tag does
> not exist until the snapshot of the workspace is committed.
> If you want that copy you use the tag and what's in the
> trunk is not particularly relevant. As you noted in your
> example, someone else can modify the trunk any time so you
> can't trust what is there unless you have a revision number
> you know happened as a commit from a workspace in exactly
> the right state. So why not use the tag committed from
> there instead and let the trunk go about its business towards
> the next one? If you want the change on the trunk for future
> versions, commit it there too, but there is no need for that
> step to be atomic with anything.
>
>>>
>>> Call them snapshots or whatever you want. If they want to preserve
>>> an exact duplicate of their workspace, just:
>>> svn copy -m "my message goes here" . URL:/tags/my_name_for_this
>>>
>>> It's not difficult, has no issues with being atomic, and you
>>> get your choice of ever making the changes that appear here
>>> also appear in the trunk or not.
>>
>> It's also not really the point: I want a symbolic identity for a
>> commit. I don't really see how this helps.
>
> But that's what you get when you name this tag. What is the
> problem with using this tag name anywhere you might have
> used a revision number or the label that you'd like to
> refer to one?
>
> --
> Les Mikesell
> lesmikesell@gmail.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 Sat Nov 18 09:18:15 2006