Tim Hill wrote:
> ok, I'm pulling my hair out on this one.
>
> The problem, basically, is atomicity and simplicity. Why?
Ok, I think I get it... I'm trying to fit this in an earlier suggested
solution (in another thread).
Actually I did already understand the problem of atomicity and
simplicity (especially simplicity is important here) but because I've
got no scenarios to measure it against, it's more difficult to
understand/explain.
> Scenario: I fix a bug in "foo.c". I want to check it in, and annotate
> the check-in some way that is (a) meaningful and (b) can be used later
> in other svn commands to reference the file in question at the
> appropriate rev#.
>
> Solution 1: Use a "magic" string in the log file at commit time. Yuck.
> The log file is already overloaded with too much magic, and anyway I
> cannot use it for (b) without a script hack. The workflow is:
>
> -- svn checkout foo.c
> -- (edit foo.c)
> -- svn commit -m "LABEL:12345 blah blah"
>
>
> Solution 2: A tag. But wait; creating a tag takes a copy operation,
> which is a commit. I *cannot* do my foo.c commit and then follow this
> with a tag operation, since these are two distinct commits. So I _must_
> create the tag in my working copy and then commit both the tag and the
> fix at the same time. The workflow is:
>
> -- svn checkout foo.c
> -- (edit foo.c)
> -- svn copy foo.c $TAGS/label12345/foo.c
> -- svn commit -m "blah blah"
>
>
> Solution 3: A label. The workflow is:
>
> -- svn checkout foo.c
> -- (edit foo.c)
> -- svn commit --label "12345" -m "blah blah"
You're point here is:
* Making a single command that can:
* Do a commit and
* Attach a label
* Without having to care for a location.
Am I right?
This would fix:
* Forcing people to enter location and with this the *need* to
understand how something is stored.
* Having to do several operations.
> Now, you and I and everyone else on this list probably understands #2
> perfectly. But what about tech writers? Graphic artists? At a stretch, I
> have been able to get them to understand checkout and commit, but tags?
> Forget it. Too much baggage. So they get it wrong. Which is easier to
> clean-up? A bad label, or a bad branch? What if they forget the copy
> entirely? Put the tag in the wrong place?
>
> There are many, many users of tools like subversion who are not deep
> experts in scc subtleties. All they want is a simple linear system they
> can dump stuff into and occasionally flag a "significant" event with a
> label. Tags used in this context for this class of user are like the
> proverbial sledge-hammer to crack a nut.
Reading this I get a very strong feeling that we need some sort of a
"wizard" for making difficult steps easier.
(So it's not really about the labels being wrong, it's about the labels
being too difficult for the simple users.)
> And is this *really* too much to ask? I've seen literally dozens of
> posts asking for this feature or something very much like it. Will it
> destroy the "purity" of subversion, or lead to feature bloat? Currently,
> subversion has an "svn:author" property, and I cannot think of any a
> single argument that has been leveled against labels that cannot equally
> apply to this property, and yet no-one is proposing to deprecate this
> "feature".
>
> --Tim
Well, I have to say, you did a great job explaing with a nice scenario.
Danny
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Nov 17 22:19:57 2006