> 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-help@subversion.tigris.org
Received on Fri Jun 30 23:09:42 2006