Such would need to be client-side in order to make any sense at all, and
that itself doesnt make any sense at all :)
Even if it would simply pick up svn:aliases from whatever wc it were
pointed to (again, makes no sense since not all commands take a wc
argument) it would be near-useless if it werent inheiritable (issue
1054) and so at the very least I think it should be delayed.
Though this is probably (again) just me, I still think actually doing
something with an $SVN_ROOT (or, if you prefer, %SVN_ROOT%)
environmental variable would cut down on all the typing enough that
these "I miss tags" people would just accept the tags svn already has :)
Of course, the desire to operate on multiple repositories is the primary
reason for not wanting an $SVN_ROOT. I propose no solution, and say only
that this limitation also would make an $SVN_ROOT near-useless and make
very little sense (especially as one who hopes for an svn patch command
some day)
Yes, the tags svn has support for are longer, but the lack of ambiguity
that provides is a good thing.
As mentioned in an earlier message in this thread, I think a way to
specify paths "relative to the wc", or maybe even "relative to another
path provided elsewhere in the command-line" could solve a lot of the
"it's too long" issues.
Example (merging 1.9.8->current into wc of a branch):
svn merge svn+ssh://warehouse/main/tags/1.9.8 +../trunk .
or maybe (assuming wc, given no original path):
svn merge +../../tags/1.9.8 +../../trunk .
though perhaps this could help aliases:
svn merge +~1.9.8 +~trunk .
meaning "check aliases in . for 1.9.8, etc", so you could specify which
aliases to look at.
Maybe even stack them:
svn merge +~trunk+~1.9.8 +~trunk .
meaning "check aliases in . for something called trunk, check it's
aliases for 1.9.8", etc
All considerations stemming from "even if it's repository-wide, you'd
still need to give the repository in the first place, so you're still
right back where you started" (not that we have repository-wide props ;))
In short: I think 1054 is needed for this to work at all :)
Gale, David wrote:
>Kent Borg wrote:
>
>
>>On Thu, Feb 23, 2006 at 07:44:17PM -0800, Ron wrote:
>>
>>
>>>I agree. There is a lot I love about SVN over CVS (and VSS) but
>>>sometimes I just want simple tags. It is true that subversion's
>>>system can do everything tags can (and then some), but it's more
>>>cumbersome to use. I don't want to have to know the structure of
>>>the repository (/tags, /release, /trunk, etc, etc) just to snap a
>>>symbolic name on a revision to help my memory down the road.
>>>
>>>
>>Another former CVS users here, one who likes subversion but one who
>>also finds the lack of tags unnerving.
>>
>>One thing I have is a tags.txt file (that I also keep in subversion),
>>and in it I keep notes. For some notable versions (e.g., "New feature
>>X is working, I think") I note the date and version number along with
>>a short comment.
>>
>>
>
>Perhaps we could satisfy all of our former CVS-acolytes (myself
>included) with a "svn alias" command (or some such), which would assign
>a human-readable name to a specific revision. HEAD, PREV, and the like
>already exist, but there's currently no way to assign one of the user's
>own creation. I'd propose something like:
>
>svn alias [-force] [-r 21134] NEW_LABEL [path-to-repos]
>
>If the command is run within a working copy, the path to the repository
>should be picked up from that. If no revision is specified, HEAD should
>be assumed. If the NEW_LABEL alias already exists, an error should be
>thrown unless -force is specified (matches CVS's behavior). This
>doesn't change the working copy; it creates a versionless alias on the
>repository, which would then be available for future "-r <alias>"
>commands. I'd also suggest a "svn alias -list" command, which would
>list all of the aliases in the repository and the revisions they point
>to.
>
>Comments?
>-David
>
>---------------------------------------------------------------------
>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 Feb 24 17:01:16 2006