> I've read this three times, and I'm still confused
why this is any better
> than current "cheap" copies. I see your
proposed solution /
> implementation,
> but I don't yet understand why it is substantially
better enough to
> warrant
> the added functionality. I suppose the only value I
see here (and is
> solved
> by Subclipse) is that you'd have some record that a
tag were created in
> the
> source. Beyond that, I'm not really sure. Maybe I
need to read it a
> forth
> time.
You are basically right, and as I said, the solutions are
fundamentally
the same.
These are the benefits:
1. There will be a command for tagging. This is pedagogical.
2. The tag commands will be more compact. (E.g. 'svn tag
version-1.0', or
'svn diff -r v1.0:v1.1')
3. The tags are naturally stored with the target it is
tagging, and not
some arbitrary other place decided by convention. I believe
most user do
not care where the tags are stored.
4. When refactoring the repository layout, you do not have
to worry about
also moving the tags directory, and to where. The tags
follow the project
root directory.
These are the down-sides:
1. It will be impossible to make a non-flat tag directory
structure.
2. It will be impossible to make a tag directory contain
tags for
different TARGETS. (But you should never need that?)
3. Make for larger downloads of the project root directory,
because one
has to download all the tag properties too. (I am not sure
about this, but
it might add up to 10kB extra?)
I do not consider any of the down-sides as important.
Although the copy
mechanism is very cool technically, I believe it is neither
easy to
understand nor easy to use. And so even if the suggested
solution is
technically similar, I believe it is a better because of its
improved
user-interface.
Håkon Hallingstad
------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribe subversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org
|