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

RE: general questions

From: John Maher <JohnM_at_rotair.com>
Date: Mon, 10 Sep 2012 15:31:47 -0400

Thanks Dave, that was helpful.


I saw the svn prefix in the book but didn't know what it meant. Your
explanation was good.


The scripts are a good idea, but I was thinking about a gui for the
client side, kinda like Subversion Edge; basically a wrapper for the
command line. Even though my first computer didn't have a mouse (or
hard drive) the gui is the way to go, typing commands is just not the
future. I may start something to make my job easier. I think HTML
would benefit the most people. But I need to learn a lot more first.






From: David Chapman [mailto:dcchapman_at_acm.org]
Sent: Monday, September 10, 2012 3:12 PM
To: John Maher
Cc: Mark Phippard; users_at_subversion.apache.org
Subject: Re: general questions


On 9/10/2012 10:43 AM, John Maher wrote:

        Thanks again, I'm learning.


        I appreciate the time put in to help me and I really don't want
to cost you more time, so I have a couple of yes/no questions.


        So the only time to use svnadmin create without having a
dedicated server would be a single user (like me at home)?

At some level, svnadmin create will be called once per repository.
Whether that is done through a GUI-based interface or from the command
line is immaterial. This is the first step in setting up a repository,
and it has to be on the machine that will serve the repository.

It may be helpful to think of Subversion as a program package that runs
on a server. If you are a single user working on a non-networked
machine, then your local machine can be a Subversion server by reading
the repository directly, using the "file://" <file:///\\> protocol.
This protocol has major problems with multiple (and sometimes even
remote) access, so it is safely run only on the machine where the files
reside and only by one user at a time. If you need to access a
repository on another machine, particularly if multiple users will be
accessing the repository, you need some kind of server process running
on that machine to manage internal operations safely and arbitrate
between simultaneous requests. Subversion includes the "svnserve"
program to serve files using the "svn://" protocol and has code that
allows Apache HTTPD to serve files using the "http://" <http://> or
"https://" <https://> protocol.

Personally, my repositories are all served using Apache HTTPD. I have
multiple machines, and although it is unlikely that I would ever commit
code from two different machines at the same time, the ease of use for
the "file://" <file:///\\> protocol just wasn't worth the risk. I host
some Web sites too, and it was easier for me to adapt my HTTPD setup
knowledge than to learn how to configure svnserve. Your mileage may


As for as the dll extensions, those are not a concern. I am talking
about ide setting files. And if we have a project made up of 44
repositories I need to enter the command 44 times, no eaiser way, right?


Subversion does not provide repository administration or sandbox
configuration tools; it provides a repository hosting mechanism. What
you are asking for is not part of Subversion, so yes you need to enter
the command 44 times.

Scripting languages are your friends here. Write one script to invoke
the configuration commands for a single repository, then another to
invoke the first script for every repository in a list. This has
multiple benefits:

1) You can call the first script each time you add a new repository,
rather than type in the commands all over again.
2) Automation of this kind allows you to configure all of your
repositories identically.
3) The scripts document the configuration you used (rather than scraps
of paper somewhere, or the memory of an employee who may leave).

    David Chapman      dcchapman_at_acm.org
    Chapman Consulting -- San Jose, CA
    Software Development Done Right.
Received on 2012-09-10 21:33:52 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.