Tim Hill wrote:
> I don't think it really matters what I'm trying to accomplish, my point
> stands.
At the moment I'm just trying to understand your point, I'm not ready to
convince you yet because I don't know yet what to convince you of. (It
was clear my earlier post was not entirely on-target so I'm trying to
find out what target I need to hit. Whether it's you convincing me, or
me convincing you.)
Maybe you didn't notice, but I'm keeping an open mind, so if you have
got some example cases where SVN *is* really cumbersome to work with,
then I can understand your point.
> There are a number of valid workflows that require the entry of
> revision numbers in a command that are obtained from the output of other
> commands. These "feedback" workflows are cumbersome when the rev# has to
> be transferred by hand or by some script magically parsing the output of
> an info/status/log command. If you want examples, go scan the svn-book,
> which is full of them.
Could you name some of those workflows? Or could you name sections of
the svn-book which make your point clear?
> The "we need labels" argument that keeps on coming up in this forum is,
> imho, not about the lack of symbolic identifiers for revision numbers:
> everyone points out again and again (correctly) that tags do that.
OK, this helps a little in understanding where you're going to.
> It's about the need to directly *input* these revision numbers symbolically
> into commands. Tags _don't_ do this because the last step in the
> "feedback" loop is missing: I cannot use the tag on the command line to
> represent, symbolically, a revision number. That was what I was trying
> to show by my example.
I've got this stupid feeling that we don't need more commands, but that
we just need to input other arguments to get the same result.
(Repository location instead of revision number)
But like I said, I can't figure out what kind of Use Cases you're
working with, so it's probably just my lack of imagination that gives me
this feeling. (Probably because I haven't seen much company scenarios yet.)
Danny
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 16 01:09:22 2006