Vincent Starre wrote:
> Such would need to be client-side in order to make any sense at all,
> and that itself doesnt make any sense at all :)
Yes, it needs to be client-side; that's why I proposed 'svn alias'
rather than 'svnadmin alias'. The goal is to simplify the user
experience, and introduce more options. I'm not sure why you claim it
doesn't make sense; let me respond to the rest of your comments and see
if I can clear any confusion up.
> 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.
Um, where did svn:aliases come from? And, why would you store this in
an individual working copy? I explicitly said, "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." This is
similar to what revision properties do, though with the added ability to
use the alias in place of a specific revision number. Issue 1054,
dealing with default properties, is completely unrelated.
Are you perhaps thinking that I mean for this to be a property on a
specific folder of a working copy? That, I agree, definitely wouldn't
make sense (especially as those are versioned, and would soon have the
property assigned to multiple revisions).
> 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
> :)
This is also unrelated to my suggestion. I never suggested this was a
way to shorten down repository path access; that was something that was
brought up in the thread I responded to, but not in my proposal. I also
did not propose this as a replacement to the "tags" svn already has,
although some, who don't need the full power svn provides with it's
"tags are just copies", would probably use it as such. My proposal is
simply to give the user the ability to create their own aliases along
the lines of HEAD and PREV for specific revisions--surely you can see
some use for that? Perhaps a way to assist in merge tracking (after
each merge, update the 'branch_last_merged' alias, for instance)?
> 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)
This has nothing to do with my proposal.
> 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.
You know, if my proposal had anything to do with paths in the
repository, this line of commentary might be relevant. Since it
doesn't, well...
> 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
Ah, after staring at these examples for a while trying to figure out
what you were talking about, I think I finally understand the root of
the confusion. You're talking about creating aliases for paths; I'm
talking about creating aliases for revisions. Two very, very different
things. Was I not clear enough in my proposal--where I said I wanted to
"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."? HEAD and PREV have nothing to do with paths
into the repository.
> 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 :)
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.
Regards,
-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 18:01:24 2006