> From: Andrew Reedick <andrew.reed...@cbeyond.net>

>>  -----Original Message-----
>>  From: Les Mikesell [mailto:lesmikes...@gmail.com]
>>  Sent: Tuesday, May 21, 2013 3:53 PM
>>  To: Andrew Reedick
>>  Cc: Branko Čibej; users@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.

Ben

Reply via email to