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

RE: WinXP Env - successfully using repos WITHOUT SVNServe.EXE running. OK to do?

From: Smith, Michelle <Michelle.Smith_at_bhpbilliton.com>
Date: Fri, 11 Jul 2008 09:49:55 +1000

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.
 

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 03:16:53 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.