>> So should SVN get rid of its tags-as-copies? Of course
>> not. I don't think anyone is saying that. Should it adopt
>> a CVS-style tags instead? I'm not sure anyone is saying
>> that either. I think their just saying there is this other
>> use of tags as attributes/properties that is orthogonal
>> from tags-as-copies and I want to be able to do that too,
>> and I want to consider it separately in the UI as well
>> (whether or not the implementation does or not is
>> another matter :-).
> [...]
>
> In other words, you're essentially asking for "syntactic sugar" in
> dealing with tags, independently of how they're actually implemented?
> If this is the case, a few wrapper scripts around svn would do the
> trick. Tags will still be implemented the way they are, but this would
> be abstracted away in the wrapper scripts, and you'll have a
> consistent, blackbox interface for manipulating them.
>
> This could be coded into svn, but I wouldn't want to do that, since
> different projects have different setups, and some people could decide
> to have a global /tags directory, and others a per-subproject tags
> directory, and yet others may not want such a thing at all. I think
> it's good to keep the basic features a consistent, minimal set, and
> build on top of that according to your needs.
Isn't reducing the number of external scripts, wrappers, etc. for
common tasks a good thing? That's why svn, cvs and all other
programs with a user interface (command line or otherwise) has a
set of built-in capabilities. How about:
svn immute URL/ReleaseXYZ
or
svn freeze URL/ReleaseXYZ
or
svn stop URL/ReleaseXYZ
...or some such other syntax. This won't get in the way of anyone
who does business some other way. And don't restrict this command
to have to be under a subdirectory named ./tags. This keeps it as
flexible as anyone could ever want.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Sep 24 22:07:31 2004