Rob van Oostrum wrote:
>> -----Original Message-----
>> From: Gale, David [mailto:David.Gale@Hypertherm.com]
>> Sent: Monday, February 27, 2006 4:12 PM
>> To: Frank Gruman
>> Cc: Greg Hudson; users@subversion.tigris.org;
>> dev@subversion.tigris.org Subject: RE: [DESIGN] Aliases?
>
> [snip]
>
>> Ok, so, under my system, you hit release 1 and tag it; you find a
>> bug, and issue a "svn copy -r REL_1 <repos>/trunk
>> <repos>/branches/1.1-fix" command. Amazingly enough, SVN's
>> branching functionality supports this.
>
> I need to know what trunk/branch the tag ACTUALLY refers to for this
> to work. What if REL_1 of the application was actually released off a
> (different) branch? This scheme is only meaningful in the context of a
> convention of how you layout your repository and when/where you
> release versions of your code from. A user could just as easily do:
>
> 'svn copy -r REL_1 <repos>/branches/rel_2_dev
> <repos>/branches/1.1-fix'
>
> From the context of the command this is correct and would return you a
> copy of the code that - because you passed the REL_1 tag - you assume
> to be REL_1 of the code, yet it isn't. The REL_1 tag in your example
> is only meaningful when knowing what subsection of the repository it
> actually relates to.
True. Perhaps I failed to follow our (hypothetical) company's alias
naming policy when I came up with "REL_1"; perhaps the policy is that it
should be "TRNK_REL_1", or something like. Revision alias naming
conventions should be dictated by the people using the repository, as
they're the ones who know what the revision aliases actually mean.
To your counter-example, assuming a standard company naming, release,
and branch policy (not hard to imagine), then whoever made the branch
you proposed should get written up for failure to follow policy. But
that's an institutional concern, rather than a version-control concern.
(It's also irrelevant to the discussion, as the exact same thing could
happen with the current tags system.)
-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 23:13:27 2006