Re: Subversion: existing users

[Andy Canfield]

On 07/20/2011 12:14 PM, Nico Kadel-Garcia wrote:

On Tue, Jul 19, 2011 at 10:30 PM, Andy Canfield
  wrote:


For example, I am on a Linux box named Lenny, logged in as 'andy'. I can ssh
to hk.pimco.mobi as user 'andy', password 'psuedo'. But I don't want to.
Instead, I would like to run the command:
svn ... http://hk.pimco.mobi/svn/RepoName --username=andy
--password=psuedo

Whoa there nelly. You're mixing apples and oranges and kumquats. Go
right over to the Red Book, and read the descriptions of *each* of
HTTP, svnservee, and svn+ssh. Keep them distinct.
Apparently I read the wrong "Red Book". I read the one for the old 
version, not the "nightly build" Red Book. I shall download and install 
and read the Nightly Build Book.


As far as I know 'svn' is the name of a client program, which can 
communicate with any server, and 'svn' is also the name of a protocol 
that the svn program uses to communicate with a server program named 
"svnserve".


My impression was that there were three possible "servers", namely 
Apache, svnserve, and direct (file) access, and that which server was in 
use was controlled by the URL.


The example command:
*svn ... http://hk.pimco.mobi/svn/RepoName --username=andy*
is a valid client command. The URL starts with "http://"; so it is 
expecting to talk to the Apache-based Subversion access channel, e.g. 
mod-dav*.so, located on hk.pimco.mobi.


A similar command:
*svn ... svn://hk.pimco.mobi/svn/RepoName --username=andy
*is also a valid client command, where the URL starts with "svn://" so 
it is expecting to talk to svnserve via port 3690 on hk.pimco.mobi.


The above two commands can run on any computer with a connection to 
hk.pimco.mobi; i.e. any computer with an internet connection. Another 
valid command, which can only run on the server itself, would be

*svn ... file:///var/svn/RepoName --username=andy*

You said that I'm mixing apples and oranges and kumquats. Well, the svn 
client program is like my teeth, which can eat apples or oranges or 
kumquats (three kinds of servers depending on the URL). I usually only 
buy one kind of fruit at a time, and presumably we would only run one 
kind of server at a time. Since we want to have net access, I expect 
that we won't use direct (file://) access for anything except the 
svnadmin program, which as I recall can only be run on the server 
itself. So we are not yet decided on whether to use URLS that start with 
http:// (talking to the server known as apache mod_dav*.so) or URLS that 
start with svn:// (talking to the server known as svnserve).


IMHO the 'svn' program is the client program which requests actions on a 
repository, and the Subversion server, either apache/mod_dav or 
svnserve, contains the code which actually manipluates the contents of 
the /var/svn repository directories.


One quirk is that if he URL specifies direct access, e.t. svn ... 
file:///var/svn/RepoName, then where is the code which actually 
manipulates the contents of the /var/svn/RepoName directory? It must be 
hidden in svn itself, or perhaps svn forks a call to something like 
svnserve as a subtask to get the manipulations done for it, since there 
is no server program already running on the server computer.


I read The Book already, but apparently the conversion from your ideas 
to those words to my eyes to my brain did not result in a replication of 
your ideas.


I read the wrong version of "The Book", the featured but obsolete 
version. I shall download the "Nightly Build" version ASAP.


Thank you very much.


But this does not match what you are telling me. Apparently my brain is
pointed 89 degrees off from the direction your brain is pointed. Please
point me in the right direction.

See the explanations at http://svnbook.red-bean.com/. They go into
much more depth than we can here.


Thank you.


The only well supported solution to this, so far, is to use SSH keys
for a shared account, and to use those keys to use a forced "command"
for that shared account, a "command" that enforces the user's name for
that particular svnserve instance.

I've previously tried, myself, to help set up a restricted shell for
just such access, starting with the "rssh" tool, but didn't get very
far. That would be a significant security improvement, and help
protect the rest of the OS from unauthorized access with valid
Subversion logins with Kerberized or other account access, rather than
SSH keys.

Re: Subversion: existing users

[Stefan Sperling]

On Wed, Jul 20, 2011 at 05:22:57PM +0700, Andy Canfield wrote:
> One quirk is that if he URL specifies direct access, e.t. svn ...
> file:///var/svn/RepoName, then where is the code which actually
> manipulates the contents of the /var/svn/RepoName directory? It must
> be hidden in svn itself, or perhaps svn forks a call to something
> like svnserve as a subtask to get the manipulations done for it,
> since there is no server program already running on the server
> computer.

See this picture for a graphical representation of the various
layers Subversion is composed of:
http://svnbook.red-bean.com/nightly/en/svn.intro.whatis.html#svn.intro.architecture
Each layer has a public API that can be used by other layers.

Clients like 'svn' and TortoiseSVN primarily use the client library's API.
The client library in turn calls into what is referred to as the "repository
access" (RA) library, which selects a repository access implementation
depending on the protocol used (http://, svn://, file://).

But there are exceptions where clients bypass the RA layer.
E.g. if you run TortoiseSVN and select the 'Create repository here'
command (the equivalent to 'svnadmin create'), TortoiseSVN calls
directly into the libsvn_repos API (the API for the big box labelled
"Subversion Repository" in the figure) to create a repository
on local disk.

Getting back to your original question, the so-called "ra_local"
repository access module (labelled "Local" in the figure) which
implements file:// access to the repository calls directly into
the libsvn_repos API to manupilate a repository on local disk.
The 'svn' client is linked to the repository access library,
and hence, indirectly, to the ra_local library and to libsvn_repos,
to support file:// URLs. So you could say that 'svn' contains a copy
of the same code that svnserve uses to access the repository. The
copy is not embedded into the 'svn' binary itself, but is loaded
from a library file (libsvn_repos.dll on Windows) when 'svn' (or
svnserve) is started.

> I read the wrong version of "The Book", the featured but obsolete
> version. I shall download the "Nightly Build" version ASAP.
> 

Unfortunately google keeps showing links to the 1.1 version of the book.
This problem has existed for ages.

odd svn:mergeinfo appearing and causing conflicts

[Tino Schwarze]

Hi there,

we've successfully migrated from CVS to SVN recently and we are now
facing an oddity during merging. We are using Subversion 1.6.17 on
client and server.

Repository structure is like this:

/ourstuff/ourproduct/1.0/MODULES/mod_a
/ourstuff/ourproduct/1.0/MODULES/mod_b
/ourstuff/ourproduct/1.0/MODULES/...

-> mod_a ... mod_x get's branched (=copied) to customer dev branch

/customer/project/1.x/dev/MODULES/mod_a
/customer/project/1.x/dev/MODULES/mod_b
/customer/project/1.x/dev/MODULES/...

-> from there the modules are branches (=copied) to customer prod branch
/customer/project/1.x/dev/production/MODULES/mod_a
/customer/project/1.x/dev/production/MODULES/mod_b
/customer/project/1.x/dev/production/MODULES/...


Then, merges are performed from ourproduct->project/dev, then
project/dev->project/dev/production. (We chose this non-standard branch
scheme because we can see branch relationship that way and also svnsync
only the customer-relevant part of the repository.)

Now we had a mysterious conflict popping up. The first merge
ourproduct->project/dev worked fine but the merge project/dev to
project/dev/production produces conflicts on the svn:mergeinfo property.

The strange thing is: There is no svn:mergeinfo on the source module
(say ourproduct/MODULES/mod_a) BUT an empty one has been created on the
branched module (dev/MODULES/mod_a).

> svn log --stop-on-copy ^/customer/project/1.x/dev/MODULES/mod_a
[...]
r27322 | ...
[...]
   A /customer/project/1.x/dev/MODULES/mod_a (from 
/ourstuff/ourproduct/version/MODULES/mod_a:127321)

> svn proplist -v -r27322 ^/ourstuff/ourproduct/1.0/MODULES/mod_a
(no output)
> svn proplist -v -r27322 ^/customer/project/1.x/dev/MODULES/mod_a
Properties on '$REPOURL/customer/project/1.x/dev/MODULES/mod_a':
  svn:mergeinfo

The same empty property is of course copied to
dev/production/MODULE/mod_a and causes a conflict when merging from dev
to production.

The file dir_conflicts.prej contains:
> Trying to change property 'svn:mergeinfo' from '' to
> '/ourstuff/ourproduct/version/MODULES/mod_a:27322-27324', but it has
> been locally deleted.

The property has not been deleted - it was there, but empty:
> svn proplist -v ^/customer/project/1.x/dev/production/MODULES/mod_a
Properties on '$REPOURL/code/customer/project/1.x/dev/production/MODULES/mod_a':
  svn:mergeinfo

The directory properties after merging are:
> svn proplist -v .
Properties on '.':
  svn:mergeinfo
/customer/project/1.x/dev/MODULES/mod_a:27324-27341

-> correct.

So my questions are:

1. Where does the empty svn:mergeinfo come from? (Might it be connected
to one spurious svn:mergeinfo somewhere down in mod_a in the source
branch?)
2. How may I prevent further conflicts?

Thanks,

Tino.

-- 
"What we nourish flourishes." - "Was wir nähren erblüht."

www.tisc.de

Re: Subversion access control

[Geoff Hoffman]

Andy,

I thought you were off Apache and onto svnserve. Anyway, I sent you this
info last week - maybe you missed it.  It is pasted again below. I will
grant to you that it is tricky to set up. The david winter blog post below
spells it out perfectly... for a single repo setup, multiple users. For
multi-user, multi-repo setup see my pasted config files below. One thing to
note that is confusing is that if your repos are at /subversion/repos/repo1
your  stays the same. The /svn bit there is what appears in
the URL address bar, its not a filesystem path.

I have 10 repositories, project1 through project10, physically located on
Ubuntu filesystem at
/svn/project1
/svn/project2
...
/svn/project10


Here is my /etc/apache2/mods-available/dav_svn.conf (the comments come with
the file. This was installed using apt-get on Ubuntu 10.04 LTS.)


  # Uncomment this to enable the repository
  DAV svn

  # Set this to the path to your repository
  #SVNPath /svn
  # Alternatively, use SVNParentPath if you have multiple repositories under
  # under a single directory (/var/lib/svn/repo1, /var/lib/svn/repo2, ...).
  # You need either SVNPath and SVNParentPath, but not both.
  SVNParentPath /svn
  SVNListParentPath on

  # From
http://www.redmine.org/projects/redmine/wiki/Repositories_access_control_with_apache_mod_dav_svn_and_mod_perl

  #Order deny,allow
  Deny from all
  Satisfy any

  # Access control is done at 3 levels: (1) Apache authentication, via
  # any of several methods.  A "Basic Auth" section is commented out
  # below.  (2) Apache  and , also commented out
  # below.  (3) mod_authz_svn is a svn-specific authorization module
  # which offers fine-grained read/write access control for paths
  # within a repository.  (The first two layers are coarse-grained; you
  # can only enable/disable access to an entire repository.)  Note that
  # mod_authz_svn is noticeably slower than the other two layers, so if
  # you don't need the fine-grained control, don't configure it.

  # Basic Authentication is repository-wide.  It is not secure unless
  # you are using https.  See the 'htpasswd' command to create and
  # manage the password file - and the documentation for the
  # 'auth_basic' and 'authn_file' modules, which you will need for this
  # (enable them with 'a2enmod').

  AuthType Basic
  AuthName "Subversion Repository"
  AuthUserFile /etc/apache2/dav_svn.passwd

  # To enable authorization via mod_authz_svn
  AuthzSVNAccessFile /etc/apache2/dav_svn.authz

  # The following three lines allow anonymous read, but make
  # committers authenticate themselves.  It requires the 'authz_user'
  # module (enable it with 'a2enmod').
  #
 Require valid-user
  #



Now, here is my /etc/apache2/dav_svn.authz file.


[groups]
group1 = usera, userb, userc, userd, usere
group2 = userc, userb
group3 = userf, userg
group4 = usera, userb, userc, userd, usere, userf
group5 = userh


[/]
@group1 = rw
@group2 =
@group3 =
@group4 =
@group5 =

[project1:/]
@group1 = rw

[project2:/]
@group1 = rw
userg = rw
userf = rw

[project4:/]
@group1 = rw

[project5:/]
@group11 = rw

[project6:/]
@group1 = rw
@group5 = rw

[project7:/]
@group1 = rw

[project8:/]
@group1 = rw

[project9:/]
@group1 = rw

[project10:/]
@group1 = rw
@group4 = rw


There is no need to send you the dav_svn.passwd - it merely lists usera
through userh with their hashed password. You use the htpasswd program to
set your users up.

Here is the email I sent before...

I read (skimmed) all your posts, and I'm a little confused but I think I
know where you're going. I'm not sure if you're using Apache to serve your
repositories. If you are, you should check out this:
http://davidwinter.me/articles/2006/03/03/access-control-for-subversion-with-apache2-and-authz/

and this  https://help.ubuntu.com/community/Subversion

I recently followed the blog above and got everything setup how I think you
want it. You can control user access to multiple repos in three ways, the
blog explains it all, except one thing. I found that this is for
folder-level control on one repository:

[/]
@team = r
bob = rw

[/wowapp/trunk]
@team = r
@devteam = rw
brenda = rw


In my authz control file, multiple repositories are done like this (note the
repo name and colon):

[repoA:/]
@team = r
bob = rw

[repoB:/]
@team = r
@devteam = rw
brenda = rw


I also put websvn on it, and use the configuration option

$config->useAuthenticationFile('/path/to/your/authz/file');
which I found on this stackoverflow
QA
.
http://serverfault.com/questions/13853/how-do-i-restrict-repository-access-via-websvn

Re: Subversion: existing users

[Thomas Harold]

On 7/17/2011 2:07 AM, Andy Canfield wrote:

The most obvious authorization scheme is that of the host server; if
there is a user named "andy" on that server with a password "jackel"
then I would like to simply be able to talk to the subversion server as
user named "andy" password "jackel". This is how ssh and sftp work. But
apparently subversion can't handle that. True?


You can use individual accounts, the main trickiness is in making sure 
that the svn repository directory is group owned, group writable and 
that new files created within the repo/db tree are owned by the group 
and not the individual's primary group.  A quick "chmod -R g+s repo/db" 
after setting up the repository takes care of that.


Our server only allowed SSH public-key authentication, so the only way 
to login (other then physically at the console) is via the SSH keys.  So 
the "command=" line in the authorized_keys files is reasonably secure 
for our purposes.  Very few users actually have a way to get to the 
shell.  And most of those don't even know the password for their account 
on the server.


(Naturally, we run backups daily, just in case someone does figure out 
how to get a shell through the svnserve process and deletes a 
repository.  But if they can commit to the repository, there are more 
nefarious things they can do there too.)


We prefix our ssh-rsa lines in the ~/.ssh/authorized_keys file with:

command="/usr/bin/svnserve -t -r /var/svn",
no-agent-forwarding,no-pty,
no-port-forwarding,no-X11-forwarding

This also has the advantage that remote URL ends being:

svn+ssh://servername/repositoryname/path/within/repo

Instead of:

svn+ssh://servername/var/svn/repositoryname/path/within/repo

With SSH ~/.ssh/config files or by setting up PuTTY sessions correctly 
you can get rid of having the usernames / port numbers in the svn+ssh 
URL.  (We run our SSH servers on a non-standard port.)

Re: Subversion: existing users

[David Weintraub]

On Sun, Jul 17, 2011 at 2:07 AM, Andy Canfield  wrote:
> The most obvious authorization scheme is that of the host server; if there
> is a user named "andy" on that server with a password "jackel" then I would
> like to simply be able to talk to the subversion server as user named "andy"
> password "jackel". This is how ssh and sftp work. But apparently subversion
> can't handle that. True?

Subversion has no built in security system. It merely plugs into
whatever security system you're using.

A common mechanism is to use LDAP with Apache httpd. LDAP can be used
to interface your Windows Active Directory accounts or Unix accounts.
Thus, your access to Subversion is based upon your system login.

On versions of Subversion 1.5 and greater, the native Subversion
server, svnserve can use SASL which can integrate with OpenLDAP. Thus,
even svnserve can be configured to work with either WIndows or Unix
accounts.

Another solution is to use svn+ssh which uses SSH's security mechanism
to control access to Subversion. Since SSH depends upon the system
user accounts, once again your Subversion account is the same as your
system account. Unix/Linux systems come with an SSH server, but you
can use Bitvise's WinSSHD program to create a SSH server on a Windows
box.

So to answer your question: No, Subversion doesn't use your system
accounts simply because Subversion doesn't handle its own security.

However: Yes, you can use Subversion to use your system accounts
because you can create a plugin mechanism that interface with
Subversion's server process.

Worse comes to worse, the svnserve password file is a simple text file
that can be generated automatically based upon some quirky, in house,
roll your own security scheme that some paid-by-the-hour consultant
has invented. I had to do this back when Subversion was at revision
1.3.x. I simply had a crontab that rebuilt the passwd file every few
minutes based upon the password and accounts that other mechanism
used.

-- 
David Weintraub
qazw...@gmail.com

external merge tool argument order does not match sample in svn-book

[Steven Trabert]

http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.advanced.externaldifftools.merge, 
Example 7.6 "mergewrap.py" shows the argument order as

# Get the paths provided by Subversion.
BASE   = sys.argv[1]
MINE   = sys.argv[2]
THEIRS = sys.argv[3]
MERGED = sys.argv[4]
WCPATH = sys.argv[5]

Example 7.7. mergewrap.bat shows the same order as Example 7.6.

However, the routine svn_cl__merge_file_externally in svn/util.c, 
1.6.17,  uses a different order ( the mine and their arguments are 
switched ):



arguments[0] = merge_tool;
arguments[1] = base_path;
arguments[2] = their_path;
arguments[3] = my_path;
arguments[4] = merged_path;
arguments[5] = wc_path;
arguments[6] = NULL;


the current version, r1140729, shows the same order in util.c as 1.6.17.

** 

Re: Subversion: existing users

[Andy Canfield]

Thank you very much.

On 07/20/2011 05:44 PM, Stefan Sperling wrote:

On Wed, Jul 20, 2011 at 05:22:57PM +0700, Andy Canfield wrote:

One quirk is that if he URL specifies direct access, e.t. svn ...
file:///var/svn/RepoName, then where is the code which actually
manipulates the contents of the /var/svn/RepoName directory? It must
be hidden in svn itself, or perhaps svn forks a call to something
like svnserve as a subtask to get the manipulations done for it,
since there is no server program already running on the server
computer.

See this picture for a graphical representation of the various
layers Subversion is composed of:
http://svnbook.red-bean.com/nightly/en/svn.intro.whatis.html#svn.intro.architecture


I study the diagram. Starting at the top:

   * "commandline client app" - since you don't put a name on it,
 apparently this is a program that I write. Same with "GUI client
 apps" - since there is no name it must be a program that I write.
   * Each of these access a "Client Library". This Client LIbrary
 access the Working Copy Management Library. Somebody, presumably
 the WCML, access my working copy of the repository.
   * Then the Client Library access the "Repository Access". This I
 have to assume is a PROTOCOL, not a PROGRAM. There are three; DAV,
 SVN, and Local.
   * At this point things DAV and SVN go through the Internet or any
 other TCP/IP network.
   * DAV goes through Apache and from here to mod_dav and through that
 to mod_dav_syn. The "mod_dav_fs" is not mentioned at all.
   * At this point we see the first blast. My copyof mod_dav_syn.so is
 timestamped about a year BEFORE the build date on Apache, which is
 within one day of the timestamp on mod_dav.sl. Whereas it is not
 unusual for a timestamp to be made later (e.g. via cp without -p),
 it is almost impossible for mod_dav_syn to have been build for
 this Apache and then the timestamp moved earlier. This must be why
 DAV access is crashing.
   * Alternatively, the SVN protocol will go to the svnserve program.
   * Below the mod_dav_syn layer and the svnserve layer and the
 repository local layer is the "Subversion Repository".
 Significantly, this is diagrammed as data, not code. So
 mod_dav_syn must contain the code to manipulate the repository,
 and svnserve must also contain the code to manipulate the
 repository, and the Client Library (because of Local access) must
 contain the code to manipulate the repository.
   * Below the "Subversion Repository" component is either "Berkeley
 DB" or "FSFS". I have already decided to use "FSFS" since I can
 look at it as it's sitting on the disk and therefore it is more
 conceptually transparent.
   * Significantly, the "svn" PROGRAM never appears on this diagram.
 Because the svn program is supposed to accept any of the three
 types of URL (http:// svn:// or file://) the svn program must be a
 "commandline client app".

I don't know how we got a year old version of mod_dav_syn but that is 
apparently what is screwing up the http:// protocol.




Each layer has a public API that can be used by other layers.

Clients like 'svn' and TortoiseSVN primarily use the client library's API.
The client library in turn calls into what is referred to as the "repository
access" (RA) library, which selects a repository access implementation
depending on the protocol used (http://, svn://, file://).

But there are exceptions where clients bypass the RA layer.
E.g. if you run TortoiseSVN and select the 'Create repository here'
command (the equivalent to 'svnadmin create'), TortoiseSVN calls
directly into the libsvn_repos API (the API for the big box labelled
"Subversion Repository" in the figure) to create a repository
on local disk.

Getting back to your original question, the so-called "ra_local"
repository access module (labelled "Local" in the figure) which
implements file:// access to the repository calls directly into
the libsvn_repos API to manupilate a repository on local disk.
The 'svn' client is linked to the repository access library,
and hence, indirectly, to the ra_local library and to libsvn_repos,
to support file:// URLs. So you could say that 'svn' contains a copy
of the same code that svnserve uses to access the repository. The
copy is not embedded into the 'svn' binary itself, but is loaded
from a library file (libsvn_repos.dll on Windows) when 'svn' (or
svnserve) is started.


I read the wrong version of "The Book", the featured but obsolete
version. I shall download the "Nightly Build" version ASAP.


Unfortunately google keeps showing links to the 1.1 version of the book.
This problem has existed for ages.
I was not confused by Google. I was confused by the web page 
http://svnbook.red-bean.com/. On that page there are two versions of the 
book. The first is labelled "For Subversion 1.5", the other is labelled 
"Nightly Build (for Subversion 1.7)". I read the first one, under t

Re: Subversion: existing users

[Andy Levy]

On Wed, Jul 20, 2011 at 22:42, Andy Canfield  wrote:
> Thank you very much.
>
> On 07/20/2011 05:44 PM, Stefan Sperling wrote:
>
> On Wed, Jul 20, 2011 at 05:22:57PM +0700, Andy Canfield wrote:
>
> One quirk is that if he URL specifies direct access, e.t. svn ...
> file:///var/svn/RepoName, then where is the code which actually
> manipulates the contents of the /var/svn/RepoName directory? It must
> be hidden in svn itself, or perhaps svn forks a call to something
> like svnserve as a subtask to get the manipulations done for it,
> since there is no server program already running on the server
> computer.
>
> See this picture for a graphical representation of the various
> layers Subversion is composed of:
> http://svnbook.red-bean.com/nightly/en/svn.intro.whatis.html#svn.intro.architecture
>
> I study the diagram. Starting at the top:
>
> "commandline client app" - since you don't put a name on it, apparently this
> is a program that I write. Same with "GUI client apps" - since there is no
> name it must be a program that I write.

No. It's just a placeholder for any of the various clients that are
available. Instead of listing all of the apps and having to maintain
that list as they appear and disappear. I have 4 clients installed on
my workstation - there wouldn't be any value in listing them all in
that diagram, because any one of them could up and disappear tomorrow.

> Each of these access a "Client Library". This Client LIbrary access the
> Working Copy Management Library. Somebody, presumably the WCML, access my
> working copy of the repository.

As a user, you never see the client library. It's built into (or
linked by) your client.

> Then the Client Library access the "Repository Access". This I have to
> assume is a PROTOCOL, not a PROGRAM. There are three; DAV, SVN, and Local.

The access layer is part of the program code. Again, as a user, you
only care which ones you have available (to make sure you can access a
repository using the method(s) provided by the administrator), not
*how* they're implemented.

> At this point things DAV and SVN go through the Internet or any other TCP/IP
> network.
> DAV goes through Apache and from here to mod_dav and through that to
> mod_dav_syn. The "mod_dav_fs" is not mentioned at all.

mod_dav is a standard Apache module which implements the WebDAV
protocol. mod_dav_svn is an Apache module developed by/for the
Subversion team which specifically implements Subversion using WebDAV
(which is why it's in a box *inside* mod_dav's box).

There is no mod_fs because ra_local doesn't utilize Apache as a server.

> At this point we see the first blast. My copyof mod_dav_syn.so is
> timestamped about a year BEFORE the build date on Apache, which is within
> one day of the timestamp on mod_dav.sl. Whereas it is not unusual for a
> timestamp to be made later (e.g. via cp without -p), it is almost impossible
> for mod_dav_syn to have been build for this Apache and then the timestamp
> moved earlier. This must be why DAV access is crashing.

It's not 100% definite, but it's an extremely likely root cause.

> Alternatively, the SVN protocol will go to the svnserve program.
> Below the mod_dav_syn layer and the svnserve layer and the repository local
> layer is the "Subversion Repository". Significantly, this is diagrammed as
> data, not code. So mod_dav_syn must contain the code to manipulate the
> repository, and svnserve must also contain the code to manipulate the
> repository, and the Client Library (because of Local access) must contain
> the code to manipulate the repository.
> Below the "Subversion Repository" component is either "Berkeley DB" or
> "FSFS". I have already decided to use "FSFS" since I can look at it as it's
> sitting on the disk and therefore it is more conceptually transparent.

FSFS doesn't expose the files directly. It's still a database of
sorts, just not a BDB database. You still need a Subversion client to
access the files.

> Significantly, the "svn" PROGRAM never appears on this diagram. Because the
> svn program is supposed to accept any of the three types of URL (http://
> svn:// or file://) the svn program must be a "commandline client app".

The "svn" program is one of many clients. As noted above, the clients
are not described by name because an architecture diagram is not the
appropriate place to list all clients.


> I was not confused by Google. I was confused by the web page
> http://svnbook.red-bean.com/. On that page there are two versions of the
> book. The first is labelled "For Subversion 1.5", the other is labelled
> "Nightly Build (for Subversion 1.7)". I read the first one, under the
> traditional assumption that anything named "Nightly Build" is alpha and not
> to be relied upon in a production environment. I was wrong; I will read the
> second.

The concepts described in the book change much less frequently than
the code. A significant portion of the "nightly" book applies to older
versions - but of course there are changes

Re: Subversion access control

[Andy Canfield]

Thank you very much.

On 07/20/2011 12:19 PM, Nico Kadel-Garcia wrote:

On Tue, Jul 19, 2011 at 11:14 PM, Andy Canfield
  wrote:

One thing has hit my mind today that I don't think you realize ...

 I have never, in my entire life, seen a working Subversion system.

Apparently Subversion, as distributed, doesn't work - the access
authentications are deliberately turned off.

I'm afraid it depends on your access requirements. Seriously. Which
access technology are you using? svn+ssh (which I tend to recommend),
or Apache (using https://), or svn directorly (svn://) Start with that
and we'll walk you through it.


OK, here goes.

I would like to use http/https. I am not supposed to be working on the 
server, but on my notebook workstation. And svn or svn+ssh require port 
3690 to be forwarded by the router, and we don't own the router. So I 
would prefer http and/or https.


But on the actual server https is screwed up because mod_dev_svn.so is a 
year earlier than Apache, and apparently there is a version mismatch. 
When svn is enabled apache is dead. I have put in a request for my 
friend to re-install, but that could take a week.


So for the interim I have installed mod_dav etc. on my notebook 
computer. FYI it is running Ubuntu Linux 1.04. This is for testing.


Directory /etc/apache2/modes-enabled contains the file dav.load with 
this contents:

*LoadModule dav_module /usr/lib/apache2/modules/mod_dav.so*
That same directoy also contains the file dav_syn.load with these contents:
*# Depends: dav
LoadModule dav_svn_module /usr/lib/apache2/modules/mod_dav_svn.so
LoadModule authz_svn_module /usr/lib/apache2/modules/mod_authz_svn.so*
That same directory also contains the file dav_svn.conf which I altered; 
this is the altered contents:

*# dav_svn.conf - Example Subversion/Apache configuration
#
# For details and further options see the Apache user manual and
# the Subversion book.
#
# NOTE: for a setup with multiple vhosts, you will want to do this
# configuration in /etc/apache2/sites-available/*, not here.

#  ... 
# URL controls how the repository appears to the outside world.
# In this example clients access the repository as http://hostname/svn/
# Note, a literal /svn should NOT exist in your document root.


  # Uncomment this to enable the repository
  DAV svn

  # Set this to the path to your repository
  #SVNPath /var/lib/svn
  # Alternatively, use SVNParentPath if you have multiple repositories 
under

  # under a single directory (/var/lib/svn/repo1, /var/lib/svn/repo2, ...).
  # You need either SVNPath and SVNParentPath, but not both.
  #SVNParentPath /var/lib/svn
  SVNParentPath /data/svn

  # Access control is done at 3 levels: (1) Apache authentication, via
  # any of several methods.  A "Basic Auth" section is commented out
  # below.  (2) Apache  and , also commented out
  # below.  (3) mod_authz_svn is a svn-specific authorization module
  # which offers fine-grained read/write access control for paths
  # within a repository.  (The first two layers are coarse-grained; you
  # can only enable/disable access to an entire repository.)  Note that
  # mod_authz_svn is noticeably slower than the other two layers, so if
  # you don't need the fine-grained control, don't configure it.

  # Basic Authentication is repository-wide.  It is not secure unless
  # you are using https.  See the 'htpasswd' command to create and
  # manage the password file - and the documentation for the
  # 'auth_basic' and 'authn_file' modules, which you will need for this
  # (enable them with 'a2enmod').
  #AuthType Basic
  #AuthName "Subversion Repository"
  #AuthUserFile /etc/apache2/dav_svn.passwd
  AuthType Basic
  AuthName "Lenny Subversion Repository"
  AuthUserFile /etc/apache2/dav_svn.passwd

  # To enable authorization via mod_authz_svn
  #AuthzSVNAccessFile /etc/apache2/dav_svn.authz

  # The following three lines allow anonymous read, but make
  # committers authenticate themselves.  It requires the 'authz_user'
  # module (enable it with 'a2enmod').
  #
#Require valid-user
  #
*
*  Require valid-user*
*

*
By the way, all three of the above files in /etc/apache2/mods-enabled 
are actually symbolic links to the same file name in ../mods-available.


I used sudo htpasswd to create the /etc/apache2/dav_svn.passwd file:
*andy:4izmp7W8TSqww*

Also I created my subversion directory like this:\
*sudo bash
mkdir /data/svn
chmod a+w /data/svn*
*ls /data/svn
**drwxrwxrwx 2 root root 4096 2011-07-21 10:53 /data/svn*

Now I point my browser to http://localhost/svn and I get a prompt for a 
user name and password. If I type in my valid user name "andy" and a 
completely spurious password, I get prompted again. But if I type in my 
valid user name and password (as given when I created the dav_svn.passwd 
file), the result is:

*Forbidden
You don't have permission to access /svn on this server.
Apache/2.2.17 (Ubuntu) Server at localhost Port 80*

Of course the /d

Re: Subversion access control

[Dave Huang]

On 7/20/2011 11:14 PM, Andy Canfield wrote:

Isn't http://localhost/svn supposed to show me something useful?


I don't use SVNParentPath and haven't tried this, but perhaps add 
"SVNListParentPath on" right after "*SVNParentPath /data/svn"? See the 
"Listing repositories" section of 
http://svnbook.red-bean.com/nightly/en/svn.serverconfig.httpd.html

*

Re: Subversion: existing users

[Andy Canfield]

Great...

On 07/21/2011 10:01 AM, Andy Levy wrote:

On Wed, Jul 20, 2011 at 22:42, Andy Canfield  wrote:

Thank you very much.

On 07/20/2011 05:44 PM, Stefan Sperling wrote:

On Wed, Jul 20, 2011 at 05:22:57PM +0700, Andy Canfield wrote:

One quirk is that if he URL specifies direct access, e.t. svn ...
file:///var/svn/RepoName, then where is the code which actually
manipulates the contents of the /var/svn/RepoName directory? It must
be hidden in svn itself, or perhaps svn forks a call to something
like svnserve as a subtask to get the manipulations done for it,
since there is no server program already running on the server
computer.

See this picture for a graphical representation of the various
layers Subversion is composed of:
http://svnbook.red-bean.com/nightly/en/svn.intro.whatis.html#svn.intro.architecture

I study the diagram. Starting at the top:

"commandline client app" - since you don't put a name on it, apparently this
is a program that I write. Same with "GUI client apps" - since there is no
name it must be a program that I write.

No. It's just a placeholder for any of the various clients that are
available. Instead of listing all of the apps and having to maintain
that list as they appear and disappear. I have 4 clients installed on
my workstation - there wouldn't be any value in listing them all in
that diagram, because any one of them could up and disappear tomorrow.


Each of these access a "Client Library". This Client LIbrary access the
Working Copy Management Library. Somebody, presumably the WCML, access my
working copy of the repository.

As a user, you never see the client library. It's built into (or
linked by) your client.
But as a system administrator, for installing packages from Ubuntu, I 
often see library names etc. Also as a programmer I often run into 
libraries that no longer exist, library version problems, etc. But I 
know what you mean. As a user of subversion I should not see them 
assuming that my system administrator has taken care of things.



Then the Client Library access the "Repository Access". This I have to
assume is a PROTOCOL, not a PROGRAM. There are three; DAV, SVN, and Local.

The access layer is part of the program code. Again, as a user, you
only care which ones you have available (to make sure you can access a
repository using the method(s) provided by the administrator), not
*how* they're implemented.


At this point things DAV and SVN go through the Internet or any other TCP/IP
network.
DAV goes through Apache and from here to mod_dav and through that to
mod_dav_syn. The "mod_dav_fs" is not mentioned at all.

mod_dav is a standard Apache module which implements the WebDAV
protocol. mod_dav_svn is an Apache module developed by/for the
Subversion team which specifically implements Subversion using WebDAV
(which is why it's in a box *inside* mod_dav's box).

There is no mod_fs because ra_local doesn't utilize Apache as a server.
But there is a file named "mod_dav_fs.so" on both the intended server 
and on my notebook trial server. If WebDAV is not specific to Subversion 
then maybe some other package / feature uses mod_dav_fs.so. Ahah! Google 
to the rescue. From http://httpd.apache.org/docs/2.0/mod/mod_dav_fs.html 
I learn that mod_dav_fs.so "acts as a support module for mod_dav and 
provides access to resources located in the server's file system."



At this point we see the first blast. My copyof mod_dav_syn.so is
timestamped about a year BEFORE the build date on Apache, which is within
one day of the timestamp on mod_dav.sl. Whereas it is not unusual for a
timestamp to be made later (e.g. via cp without -p), it is almost impossible
for mod_dav_syn to have been build for this Apache and then the timestamp
moved earlier. This must be why DAV access is crashing.

It's not 100% definite, but it's an extremely likely root cause.


Alternatively, the SVN protocol will go to the svnserve program.
Below the mod_dav_syn layer and the svnserve layer and the repository local
layer is the "Subversion Repository". Significantly, this is diagrammed as
data, not code. So mod_dav_syn must contain the code to manipulate the
repository, and svnserve must also contain the code to manipulate the
repository, and the Client Library (because of Local access) must contain
the code to manipulate the repository.
Below the "Subversion Repository" component is either "Berkeley DB" or
"FSFS". I have already decided to use "FSFS" since I can look at it as it's
sitting on the disk and therefore it is more conceptually transparent.

FSFS doesn't expose the files directly. It's still a database of
sorts, just not a BDB database. You still need a Subversion client to
access the files.


But I don't need a Subversion client to see the files, to read the 
files, and therefore to learn how things are stored. I'm the kind of guy 
who has looked at the directory & file structure created by MySQL for 
it's databases. It becomes possible to see the low-level implementation 
in case tha