ok, I'm pulling my hair out on this one.
The problem, basically, is atomicity and simplicity. Why?
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"
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.
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
On Nov 16, 2006, at 3:13 PM, Danny van Heumen wrote:
> Nikki Locke wrote:
>>> Workflow 1 (today): (1) enter: svn info <some-url> (2) manually
>>> scan the output for the rev#, call it X (3) enter: svn diff foo.c
>>> -r X:HEAD
>
>> OK, now I've been told the (rather obscure, IMHO) extra syntax
>> needed, how about trying Workflow 3...
>> (1) enter: svn diff --new foo.c --old <some-url>:HEAD
>
>
> Workflow 3 is about a revision range, like -r 100:200
>
> I think you need the following:
>
> 'svn diff --new foo.c --old <some-url>@HEAD'
>
> or
>
> 'svn diff --new foo.c --old <some-url>'
>
> should work too because it'll default to HEAD.
>
> Danny
>
> ---------------------------------------------------------------------
> 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 Fri Nov 17 02:15:53 2006