[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Subversion, decentralized version control, and the future.

From: Ph. Marek <philipp.marek_at_bmlv.gv.at>
Date: 2007-07-04 15:06:29 CEST

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.



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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.