Adding LAN support to Subversion - Clarification

[Kopp David K <da...@us.army.mil>]

Thanks to everyone for the discussion.

I had posted this in a message a few days ago. This may clear some things
up.


--- snip ----
We have VSS set up so that the repository is on a shared network drive.
Somehow VSS has a locking mechanism that keeps the different clients from
hosing the repository. Would it be possible to add something similar to
Subversion? I would guess it might work something like this:
1) User A does an initial checkout by typing 
svn checkout lan:///k:/logpars/subverion/powerLOGJ/trunk 
2) svn notices that the URL protocol is lan, (or nfs or whatever bogus
protocol you like). It determines that K:\logpars\subversion\powerLOGJ is
the directory holding the Subversion repository, so it checks to see if a
file (let's call it lan.lock) exists in that directory. If it does, it
aborts and tells the user that someone else is currently using the
repository and they should try again in a couple of minutes. If not, it
creates lan.lock itself.
3) Assuming we were able to lock the repository, we do the checkout 
4) We delete lan.lock 
5) All done 
I guess the big question is, is there a way to check for the existence of a
lock file, and then create it, without introducing a bunch of nasty race
conditions?
--- snip ---

This is basically what I was thinking about doing.

David Kopp
General Engineer
USAMC LOGSA
(256) 955 - 9902

Re: Adding LAN support to Subversion - Clarification

[Barry Scott <ba...@barrys-emacs.org>]

At 27-10-2003 18:30, Kopp David K wrote:

>Thanks to everyone for the discussion.
>
>I had posted this in a message a few days ago. This may clear some things up.
>
>--- snip ----
>We have VSS set up so that the repository is on a shared network drive. 
>Somehow VSS has a locking mechanism that keeps the different clients from 
>hosing the repository. Would it be possible to add something similar to 
>Subversion? I would guess it might work something like this:

I wish this was true. A Client can hose VSS trivially,
pull out the LAN cable while you are working on VSS.
I expect BDB will die from a similar action.

You will need repair utilities and procedures in place
to try and keep the repo going. You probable need to
do this already with VSS.

>1) User A does an initial checkout by typing
>svn checkout lan:///k:/logpars/subverion/powerLOGJ/trunk
>2) svn notices that the URL protocol is lan, (or nfs or whatever bogus 
>protocol you like). It determines that K:\logpars\subversion\powerLOGJ is 
>the directory holding the Subversion repository, so it checks to see if a 
>file (let's call it lan.lock) exists in that directory. If it does, it 
>aborts and tells the user that someone else is currently using the 
>repository and they should try again in a couple of minutes. If not, it 
>creates lan.lock itself.
>
>3) Assuming we were able to lock the repository, we do the checkout
>4) We delete lan.lock
>5) All done
>I guess the big question is, is there a way to check for the existence of 
>a lock file, and then create it, without introducing a bunch of nasty race 
>conditions?

Yes using Win32 file API calls; look at CreateFile. I expect
you will not find APR functions to help with this.

I recommend that you work on your admin folks to allow you to run an SVN 
server.
The alternative's are all ways to madness.

Barry

Re: Adding LAN support to Subversion - Clarification

[Ben Collins-Sussman <su...@collab.net>]

Kopp David K <da...@us.army.mil> writes:

> This is basically what I was thinking about doing.

Why are you trying to create so much work for yourself?  :-)

Just run a real server process on the machine which contains the
repository.  If apache is too big for you, use an svnserve daemon
instead.

The reason we have servers is so that you don't have to worry about
this kind of thing... and to allow concurrent accesses.  Trying to add
a 'lockfile' to file:/// access is a poor reinvention of a wheel, and
won't even give you concurrency.  With a real server process,
repository readers are *never* blocked, and writers are almost never
blocked.



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org