On 8/31/07, Stefan Küng <tortoisesvn@gmail.com> wrote:
> Strip, David R wrote:
> > I was not aware of the vulnerability under FILE://, but now that you
> > mention it, I'm guessing the problem arises when two (or more) people
> > try to commit (or otherwise modify) the repository at the same time.
> > Since FILE:// provides no directory level locking, you can get seriously
> > hosed. Is that the issue?
>
> Whether directory level locking is available or not depends fully on the
> network protocol and the filesystem on the server. If both support it,
> Subversion can use it and you will be fine even if multiple accesses
> happen at the same time. But lets face it: there simply isn't a network
> that stable to never have problems. And one cut connection is enough to
> leave a lock in the repository - you will have to execute an 'svnadmin
> recover' on the repository before any other access will be possible.
> And of course, if you run that command over the network and someone
> tries to access the repo that very moment, your repository could get
> screwed beyond repair. (svnadmin recover can't lock - it has to *remove*
> left over locks, that's why an access at that time is fatal).
Unfortunately, there are some environments where the file:/// method
is the only option. I am working in such an environment. It is very
hard to get the IT people to grant us a DB on the MS SQL server or
even a MS extension to IIS, let alone get them to set up any other
kind of server. We were able to get a server folder under which we put
all our group's shared resources, including the SVN repositories.
(Fortunately, they long ago gave up on trying to support the "arcane"
needs of embedded software development and give us admin rights to our
PCs.)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: users-help@tortoisesvn.tigris.org
Received on Fri Aug 31 23:36:45 2007