You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Adam Daughterson <ad...@gmail.com> on 2013/12/04 21:59:28 UTC

Linux svn clients > 1.7 have issues operating on WC which physically lives on Windows shares

Prior to upgrading to WanDisco svn client 1.7.x I was able to operate on 
working copies which physically live on Windows shares.  After the upgrade, 
I get the following error when trying to do a fresh checkout:

me@here:tmp$ svn co http://myThing/trunk myThing
*svn: E200030: sqlite[S22]: large file support is disabled*

I've verified that I can perform this same operation on a Linux samba share 
with the new clients, and nothing has changed on the Windows side of things.

Anyone have any idea as to WTH this is all about?

Thanks

Re: Linux svn clients > 1.7 have issues operating on WC which physically lives on Windows shares

Posted by Les Mikesell <le...@gmail.com>.
On Wed, Dec 4, 2013 at 4:05 PM, Ben Reser <be...@reser.org> wrote:
> On 12/4/13 12:59 PM, Adam Daughterson wrote:
>> Prior to upgrading to WanDisco svn client 1.7.x I was able to operate on
>> working copies which physically live on Windows shares.  After the upgrade, I
>> get the following error when trying to do a fresh checkout:
>>
>> me@here:tmp$ svn co http://myThing/trunk myThing
>> *svn: E200030: sqlite[S22]: large file support is disabled*
>>
>> I've verified that I can perform this same operation on a Linux samba share
>> with the new clients, and nothing has changed on the Windows side of things.
>>
>> Anyone have any idea as to WTH this is all about?
>
> Subversion 1.7 moved from having .svn directories in each directory and flat
> file entries files to maintain the state of the working copy to using a single
> .svn directory at the root of the working copy and a sqlite database.
>
> The error you're getting is because the working copy database file
> (myThing/.svn/wc.db in your case) is larger than 2GB.  Your Windows server may
> not support files over 2GB.

Or if the filesystem is on VFAT, you might be hitting the the 4GB file
size limit.
>
> All that said, if you have that large of a working copy database, I doubt
> you're going to have very good performance using the working copy over a
> network share.

Not to mention what happens if you have linux filenames that differ
only in case.

-- 
   Les Mikesell
     lesmikesell@gmail.com

Re: Linux svn clients > 1.7 have issues operating on WC which physically lives on Windows shares

Posted by Adam Daughterson <ad...@gmail.com>.
On Wednesday, December 4, 2013 3:05:37 PM UTC-7, Ben Reser wrote:
>
> On 12/4/13 12:59 PM, Adam Daughterson wrote: 
> > Prior to upgrading to WanDisco svn client 1.7.x I was able to operate on 
> > working copies which physically live on Windows shares.  After the 
> upgrade, I 
> > get the following error when trying to do a fresh checkout: 
> > 
> > me@here:tmp$ svn co http://myThing/trunk myThing 
> > *svn: E200030: sqlite[S22]: large file support is disabled* 
> > 
> > I've verified that I can perform this same operation on a Linux samba 
> share 
> > with the new clients, and nothing has changed on the Windows side of 
> things. 
> > 
> > Anyone have any idea as to WTH this is all about? 
>
> Subversion 1.7 moved from having .svn directories in each directory and 
> flat 
> file entries files to maintain the state of the working copy to using a 
> single 
> .svn directory at the root of the working copy and a sqlite database. 
>
> The error you're getting is because the working copy database file 
> (myThing/.svn/wc.db in your case) is larger than 2GB.  Your Windows server 
> may 
> not support files over 2GB. 
>
> You might try adding the lfs flag to the mount options when you mount it 
> to 
> tell Linux to enable large file support on the mount. 
>
> I'm not personally familiar enough with the specifics of what needs to be 
> done 
> on the Windows side to support this or which versions of Windows support 
> it to 
> help you there. 
>
> All that said, if you have that large of a working copy database, I doubt 
> you're going to have very good performance using the working copy over a 
> network share. 
>

The really interesting part is that the file in question is only 119k, so 
that's nice and weird...

me@here:myThing$ ls -alh .svn
total 144K
drwxr-xr-x  4 adaughterson adaughterson 4.0K 2013-12-02 15:42 .
drwxr-xr-x  9 adaughterson adaughterson 4.0K 2013-12-02 15:41 ..
-rw-r--r--  1 adaughterson adaughterson    3 2013-12-02 15:41 entries
-rw-r--r--  1 adaughterson adaughterson    3 2013-12-02 15:41 format
drwxr-xr-x 97 adaughterson adaughterson 4.0K 2013-12-02 15:41 pristine
drwxr-xr-x  5 adaughterson adaughterson 4.0K 2013-12-02 15:41 tmp

*-rw-r--r--  1 adaughterson adaughterson 119K 2013-12-02 15:42 wc.db*
Adam 

Re: Linux svn clients > 1.7 have issues operating on WC which physically lives on Windows shares

Posted by Ben Reser <be...@reser.org>.
On 12/4/13 12:59 PM, Adam Daughterson wrote:
> Prior to upgrading to WanDisco svn client 1.7.x I was able to operate on
> working copies which physically live on Windows shares.  After the upgrade, I
> get the following error when trying to do a fresh checkout:
> 
> me@here:tmp$ svn co http://myThing/trunk myThing
> *svn: E200030: sqlite[S22]: large file support is disabled*
> 
> I've verified that I can perform this same operation on a Linux samba share
> with the new clients, and nothing has changed on the Windows side of things.
> 
> Anyone have any idea as to WTH this is all about?

Subversion 1.7 moved from having .svn directories in each directory and flat
file entries files to maintain the state of the working copy to using a single
.svn directory at the root of the working copy and a sqlite database.

The error you're getting is because the working copy database file
(myThing/.svn/wc.db in your case) is larger than 2GB.  Your Windows server may
not support files over 2GB.

You might try adding the lfs flag to the mount options when you mount it to
tell Linux to enable large file support on the mount.

I'm not personally familiar enough with the specifics of what needs to be done
on the Windows side to support this or which versions of Windows support it to
help you there.

All that said, if you have that large of a working copy database, I doubt
you're going to have very good performance using the working copy over a
network share.