hakon@ion.no wrote on 06/30/2006 07:22:13 PM:
> > On 6/30/06, hakon@ion.no <hakon@ion.no> wrote:
> > What's confusing here is that you're offering a solution to something,
> > but nobody seems to understand what that something is. What's the
> > problem you're trying to solve? Before you can propose technical
> > solutions, you need to persuade us that there's a problem with
> > subversion's current tagging system.
>
> I want to simplify and enhance tagging in Subversion. I also would like
to
> make Subversion tagging feel more like other version control systems',
> because I believe the current scheme is unnecessary difficult to use and
> understand.
>
> Here is my list of possible improvements to the Subversion's tagging
scheme:
>
> 1. The user should not need to be bothered with _where_ the tag will be
> stored.
>
> 2. The Subversion 'tag concept'* should be the same as other VCS', as
the
> Subversion concept does not add any value and confuses newcomers.
These sorts of items are classic examples of where the answer seems like
you would be best served by looking at another version control solution.
The things you do not like are essential parts of the Subversion design.
They are not flaws, they are intentional. Personally, I love this design
and think it is extremely intuitive and easy to understand.
> 3. In line with (2), commands like 'svn up -r v1.0' should work as
expected.
This has been mentioned before. Thus far a design has not emerged that
was worth implementing. There are techniques using shell variables that
can work. Not that that is the ideal solution, just that the proposed
designs have not been better enough to make it worth doing.
> 4. Subversion should 'know' of tags. E.g. look at what Subclipse have
done
> because Subclipse knew about the tags, and realise that Subversion
should
> support this natively. (Now the user had to locate the tags directory
for
> Subclipse.) In an earlier email I was telling about a possible 'svn
> taglist' command that displays "TAG REVISION AUTHOR DATE" for all tags,
> which is excactly the command-line version of one of the features of
> Subclipse.
It would be nice if the command line could do some of the similar things
we are doing in Subclipse, but to be honest, the Subclipse solution can
work because the project/repository structure within Eclipse is very
predictable and consistent. It would be a lot more difficult for this to
work "in general". There are some changes to SVN properties that have
been discussed that could make this more viable, but the design has been
tricky to nail down.
> 5. Subversion should get a 'tag' command to make the intention clear.
(In
> its simplest form, it could be another alias for 'copy'.)
The Subversion developers have been very much against subcommand bloat.
Adding "tag" as an alias for copy would be a terrible idea because if a
good design for tag improvements surfaces in the future the subcommand
would not be available.
> 6. Subversion should provide a more compact syntax for tagging. Say 'svn
> tag -r REVISION TAG', or 'svn tag --force NEWREVISION' to update an
> already set tag, or 'svn taglist' for displaying tags.
These things can be done with shell variables and a lot of other
techniques.
> *) The Subversion concept of a tag is that it is a directory (in HEAD).
> While other VCS uses a concept of tags which is a revision number (or a
> path and a revision number).
>
> The proposed solution of putting tags as special properties solves all
of
> them.
It doesn't, and without major API changes to properties it couldn't work.
Your proposed solution was not very well thought out. Look at the Apache
repository at http://svn.apache.org/repos/asf. There are 39 different
projects. How could you store all of the tags in revision 0 of the
repository root and have the feature work and have meaning? Doing
something like Subclipse where the properties are stored as versioned
properties within the repository would work conceptually but there are a
lot of real API hurdles to overcome before that could be done. It might
be worthwhile to head further down this path and work up a real design,
but I have a feeling that to implement this "tag" feature you would have
to dive into large thorny areas like changing how properties work.
When all is said and done, the problem is that there are a large number of
people, myself included, that do not really think anything is broken and
needs to be fixed. We know it is different in some ways, but we like
those differences. If you can "bridge the designs" without compromising
what we like, then great.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jul 1 02:51:37 2006