Thanks,
Up till now we have been using SVNSERVE.exe (and I'd be more comfortable
to continue to do so), however, our IT department wants to shift us to
this super-fast & large array of disks. Given it's such a small team of
users (5), we should be able to control the client software issues.
I'll do some testing by having multiple users committing 3GB+ files at
the same time & see what happens. From what you've said, and what I've
read, a new local service is spawned by each client, so I'm unsure how
(if) this will impact the repository.
Thanks for the help,
Michelle Smith
Senior Database Geologist
Uranium - Olympic Dam Expansion Project
________________________________
From: Kevin Grover [mailto:kevin_at_kevingrover.net]
Sent: Friday, 11 July 2008 3:14 PM
To: Smith, Michelle
Cc: users_at_subversion.tigris.org
Subject: Re: WinXP Env - successfully using repos WITHOUT SVNServe.EXE
running. OK to do?
On Thu, Jul 10, 2008 at 4:49 PM, Smith, Michelle
<Michelle.Smith_at_bhpbilliton.com> wrote:
Thank you for your polite response. I actually HAVE looked in
the SVN book (by which, I assume you mean the help file that is
installed with Subversion) and I've also tried to search the archived
mail posts. Failing to find a solution to my problem, I posted on to
this user forum. A search for the keyword "File://" doesn't actually
help since every page in the help file that has the word "File" in it
comes up. Perhaps you could point me to the appropriate section of the
SVNBook if it's so easy to find?
The only information that I have found about file:// access tell
me that it can be done - which I know since I've done it. What I can't
find is the pro's and con's of doing it this way. Where does it tell me
that "it's dangerous to use the file:// protocol on network shares", and
why is it dangerous?
Thanks,
Michelle.
Michelle Smith
Senior Database Geologist
Uranium - Olympic Dam Expansion Project
________________________________
From: Kevin Grover [mailto:kevin_at_kevingrover.net]
Sent: Friday, 11 July 2008 1:42 AM
To: Smith, Michelle
Cc: users_at_subversion.tigris.org
Subject: Re: WinXP Env - successfully using repos WITHOUT
SVNServe.EXE running. OK to do?
On Wed, Jul 9, 2008 at 10:29 PM, Smith, Michelle
<Michelle.Smith_at_bhpbilliton.com> wrote:
Hi,
I'm using Subversion for Win32, version 1.4.5
We've been using Subversion (using the SVNSERVE.EXE
running as a Windows service) for a team of 5 people to manage version
control. Due to huge file sizes, we're about to shift across to a
dedicated SAN with massive storage volume. The WinXP desktop machine
that is currently running the SVNSERVE.EXE service will be taken
off-line.
The SAN storage space (mapped to "Y:\" on my machine)
does NOT have the SVNSERVE.EXE running as a service since it's
apparently just an array of hard drives without an operating system. My
client machine doesn't have the SVNSERVE.EXE service running either
(though subversion is installed in Program Files\Subversion). Despite
this, I can (using TortoiseSVN), create a repository on the Y:\ drive
and successfully checkout, add, commit and update changes to this
repository via my repository. The only difference I can see is that the
repository path is now "file:///Y:/Test Repository" where it used to be
svn://ACOMPUTER/AFOLDER.
I can't find anything in the documentation about using
SVN in this manner - essentially, the only two documented methods I can
see is a) APACHE and b)SVNSERVE.EXE. I'm mystified as to how the
software is actually functioning if it's not running as a service on
either of the two machines that are a) hosting and b) communicating with
the repository.
Then you must not be reading any of the Subversion documentation
I'm used to seeing (like the SVN Book). It's in there.
Am I OK to use Subversion in this fashion? Is there
anything I need to be aware of?
No. It's dangerous to use the file:// protocol on network
shares.
Yes, I was talking about the svn book -- that's the help file that comes
with Subversion.
You are correct that the info is not as easy to find as I thought. I
loaded the SVN book (single HTML file:
http://svnbook.red-bean.com/en/1.4/svn-book.html) and also the FAQ
(http://subversion.tigris.org/faq.html) and searched quickly for file://
(too many) and 'network' and 'danger' and could not find it.
The biggest problems are permissions and access control. svn:// and
http:// are separate processes that control access to the repository.
With file://, if you have write permissions (i.e. on an OS file level)
to the files in the repository, you can commit. You can also CD in
there and screw things up completely.
There are also issues with server/client compatibility: when you use the
file:// protocol, each users client is acting as a server (it directly
reads and writes the repository files.) This is actually very quick.
However, if you upgrade to a newer svn client, your writing to the repo
may silently upgrade it. Then, anyone use an older client could not
access it. However, if you use svn:// or http:// then different vesions
of clients have no problem accessing the server (and there are no silent
upgrade issues).
The greatest use of file:// are you can quickly create and use a
repository if you can not (or do not want to take the time) to setup and
run svnserve or Apache. Plus there is no configuration needed. With
svn:// you must edit the svnserve.conf file (and probably the passwd
file) (in each repo) before you can commit. The configuration for http:
is more complicated upfront, but easier to setup a global configuration
that all repositories use.
I'm sure I'm missing something, but don't have time now to look more
into it.
This message and any attached files may contain information that is confidential and/or subject of legal privilege intended only for use by the intended recipient. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient, be advised that you have received this message in error and that any dissemination, copying or use of this message or attachment is strictly forbidden, as is the disclosure of the information therein. If you have received this message in error please notify the sender immediately and delete the message.
Received on 2008-07-11 17:20:28 CEST