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

Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?

From: BRM <bm_witness_at_yahoo.com>
Date: Tue, 21 May 2013 13:58:44 -0700 (PDT)

> From: Andrew Reedick <Andrew.Reedick_at_cbeyond.net>

>> -----Original Message-----
>> From: Les Mikesell [mailto:lesmikesell_at_gmail.com]
>> Sent: Tuesday, May 21, 2013 3:53 PM
>> To: Andrew Reedick
>> Cc: Branko Čibej; users_at_subversion.apache.org
>> Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams
>> aka Branches as First Class Objects?
>> > The client should only see and work with "--project project1
> --branch
>> 1.0", e.g. "svn co --project project1 --branch 1.0" to
> checkout a
>> branch.
>> That's sort of like saying filesystems shouldn't have
> subdirectories so
>> users don't get confused...  Some people might even believe that.
> And there's a reason why 'pwd' returns '/home/userid'
> instead of '/dev/sda1/home/userid' or
> 'server-vol0.foo.net:/vol0/userid'.  Or why 'cd ~' takes you to
> your home dir. 

Well, "cd ~" is imposed by the shell environment, not by kernel.
And /dev/sda1 being / is imposed by the kernel, not the shell; but the kernel only knew to map it that way because the user told it to.
The issue is the same as with SVN. SVN does not know anything about what users mean by the URL paths; it only knows about the paths it implements.
A higher level piece of software could do additional mappings and hide all those details - just like the kernel does for user level programs when it is told to map /dev/sda1 to /;
but that higher level piece of software has to be configured to do that, just like the kernel does.

>> > It's about presentation.  Keep the superfluous dir components
>> internal and hidden from the average user.  We've already seen a move
>> towards information hiding with the'^' syntax that hides the server
>> component.  This would be the logical progression.
>> It's about organization.  And letting you arrange your own conventions
>> to match your processes.
> We'll have to agree to disagree.  We're back at the low level
> "managing dirs" versus high-level "managing baselines"
> arguments/thinking/paradigms.

As others have stated, SVN provides the engine to do the work - just like the kernel provides the engine to read the disk drive.
However, unlike the kernel it has no higher level functions that do mappings it can understand. It's just the core, and while it is pretty smart about what it does
it is also pretty dumb about what it doesn't do - just like a kernel file system driver is very smart about reading the file system but very stupid about what the
directories or files the user puts in the file system mean.

Or more to the point, you can think of it like this:
Apache2 = Kernel - maps https://mysvnserver/svnrepopath to /
SVN = File System Driver for the kernel

Of course, "svnserve" mixes the two, but that's really the gist of it as it relates to your example.

Received on 2013-05-21 22:59:16 CEST

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

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