Re: FW: [DESIGN] Aliases?

Hi Gale!

Your proposal sounds very complex to me
(e.g. a complete new mechanism of version controlling labels),
and seems only duplicating existing functionality,
just to get a new user interface.

I think it is very elegant of SVN to use the same version control
mechanism for the content, for tags, and for everything in your repository.
A simple powerful mechanism for everything. :-)

CHeers,
Folker


Gale, David wrote:
> Folker Schamel wrote:
>> Gale, David wrote:
>>> Ok, I'm confused.  Tags are immutable, but they're mutable? To my
>>> mind, a tag is not mutable--once created, it should not (at least
>>> 98% of the time) be updated, and there shouldn't be any reason to
>>> remove it. 
>> The *content* of a tag usually is immutable.
>> But a tag (alias label) may change.
>>
>> For example, a tag "latest_stable_version".
>> Or when using SVN for websites,
>> then using a tag for the version which is currently online.
>> Also in CVS labels are used often for such purposes.
> 
> So, again, I suggested the '--force' option to allow for changing which
> revision a label points to.  Seems much easier than the merge command
> you're forced to use by treating tags like branches, or the (perhaps)
> better path of dropping the tag directory and then re-creating it.
> 
>> And you want to version control such information,
>> which is not possible in CVS.
>> In this respect the SVN model has significant advantages
>> to the CVS model I think.
> 
> As others have stated, there'd be no reason the list of aliases (or
> labels, or tags, or whatever names you want to assign it) couldn't be
> version-controlled.  So this snide jab at CVS is unwarranted.  (Which is
> not to say that snide jabs at CVS aren't warranted in general; just that
> this particular one isn't.)
> 
>>>> And in both cases you might want to version control such operations.
>>>> Furthermore, you want to have hierarchical namespaces
>>>> both for branches and tags.
>>> Why would you want hierarchical namespaces for tags?
>> Well, why do you use subdirectories on your harddisk? ;-)
> 
> I don't use hierarchical structures on my watch.  Do you?  Revision
> aliases are simply that--aliases for specific revision numbers.  An easy
> way to reference a specific point in time.  An alternative to specifying
> the number explicitly in '-r 451623'.  Revision numbers are not
> hierarchical, so I don't see a reason to try to force them to be.
> 
>>  > There's no
>>> hierarchical namespace for revision numbers.  And, frankly, the
>>> thought of 'svn co -r proj1/releases/1/2/8
>>> svn://example.com/repos/proj1' scares me.
>> The correct command is just 'svn co proj1/releases/1/2/8'.
> 
> No, the *standard* command is 'svn co <server>/tags/proj1/1.2.8/', or
> something similar.  Correctness depends on the server setup and what
> options are included in the examples (ie., assuming my proposal were
> implemented, the 'correct' command could be 'svn co -r PROJ1_1.2.8
> <server>/proj').  My point was that hierarchical revision aliases lead
> to other issues (ugliness being an obvious one), with no clear benefit.
> 
>> Yes, SVN uses a different approach than CVS,
>> and this may scare people being used to the CVS philosophy.
>> But as often, after being used to a new philosophy,
>> then you can see the advantages. :-)
> 
> This is an amusing assertion, when you've gotten people who a) aren't
> used to CVS, or b) have given themselves plenty of time to get used to a
> new philosophy, who've publicly stated that they would like to have this
> option available.  Just because the behavior is similar to that offered
> by CVS doesn't mean that only CVS users want it, or that it's something
> SVN shouldn't (better get rid of svn diff, otherwise).
> 
> A thought: it's somewhat standard practice to indicate in whatever issue
> tracker a team is using which revision solved a specific issue.  With
> revision aliases, it would also be possible to create an alias whenever
> an issue is dealt with, allowing 'svn log -r ISSUE_1423_FIX', for
> instance.  One more method of tracking important information.  Is that a
> bad thing?  (And yes, you could copy a tag for every revision; I'm not
> arguing against that.  Just trying to present one option where revision
> aliases might co-exist peacefully with the existing tags
> procedure...ie., you could alias issue resolutions, while only tagging
> releases...)
> 
> -David
>