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

Re: FW: [DESIGN] Aliases?

From: Max Bowsher <maxb1_at_ukf.net>
Date: 2006-02-25 11:24:27 CET

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gale, David wrote:
> robert@infotility.com wrote:
>> Quoting "Gale, David" <David.Gale@Hypertherm.com>:
>>
>>> 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.
>> I think all of this is right on the mark.
>>
>> Since we know already that symbolic aliases are useful
>> (HEAD, BASE, etc) why not set up a mechanism to allow
>> users to make new ones?
>>
>> Various correspondents have suggested workarounds or
>> hacks of various kinds. Thanks guys, but if there's
>> evidence that there is widespread desire for this feature
>> (namely that it has been solved multiple times by
>> multiple persons) why not just build it into the standard release?
>>
>> Thanks a lot to everyone who has responded.
>> I appreciate your help.
>>
>> Robert Dodier
>
> Any thoughts from the dev list, before I add this to the issue tracker?

I'm sorry, but this most recent discussion doesn't appear to have
covered any new ground compared with its previous incarnations.

The proposed design replicates major disadvantages of the CVS model, for
the sole advantage of shorter command lines;

* Unversioned: You can't tell who or when 'aliases' were created, nor
track the history of an alias that undergoes changes.

* Unscoped: It would be far too easy for multiple projects in the same
repository to clash on their alias naming.

And, most of all, there is the conceptual weirdness of having two
totally different UI paradigms for supporting the same goal.

Regarding the specific example of merge tracking which seemed to be the
major justification employed in the users@ thread: This is _entirely_
possible with properties - indeed, see svnmerge.py in contrib/ for a
very nice front-end to merging, which does far more than is
accomplishable with 'aliases'.

Max.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)

iD8DBQFEADBbfFNSmcDyxYARAgDWAKCWuqd9lcHHWyo1+PQHIDLIINQ0QgCcCAac
vJLWHEthNXqF+muDyomn3ZM=
=Y0/L
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Feb 25 11:26:51 2006

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

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