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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Feb 27 20:47:12 2006