3

We have SVN working copies of three websites held on a development server in the office. The server WAS Linux, and the working copies were worked on Windows machines and updated / committed etc. using TortoiseSVN. I will preface this by saying that I know working copies on network shares aren't strictly supported, but it was done this way so that we could test our code changes to the sites offline on local dev URLs before putting them on the live server.

This WAS working absolutely brilliantly. No problems at all - until our Linux server developed problems and had to be replaced. We have replaced it with a Mac to kill the second bird of having a Mac in-house for browser testing.

Ever since moving everything to the Mac, SVN has been extremely problematic. Commits / updates often fail with "database is locked" errors, and I cannot do clean up most of time as it usually fails with this error:

Cleanup failed to process the following paths: PATH TO WC ON NETWORK database is locked, executing statement 'COMMIT TRANSACTION;'

The statement being executed differs, sometimes being something to do with RELEASE.

The code changes we are making must be tested on our dev server before being committed to the live site online. As it stands, I now have a working copy checked out on my own hard drive. I have to commit my changes, update on the development server (and pray it works - it takes AGES either way) and test them, before then updating the live server if they work.

I cannot checkout new working copies on the network share either - again, it usually fails complaining of a disk I/O error, or a database becoming locked. We have already disabled all the Mac's power saving functions in case a sleep or hard disk spindown was responsible - no luck.

I would prefer to keep the working copy on the network share if possible. As I've already said, I realise it's not the most suitable way to do SVN but it's been working for us. What can I do to try and fix this problem? I suspect it's Windows -> Mac network related and actually have another question open about slow network access from my machine to the Mac network share.

MikkyX
  • 303
  • 3
  • 15

3 Answers3

2

Since SVN 1.7, SQLite is used as the database for working copies. As read in File Locking And Concurrency In SQLite Version 3:

SQLite uses POSIX advisory locks to implement locking on Unix. On Windows it uses the LockFile(), LockFileEx(), and UnlockFile() system calls. SQLite assumes that these system calls all work as advertised. If that is not the case, then database corruption can result. One should note that POSIX advisory locking is known to be buggy or even unimplemented on many NFS implementations (including recent versions of Mac OS X) and that there are reports of locking problems for network filesystems under Windows. Your best defense is to not use SQLite for files on a network filesystem.

It seems that's your problem. You should use a local working copy to avoid problems. You will probably get an extra performance gain while developing, since file I/O is likely to be reduced.

Concerning your deployment server, you might consider using an integration server such as TeamCity or Hudson, that once correctly configured can deploy your changes on your development server automatically (for example, on each commit).

Julien Lebosquain
  • 40,639
  • 8
  • 105
  • 117
1

Most likely the way you access those 'network shares' has been altered when you replaced the server software. So it might might well be that you now face different (more) problems related to the fact that indeed: accessing svn checkouts via network shares is not working reliably.

But why would one want to work on a shared checkout anyway? It makes much more sense to make a separate checkout on all development systems and commit changes separately...

arkascha
  • 41,620
  • 7
  • 58
  • 90
  • I'm the only developer working with the code in this office. Another office in London also checks out from the live server but they don't have a dev server to test on - they tend to do small scale tweaks whereas I do all the big work. So no-one else in THIS office shares my working copy - it's only on the network for site testing purposes. – MikkyX Nov 13 '12 at 12:13
  • Then do it the other way 'round: checkout to your local workstation (where svn access works cause it is a native file system) and export that checkout to the testing server. The access for testing purposes has no problems accessing the checkout via a network share, since it is no svn access (I'd assume...). – arkascha Nov 13 '12 at 12:23
  • I must admit I've not looked in to the Export option before. Will this simply copy the files across to the network drive so that I can test them BEFORE committing? Sounds like it could work. I'll try it. – MikkyX Nov 13 '12 at 12:28
  • Tried Export - if I export from the WC on my machine to a folder on MY machine it works OK. Try to export it to the network drive where it used to live? It crashes a few files in saying it "can't find the file specified". Got a feeling there's a network problem that needs solving now. One thing after another! :-) – MikkyX Nov 13 '12 at 13:20
  • 1
    No no no! Sorry, that is a missunderstanding. With 'export' I meant a file system export. So you make your development workstation a file system server (SMB or NFS or something) and mount the exported share on that MAC server you use for testing. – arkascha Nov 13 '12 at 13:23
  • So.... share the folder I keep my local working copy in, then connect to that share on the Mac, and point Apache to that share so that it can access / run the PHP from my machine instead? – MikkyX Nov 13 '12 at 13:32
  • Exactly. If you work with more than once checkout or re-checkout that often then it might make sense to not only export that folder (the checkout), but maybe the parent folder. This makes you more flexible on the server side to prevent having to remount the share again and again. You just point apache to different folders then or offer all available folders in there. – arkascha Nov 13 '12 at 13:38
  • Understood - I'll give it a shot. – MikkyX Nov 13 '12 at 13:40
  • 1
    It was a pleasure to be of help. This is one of the things I don't like about this forum: too many users give a one shot answer to get points (what for?!?) and that's it. – arkascha Nov 13 '12 at 15:30
1

simillar question has already been answered here - Working copy XXX locked and cleanup failed in SVN

it might not be the desired approach, however it will help you to resolve problems with locks.

think about checking out to new directory each time and than replace the old with the new one

Community
  • 1
  • 1
m1k3y3
  • 2,762
  • 8
  • 39
  • 68
  • I'll try the steps there, thanks. Suspect I might still run into the locks / I/O problems when creating a new working copy but we'll see what happens. – MikkyX Nov 13 '12 at 12:20