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.
Received on 2008-07-11 07:44:32 CEST