On Mittwoch, 4. Juli 2007, Branko Čibej wrote:
> Ph. Marek wrote:
> > To this I'd like to mention that the *technical* aspect of "just a
> > directory structure" is one of the most valuable design choices in
> > subversion (IMHO, at least).
> Why? I'm really interested: What, exactly, do you (we) gain by that?
- Extensible
- Versatile
Eg. you can easily do some debian-like naming "experimental",
"unstable", "testing", "stable" and merge in this directions.
- Easily understandable to anyone who knows directories/folders
(At least, if not the "old" understanding of CVS' tags/branches as a
new dimension is present).
I think that this point is *the* point for new users.
- As soon as the information "Make pointer to old data" is given, all
implications follow naturally.
> Compared to all the real pain it's causing.
What pain does it cause?
Make "tag:A" be a synonym for "$URL/tags/A", and if another layout is present,
require a "svn:layout" property in $URL.
Then use "svn cp . tag:A", or "svn diff tag:1.1 tag:1.2" or whatever.
Similar for branches. Result? No visible difference to CVS (for the user).
(Please take that with a grain of salt. I have surely overlooked some point
which makes that more problematic).
[Of course, that could clash with files named "tag:*". But this problem exists
with directories named "http:", too, no?)
> > Please don't change that.
> Obviously you can always map two namespaces into one by adding a level
> of indirection.
Right, and that's what makes subversion so powerful IMO - the extensibility
(w.r.t. the repository layout).
Naturally there could be ways to do trunk/branches/tags invisible to the
casual user (like NTFS hides its internal files from the user, by just
showing a subtree), which would make no difference for me.
But then there'd be at least the addressing issues again ... so just map the
destination into the path.
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 4 15:06:19 2007