Vincent Starre wrote:
> The confusion of your actual intent comes from my having no idea why
> you'd want to tag something (a revision number) which is, by itself
> (without an associated path), meaningless. (note that HEAD is the only
> current 'alias' which has no path associated with it, and using it
> tends to be a Bad Idea[tm])
Perhaps the confusion stems from your thinking of it in terms of
tagging; a terminology which I have striven to avoid.
> If you are talking about "What was the state of this component when
> the state of this other component was this", note that svn:externals
> can be linked to a specific revision.
In my last e-mail, I specifically mentioned merge tracking--for which
you need to know a specific revision number. Current best practice has
that number buried in a log message. I'm sure others can come up with
other examples of potential uses.
> Note that svn does not currently support _any_ repository-wide
> properties. As I mentioned, this is something which is being looked at
> in issue 1054
What about revision properties, such as svn:log? Not that that's all
that relevant to the discussion.
> I know your specific proposal for how to implement this explicitely
> said "does not change the wc", but your specific proposal seems too
> limited to be useful (unless you can explain further).
And here I thought clear, simple proposals were prefered over grandiose
plans. My proposal was to create a new tool for people to use, without
removing or modifying any existing tools. I've provided the example of
merge tracking, where it would be useful.
> Barring all logic, you could always set up your repos to have a single
> "tags" directory and "main" directory at the root, and svn cp
> svn://repos/main svn://repos/tags/WHATEVER whenever you want. "cheap
> copies", you know.
YES, I know about cheap copies, and that you can create tags whenever
you want; I also don't think it's related to my proposal, or to my
specific example where my proposal would be useful (and note that merge
tracking is one of the "often asked for" features that subversion
currently lacks).
> *Wasn't SVN created specifically to get away from the limitations of
> CVS? If SVN doesnt have those limitations, why try to hack them on? :)
Because my proposal isn't to limit SVN at all. Have I proposed not
using subversion's tags? No. Have I proposed crippling svn copy to
prevent tags? No. I'm proposing *adding* functionality that does not
currently exist in subversion, with behavior very similar to CVS's
tags--which we both agree are limited. Subversion's tagging system is
superior to CVS's tagging system, but that doesn't mean that there's no
use for the functionality provided by CVS's system.
> **The general philosophy of "don't create a whole new namespace when
> the existing one is robust enough to support the required feature" is
> probably relevent
It may be, although I would argue that the existing one isn't robust
enough. Care to address my specific example, rather than arguing
theoreticals?
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Feb 24 19:29:27 2006