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:33:46 2006