Hey Joris Thanks for the reply.
I forwarded your message onto the developers in charge of our office network, and after looking into it they don't think this is what's causing the issue. Unfortunately I don't have any more info than that for now, but can vouch they (hopefully!) know what they're talking about. Just wanted to say thanks for replying, and if you or anyone else has any other ideas for what might be causing the problem please let me know! I have slightly more consistent behavior from my workaround after using it for a couple weeks now: For repo's created in SVN 1.6.5, each commit produces 'database is locked' error after about 30/40 seconds of thinking, for every Versions user in the office. After ok'ing the error, update the same files. Text-based files (for me at least, .php .css .html .js .xml etc.) will update without problems Any images (.jpg .gif .png), upon update, will conflict with the local copy - I'm guessing some headers are being rewritten along the way? I just force delete the duplicates generated by the conflict (for example r10 and r11) which resolves it. Anyway, I'm guessing these issues are to do with my workaround rather than the actual problem! Could this potentially be a OS X issue rather than Versions? Any ideas would be greatly appreciated.. this is really annoying all of us in the office!! Thanks, Dave On Mar 16, 12:00 am, Joris de Beer <[email protected]> wrote: > That setup doesn't sound all that crazy. I use both Versions.app and > TortoiseSVN. I have seen an option in TortoiseSVN that forces SVN to use > _svn instead of .svn directories. > > This is from the TortoiseSVN help file: > > "VS.NET when used with web projects can't handle the .svn folders that > Subversion uses to store its internal information. This is not a bug in > Subversion. The bug is in VS.NET and the frontpage extensions it uses. > Read Section 4.30.11, > “Subversion Working Folders” to find out more about this issue. > > If you want to change the behaviour of Subversion and TortoiseSVN, you can > use this checkbox to set the environment variable which controls this." > > Perhaps Versions.app is not compatible with this setting? Are your Windows > co-workers using Visual Studio? > > > > On Fri, Mar 12, 2010 at 10:47 PM, Dave Star <[email protected]> wrote: > > Hey > > > The office I work in just upgraded to SVN 1.6.5. > > > The files are hosted on a Windows 2003 server, and the SVN is running > > on Fedora 10. The guys in charge of the network/SVN tell me this is > > far from ideal, but for now it's what we have to deal with. > > > Since upgrading - and only with newly created repo's on 1.6.5, older > > repo's work fine - whenever the Macs try to commit anything (all using > > Versions), we get the following error: > > > Commit failed (details follow): > > database is locked > > > The Windows guys using Tortoise don't seem to get any errors. > > > When we looked into it, there seems to be a lot of filenames starting > > with '_.' for example '_.template.css'. We are guessing as this is > > the convention for hidden files on a Mac, that these must be coming > > from Versions? > > > Our current workaround is to commit, get the 'database is locked' > > error (after Versions being in a 'busy' state for about 20 seconds), > > then update the same files. So these files are actually commited, > > regardless of the error. Sometimes - especially with .png files, the > > update conflicts, and we have to manually resolve all the conflicts. > > > Any ideas? > > > Cheers, > > > Dave > > > -- > > You received this message because you are subscribed to the Google Groups > > "Versions" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<versions%[email protected] > > om> > > . > > For more options, visit this group at > >http://groups.google.com/group/versions?hl=en. -- You received this message because you are subscribed to the Google Groups "Versions" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/versions?hl=en.
