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

Concurrent use of fsfs on network filesystem (AFS) not supporting file locking

From: George Jongren <gjongren_at_hotmail.com>
Date: 2005-11-04 18:46:42 CET


I am evaluating the use of subversion in the company I work for. We are
trying to determine how safe it is to use the fsfs type of repository on a
file system which does not support file locking. We want to store the
repository on AFS and have noticed that the fcntl function always gives back
a file lock even if another user has already acquired a lock.

1. What is the worst that can happen if two users are trying to use (commit
I guess?) the repository at once via direct file access? How would one
notice that the repository is corrupted and how would one repair it?

2. What does the file locking in the repository actually protect from? My
guess, based on some experiments when trying to commit from two clients at
once, is that the "write-lock" file is locked in order to primarily protect
the "current" file. The revision number in the "current" file is increased
and then the lock on the "write-lock" file is released to allow another user
to start its commit process as well. The revision number from the "current"
file is then used to name the transaction. Work on the transaction only
begins when the revision number of that transaction is exactly one higher
than the last revision number in the "revs" directory. When the transaction
is complete, it is moved to the revs directory (if no conflicts with the
previous revisions in the "revs" directory have occured) and work on any
outstanding transactions can begin. Have I understood this process
correctly? or is the locking feature used once again (while not enforcing
that the revision number is exactly one higher than in the "revs" directory)
when moving the transaction into the "revs" directory and checking that no
conflicts have occured? If the former is true, then to me it seems the only
problem of storing the repository on a file system that does not support
locking is if two users happen to read the "current" file at the same time
and thus get the same revision number. The transactions would then be named
the same. Would that create a corrupted revision file that is moved into the
revs directory? On the other hand if the latter is true, then I guess the
repository could contain two revision that are in conflict with each other
even though the clients did not notice it.

3. Does accessing the repository via the server option (Apache of svnserve)
completetely solve the problem?, thus avoiding the need of having proper
file locking in the networked file system.

Best regards,

George Jöngren

Don't just search. Find. Check out the new MSN Search!

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Nov 4 19:27:48 2005

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.