[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [DESIGN] Aliases? (Was: RE: Re: I, too, miss tags.)

From: Vincent Starre <vstarre_at_comcast.net>
Date: 2006-02-24 18:43:15 CET

Gale, David wrote:

>In short: no, it's not. It may be needed for what you thought I was
>proposing, but it's completely unrelated to what I in fact proposed.
>
>
So you want to be able to say:
svn co -rWhenSomeDirectoryWasAtAParticularState
svn://repos/somethingCompletelyUnrelated ?

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])
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.

If you could clarify that, I could probably better understand what
actually needs to be done.

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

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).

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.

*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? :)
**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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Feb 24 18:45:50 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.