subversion via cifs is not working

Question

I am trying to use subversion on a linux machine, the repository is on a Microsoft sbs2008 server. (I can access the repository from a Microsoft Windows 7 machine.) Can some one tell me how to get it to work?

This is what I have done.

# sudo mount -t cifs -v -o credentials=~/Files/server-mount-credentials,uid=richard,nocase,nounix,nosuid  //sbs2008/local ~/Files/server-mount/

# svn commit -m ""

Adding         file1
Sending        file2
Transmitting file data ........svn: Commit failed (details follow):
svn: database is locked

The strace shows:

open("/home/rdelorenzi/Files/server-mount/svn_repository/db/rep-cache.db", O_RDWR|O_CREAT|O_LARGEFILE, 0644) = 12

...

_llseek(12, 162816, [162816], SEEK_SET) = 0
read(12, "\n\0\0\0\20\1 \0\1 \1N\1|\1\252\1\330\2\6\0024\2b\2\220\2\276\2\354\3\32"..., 1024) = 1024

_llseek(12, 100352, [100352], SEEK_SET) = 0
read(12, "\n\0\0\0\24\0i\0\0i\0\227\0\305\0\363\1!\1O\1}\1\253\1\331\2\7\0025\2c"..., 1024) = 1024
_llseek(12, 52224, [52224], SEEK_SET)   = 0
read(12, "\n\0\0\0\24\0k\0\0\231\0\307\0\365\1#\1Q\1\177\1\255\1\333\2\t\0027\2d\2\222"..., 1024) = 1024

fcntl64(12, F_SETLK64, {type=F_WRLCK, whence=SEEK_SET, start=1073741824, len=1}, 0xbf8e15e8) = 0
fcntl64(12, F_SETLK64, {type=F_WRLCK, whence=SEEK_SET, start=1073741826, len=510}, 0xbf8e15e8) = -1 EACCES (Permission denied)

Answer 1

Don't mount a subversion repository via a network share, it just won't work reliably.

file:// access is intended for local, single-user access only, particularly testing and debugging. When you want to share the repository you really need to set up a proper server, and it is not nearly as difficult as you might think. Read the section called “Accessing the Repository” for guidelines on choosing and setting up a server. [link]

You need to run an SVN server, as David W notes.

Answer 2

Do you have control over the Windows machine? Is port 3690 unblocked? Why not use svnserve server on the Windows machine. Then, you don't have to mount file systems.

On your Windows Machine:

 c:\> svnserve -r C:\path\to\your\repository -d

On your Linux Box

$ svn co svn://sbs2008/trunk

Another possibility is using VisualSVN Server on your Windows box. Then, you could use Apache's httpd to access your repository:

$ svn co http://sbs2008/svn/trunk

VisualSVN Server isn't open source, but it's free as long as you don't need advanced stuff like Windows Active Directory connections.

Answer 3

Well. Let's imagine I dont know and can't understand mount command and parameters.

In this case I just ask:

What exactly you want to do? Work directly with files of repository (not files in repo , but files of )?! For which reasons?!

Subversion have Client-Server architecture , client communicates with server, which hide from client details of handling physical repository backend

Subversion's networking layer is abstracted, meaning that Subversion clients exhibit the same general behaviors no matter what sort of server they are operating against. Whether speaking the HTTP protocol (http://) with the Apache HTTP Server or speaking the custom Subversion protocol (svn://) with svnserve, the basic network model is the same.

You, as client-human, work with physical representation of Repository (state of repo) in Working Copy , logical representation of Repository , provided by a pair of client and server; svn-client as client-program communicates with repository server, handling repository, using any of exposed by server access-protocols and server later work with repository at the lowest possible layer (read-write files)

Answer 4

This is not so much an answer as a few questions for you to mull over.

Why do you assume that this will work? The cifs file system driver exposes the NTFS file system in such a way that you, in the worst case, can only read files. The functionality exposed by the cifs driver has to have a matching functionality in the NTFS end of things.

So, if the, by SVN, needed functionality is either unimplemented or unsupported you might very well end up with a problem like this.

I'd suggest looking at the cifs documentation and check for known limitations or ways to tweak the driver to, perhaps, offer more functionality.

And, of course, you need to check the ACLs of the exported NTFS file system. If this operation is supported by the cifs driver and should work, it will still fail if the NTFS file system has the wrong owner or a read only bit set.