svn create --fs-type fsfs <repos-path>NOTE: Why FSFS is used ?
$ svnadmin dump <repos-path> > <dumpfile>
$ svnadmin load <repos-path> < <dumpfile>
LoadModule dav_module modules/mod_dav.so
LoadModule dav_svn_module modules/mod_dav_svn.so
<Location /repos>
DAV svn
SVNPath /absolute/path/to/repository
</Location>
chown -R apache <repos-path>
AuthType Basic
AuthName "Subversion repository"
AuthUserFile /path/to/htpasswd/file
# only authenticated users may access the repository
Require valid-user
[groups]
Full-SVN-RO = svnreader
Proj1-RW = user1 user2 user3
Proj1-RO = user4
Proj2-RW = user1 user6 user7
Proj2-RO = user8 user2
EveryOne = @Full-SVN-RO, @Proj1-RW, @Proj1-RO, @Proj2-RW, @Proj2-Ro
# Access control to whole SVN
[/]
svnadmin = rw # No Groups allowed to Read-Write the whole SVN Repos
@Full-SVN-RO = are
# Access to Proj1
[/Proj1]
@Proj1-RW = rw
@Proj1-RO = r
# Access to Proj2
[/Proj2]
@Proj2-RW = rw
@Proj2-RO = r
LoadModule authz_svn_module modules/mod_authz_svn.so
AuthzSVNAccessFile /path/to/access/file
#Redirect all port 80 requests to 443
RewriteEngine On
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{SERVER_NAME}/$1 [L,R]
SSLRequireSSL
CustomLog logs/svn_logfile "%t %u %{SVN-ACTION}e" env=SVN-ACTION
<Location /svn/>
DAV svn
SVNParentPath /data/subv/repos/
</Location>
<Location /svn/testA/>
# Authenticate a user
AuthType Basic
AuthName "TestA Subversion Repository"
AuthUserFile /data/subv-testA/perms/users
Require valid-user
# Authenticate permissions
AuthzSVNAccessFile /data/subv-testA/perms/perms
# Requires SSL
SSLRequireSSL
</Location>
<Location /svn/testB/>
# Authenticate a user
AuthType Basic
AuthName "TestB Subversion Repository"
AuthUserFile /data/subv-testB/perms/users
Require valid-user
# No permissions
# AuthzSVNAccessFile /data/subv-testB/perms/perms
# No SSL
# SSLRequireSSL
</Location>
Race ConditionThis can be solved by using atomic operations or some locking semantics. Getting to understand which shared data is to locked or made atomic, does an interrupt disturb the locking semantics is tough. If the locking semantics are wrongly designed -- deadend, called deadlock.
A race hazard (or race condition) is a flaw in a system or process where the output exhibits unexpected critical dependence on the relative timing of events. The term originates with the idea of two signals racing each other to influence the output first.
en.wikipedia.org/wiki/Race_condition
DeadlockThe linux Kernel provides some functions to reduce data races
In operating systems, a situation in which two or more processes are blocked while waiting for resources that the other controls so that none of the affected processes can continue to execute. Also known as the "deadly embrace."
www.ssuet.edu.pk/taimoor/books/0-7897-1063-3/appa.htm
Critical regions
A critical section is a piece of code that can only be executed by one process at a time. It will usually terminate in fixed time and a process will only have to wait a fixed time to enter it. Some synchronisation mechanism is required at the entry and exit of the critical section to ensure exclusive use, for example a semaphore.
en.wikipedia.org/wiki/Critical_section
Atomic OperationConsider the previous example of i++. If we could read i, increment it and write it back to memory in one uninterruptible operation, the race condition discussed above would not be an issue. Atomic operators provide these uninterruptible operations.An operation that cannot be interrupted docs.cray.com/books/004-2518-002/html-004-2518-002/zglossaryqkdxjklv.html Operation that executes without interference by other concurrently-executing processes or threads. www.cise.ufl.edu/research/ParallelPatterns/PatternLanguage/Background/Glossary.htm
atomic_t v;
atomic_set(&v, 5); /* v = 5 (atomically) */
atomic_add(3, &v); /* v = v + 3 (atomically) */
atomic_dec(&v); /* v = v - 1 (atomically) */
printf("This will print 7: %d\n", atomic_read(&v));
Some points to remember.
With a UP kernel, the above code compiles to the same as:
unsigned long flags;spin_lock() and spin_unlock() methods that acquire and release the specified lock without any interaction with interrupts.
spin_lock_bh() that implements the standard spinlock as well as disables softirqs. This is needed when you have code outside a softirq that is also used inside a softirq. The corresponding unlock function is naturally spin_unlock_bh().
You must be careful not to re-acquire a spinlock you already hold, or you will deadlock.
Spinlocks should be used to lock data in situations where the lock is not held for a long time--recall that a waiting process will spin, doing nothing, waiting for the lock. (See the ``Rules'' Sidebar for guidelines on what is considered a long time.) Thankfully, spinlocks can be used anywhere. You cannot, however, do anything that will sleep while holding a spinlock. For example, never call any function that touches user memory, kmalloc() with the GFP_KERNEL flag, any semaphore functions or any of the schedule functions while holding a spinlock. You have been warned.
Semaphoresdown() function, which differs in that it puts the calling task into an uninterruptible sleep. A signal received by a process blocked in uninterruptible sleep is ignored
down_trylock() function, which attempts to acquire the given semaphore. If the call fails, down_trylock() will return nonzero instead of blocking.
Reader/Writer Locks
Since it is typically safe for multiple threads to read data concurrently, so long as nothing modifies the data, reader/writer locks allow multiple concurrent readers but only a single writer (with no concurrent readers). If your data access naturally divides into clear reading and writing patterns, especially with a greater amount of reading than writing, the reader/writer locks are often preferred. The reader/writer spinlock is called an rwlock and is used similarly to the standard spinlock, with the exception of separate reader/writer locking:
Likewise, the reader/writer semaphore is called an rw_semaphore and use is identical to the standard semaphore, plus the explicit reader/writer locking:
struct rw_semaphore mr_rwsem;
