Re: Unable to open repository following reboot

[Thorsten Schöning]

Guten Tag Pat Haley,
am Donnerstag, 5. Dezember 2013 um 02:20 schrieben Sie:

> % file /home/phaley/Papers/2011/ArpitVel/SvnPaper/db/rep-cache.db
> /home/phaley/Papers/2011/ArpitVel/SvnPaper/db/rep-cache.db: SQLite 3.x
> database, user version 1
[...]
> lstat(".svn/log", 0x7fff48dcbec0)   = -1 ENOENT (No such file or 
> directory)

Can you access the rep-cache.db using a SQLite client? I would copy
the file from the NAS to some other client with some other filesystem
and try to open it there, from my understanding it shouldn't rely on
anything else from the repo and therefore should be usable with any
client which is able to open SQLite database, like DbVisualizer for
convenience.

Afterwards try the same with the file on the NAS using a shell with
the originally mentioned path from your above message and maybe even
on the NAS after the file was copied to another directory within the
same filesystem with the same quotas.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning   E-Mail:thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme  http://www.AM-SoFT.de/

Telefon...05151-  9468- 55
Fax...05151-  9468- 88
Mobil..0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow

RE: Why does `svnversion -c` give me a range?

[Cooke, Mark]

Hi Bob,

> -Original Message-
> From: Bob Archer [mailto:bob.arc...@amsi.com] 
> Sent: 04 December 2013 15:22
> 
> > Hi Folks,
> > 
> > I would like to include the svn revision number in my 
> > project's version info but I am confused by the results
> > of svnversion.  I want the version number of a tagged
> > tree to always be the same (i.e. the last commit to the
> > tag) but if the tag is to be rebuilt using a fresh
> > checkout some time later `svnversion` seems to report
> > the HEAD revision.  So I looked at `svnversion -c` but
> > this always seems to give me a range e.g. `2:1476`, even
> > directly after an update.
> > 
> > I have read the red book but it is quite vague about the
> > -c option.  Why is `-c`
> > always giving me a range?
> > 
> > Many thanks,
> > 
> > ~ mark c
> 
> If you are on windows you can use SubWCRev which is 
> distributed with tortoiseSVN. It is designed to do what you want.
> 
> http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-subwcrev.html
> 
> BOb

Thanks very much, I do not know how I have managed to not notice that since we 
have been using TortoiseSVN for years...

Interestingly, the sample keyword file does not seem to work properly:

char *Revision  = "$WCREV$";   >>  char *Revision  = "1755";
char *Revision16= "$WCREV&0xFF$";  >>  char *Revision16= "$WCREV&0xFF$";

...but that is for another list.

~ mark c

RE: Why does `svnversion -c` give me a range?

[Cooke, Mark]

> -Original Message-
> From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] 
> Sent: 04 December 2013 16:08
> 
> Ryan Schmidt wrote on Wed, Dec 04, 2013 at 06:14:33 -0600:
> > 
> > On Dec 4, 2013, at 06:00, Cooke, Mark wrote:
> > 
> > > I would like to include the svn revision number in my 
> project's version info but I am confused by the results of 
> svnversion.  I want the version number of a tagged tree to 
> always be the same (i.e. the last commit to the tag) but if 
> the tag is to be rebuilt using a fresh checkout some time 
> later `svnversion` seems to report the HEAD revision.  So I 
> looked at `svnversion -c` but this always seems to give me a 
> range e.g. `2:1476`, even directly after an update.
> > > 
> > > I have read the red book but it is quite vague about the 
> -c option.  Why is `-c` always giving me a range?
> > 
> > I think the `-c` option means: given all the item in this 
> directory and recursive subdirectories, give the oldest and 
> newest changed file. So, the oldest item in your working copy 
> was last changed in revision 2, and the newest was last 
> changed in revision 1476.
> > 
> > And `svnversion` without any flag does seem to give the latest
> > revision to which the working copy was updated, not the last changed
> > revision.
> > 
> 
> Note that "bare" svnversion can give a range as well:
> 
> % svnversion -c ~srv/conf
> 105:143
> % svnversion ~srv/conf
> 142:143

Understood, however for my example I get a different "sort" of answer with(out) 
`-c` on all my WCs (including an unmodified fresh checkout), without `-c` gave 
a single revision, with `-c` always gives a range.  That seems to me to be 
inconsistent (even wrong):
{{{
D:\PROJECTS\Support\Code>svn --version
svn, version 1.7.10 (r1485443)
   compiled Jun  1 2013, 07:40:50


D:\PROJECTS\Support\Code>svn up .
Updating '.':
At revision 638.

D:\PROJECTS\Support\Code>svnversion .
638

D:\PROJECTS\Support\Code>svnversion . -c
235:635
}}}

> FWIW, all this should be documented in 'svnversion --help'.  
> Is it clear there?

As I mentioned, the help text would lead me to expect a consistent style of 
results, hence the question.  The only mention of `-c` is:-
{{{
  -c [--committed] : last changed rather than current revisions
}}}

Combined with the main text: "The version number will be a single number if the 
working copy is single revision, unmodified, not switched and with an URL that 
matches the TRAIL_URL argument." I would also expect a single number using `-c`.

However, I am exclusively on windoze so tsvn's SubWCRev app is ideal for what I 
want.

~ mark c

> > If you want the last changed revision, you could use:
> > 
> > svn info | sed -n 's/^Last Changed Rev: //p'

Re: Why does `svnversion -c` give me a range?

[Ryan Schmidt]

On Dec 5, 2013, at 03:23, Cooke, Mark wrote:

>> Note that "bare" svnversion can give a range as well:
>> 
>>% svnversion -c ~srv/conf
>>105:143
>>% svnversion ~srv/conf
>>142:143
> 
> Understood, however for my example I get a different "sort" of answer 
> with(out) `-c` on all my WCs (including an unmodified fresh checkout), 
> without `-c` gave a single revision, with `-c` always gives a range.  That 
> seems to me to be inconsistent (even wrong):

The output makes sense to me:


> {{{
> D:\PROJECTS\Support\Code>svn --version
> svn, version 1.7.10 (r1485443)
>   compiled Jun  1 2013, 07:40:50
> 
> 
> D:\PROJECTS\Support\Code>svn up .
> Updating '.':
> At revision 638.
> 
> D:\PROJECTS\Support\Code>svnversion .
> 638

This means that all the items in this working copy are “at” revision 638, i.e. 
you ran “svn up -r 638” (or just “svn up” if 638 is the HEAD revision). It 
means this is not a mixed-revision working copy, and that none of the items 
were in a modified state, which can be good to know.


> D:\PROJECTS\Support\Code>svnversion . -c
> 235:635
> }}}

This means the least recently changed item in this working copy was changed in 
revision 235 and the most recently changed item was changed in revision 635.

RE: Why does `svnversion -c` give me a range?

[Cooke, Mark]

> -Original Message-
> From: Ryan Schmidt [mailto:subversion-20...@ryandesign.com] 
> Sent: 05 December 2013 09:29
> 
> On Dec 5, 2013, at 03:23, Cooke, Mark wrote:
> 
> >> Note that "bare" svnversion can give a range as well:
> >> 
> >>% svnversion -c ~srv/conf
> >>105:143
> >>% svnversion ~srv/conf
> >>142:143
> > 
> > Understood, however for my example I get a different "sort" 
> > of answer with(out) `-c` on all my WCs (including an 
> > unmodified fresh checkout), without `-c` gave a single 
> > revision, with `-c` always gives a range.  That seems to me 
> > to be inconsistent (even wrong):
> 
> The output makes sense to me:
> 
> > {{{
> > D:\PROJECTS\Support\Code>svn --version
> > svn, version 1.7.10 (r1485443)
> >   compiled Jun  1 2013, 07:40:50
> > 
> > 
> > D:\PROJECTS\Support\Code>svn up .
> > Updating '.':
> > At revision 638.
> > 
> > D:\PROJECTS\Support\Code>svnversion .
> > 638
> 
> This means that all the items in this working copy are "at" 
> revision 638, i.e. you ran "svn up -r 638" (or just "svn up" 
> if 638 is the HEAD revision). It means this is not a 
> mixed-revision working copy, and that none of the items were 
> in a modified state, which can be good to know.
> 
> 
> > D:\PROJECTS\Support\Code>svnversion . -c
> > 235:635
> > }}}
> 
> This means the least recently changed item in this working 
> copy was changed in revision 235 and the most recently 
> changed item was changed in revision 635.

Ok, I agree that makes sense (and is even consistent with an interpretation of 
the help text).  But is it what a user would want to know?  I wanted just the 
most recent committed version, I wonder if that is too specific?  ...I can get 
it by parsing the output using `-c`.  What would you ever want to know the 
earliest commited revision for?

Basically, `-c` will always give you a range as soon as any file has been 
added/modified/deleted after the initial commit.

Seeing as this is long established output I would not propose changing the 
output of `-c`.  I think (a) the help text could be expanded for the `-c` 
option and (b) a new option for just the "most recent commit" would be useful.  
Both should still use the `MSP` postfixes too.

A) the current behaviour contradicts the headling "single number for fully 
updated WC" description:
{{{
Note that the -c option will almost always return a range, it is a rare working 
copy to have had only one commit or to update all files at the same time.
}}}

B) useful for adding this WC's most-recent-commit revision to version info:
{{{
-m [--most-recent-commit] : report the most recent change revision only
}}}

Does anyone agree?  Is this worth a ticket?

~ mark c

Re: SQLite appears to be compiled without large file support

[Philip Martin]

Adam Daughterson  writes:

> Prior to upgrading to WanDisco's 1.7.14 client, 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.
>
> The really interesting part is that the db file 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 adaughterson3 2013-12-02 15:41 entries
> -rw-r--r--  1 adaughterson adaughterson3 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

Which OS is the client using?  Which version of Subversion were you
using before the upgrade?

The 119K wc.db seems to imply that the checkout successfully added some
files/directories before failing.  How mant rows are present?

  sqlite3 .svn/wc.db "select count(*) from nodes"

Can you identify which file/directory triggered the problem?  Running
the checkout under strace might help identify what is wrong.

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*

Re: Issue - SVN cannot create SASL context

[Stefan Sperling]

On Wed, Dec 04, 2013 at 03:02:10PM -0800, John wrote:
> After many hours of apparently pointless googling, I hope to get an answer
> here.
> 
> I asked a question on unix.stackexchange.com which essentially outlines my
> problem: 
> http://unix.stackexchange.com/questions/103714/svn-failing-to-create-sasl-context
> 
> Here is the text of that question:
> 
> --
> 
> Trying to execute the command
> 
> |svn log svn://[my server address]/path/to/repository
> |
> 
> nets me the following:
> 
> |svn: E170001: Unable to connect to a repository at URL 'svn://[my server 
> address]/path/to/repository'
> svn: E170001: Could not create SASL context: generic failure
> |
> 
> Some quick googling reveals a possiblesolution
> :
> 
> |sudo port activate cyrus-sasl2 @2.1.23_3+kerberos
> |
> 
> However, before I attempt this, I would like to know a couple things.
> 
> 1. What exactly is going on?
> 2. What does this command do? How does it fix the problem?
> 
> 
> 
> As some additional info, I am not using SASL on my server- as far as I am
> aware, anyway. The output of "svnserve --version" on the server shows this:
> _
> 
> svnserve, version 1.6.17 (r1128011)
>compiled Jun 26 2013, 20:44:36
> 
> Copyright (C) 2000-2009 CollabNet.
> Subversion is open source software, see http://subversion.apache.org/
> This product includes software developed by CollabNet
> (http://www.Collab.Net/).
> 
> The following repository back-end (FS) modules are available:
> 
> * fs_base : Module for working with a Berkeley DB repository.
> * fs_fs : Module for working with a plain file (FSFS) repository.
> 
> Cyrus SASL authentication is available.
> 
> 
> The output of running "svn --version" on my client gets this:
> 
> 
> 
> svn, version 1.7.9 (r1462340)
>compiled Apr  6 2013, 21:23:46
> 
> Copyright (C) 2013 The Apache Software Foundation.
> This software consists of contributions made by many people; see the NOTICE
> file for more information.
> Subversion is open source software, see http://subversion.apache.org/
> 
> The following repository access (RA) modules are available:
> 
> * ra_neon : Module for accessing a repository via WebDAV protocol using
> Neon.
>   - handles 'http' scheme
>   - handles 'https' scheme
> * ra_svn : Module for accessing a repository using the svn network protocol.
>   - with Cyrus SASL authentication
>   - handles 'svn' scheme
> * ra_local : Module for accessing a repository on local disk.
>   - handles 'file' scheme
> * ra_serf : Module for accessing a repository via WebDAV protocol using
> serf.
>   - handles 'http' scheme
>   - handles 'https' scheme
> __
> 
> Oddly, I can successfully use that command ("svn log svn://[my server
> address]/path/to/repository") on another client computer without any
> trouble.
> 
> I have no idea where exactly to look to find the source of this problem, or
> what precisely is causing it. Help is greatly appreciated.
> 
> -Cheers,
> John

I believe this is a problem with the Cyrus SASL installation on the
client side. I cannot tell you specifics because I don't know all
the possible failure modes of Cyrus SASL.

I do know that users were hitting this problem some time ago on OpenBSD,
after .la files were removed from the cyrus-sasl package. This prevented
newly compiled Subversion binaries from properly linking to the SASL
libraries, which resulted in the error message you are seeing. However,
this error message could be generated for a number of reasons.

Did you compile the svn client and dependencies yourself, or are
you using binaries provided by some vendor? In the former case,
please try a binary package and check if the problem persists.
See http://subversion.apache.org/packages.html
In the latter case, it might be worth raising this issue with the vendor.

Your best bets for diagnosing the issue yourself are to strace the svn
process and study the output for errors related to SASL, or to run the
svn process in gdb with a breakpoint set to the piece of code in SASL
that raises the error and infer the reason why it's failing to initialise.

Re: Unable to open repository following reboot

[Pat Haley]

Hi Les,


On Wed, Dec 4, 2013 at 7:09 PM, Pat Haley  wrote:

One thing that didn't stand out in my original Email was the reason

for the reboot.  We turned quotas on.  Would svn react poorly
to this?


Only on a write that exceeds quota.


It is a generic linux box.  However doing dmesg before and
after generating an svn error doesn't show anything new.


Can you run the svnadmin verify on the box with the drives?   Maybe it
is just a client/network/mount issue and the things that worked (ls,
etc.) were running from cache.  Can you unmount/mount or reboot a
client?



svnadmin verify does work on the box with the drives.

# svnadmin verify /home/phaley/Papers/2011/ArpitVel/SvnPaper
* Verified revision 0.
* Verified revision 1.
(and so on)

I've scheduled a reboot on a client.  I'll let you know
how that works out.

Thanks.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Pat Haley  Email:  pha...@mit.edu
Center for Ocean Engineering   Phone:  (617) 253-6824
Dept. of Mechanical EngineeringFax:(617) 253-8125
MIT, Room 5-213http://web.mit.edu/phaley/www/
77 Massachusetts Avenue
Cambridge, MA  02139-4301

Re: SQLite appears to be compiled without large file support

[Dave Huang]

On 2013-12-05 1:16 AM, David Kelly wrote:
Repeat adding -s to ls. I think that will list the position of EOF. I 
think you have a sparse file which physically occupies 119k but has 
massive holes which have yet to be assigned disk blocks.


It's the other way around-- ls -l shows the logical length of the file, 
and ls -s shows the actual number of blocks used.


E.g.

$ dd if=/dev/zero of=sparse count=1 seek=1
1+0 records in
1+0 records out
512 bytes transferred in 0.001 secs (512000 bytes/sec)
$ ls -ls sparse
64 -rw-r-  1 khym  wheel  5120512 Dec  5 09:09 sparse

Re: SQLite appears to be compiled without large file support

[Philip Martin]

Adam Daughterson  writes:

> mkdir("/mnt/cns/Users/adaughterson/tmp/Tools/.svn", 0777) = 0
> mkdir("/mnt/cns/Users/adaughterson/tmp/Tools/.svn/pristine", 0777) = 0
> mkdir("/mnt/cns/Users/adaughterson/tmp/Tools/.svn/tmp", 0777) = 0
> open("/mnt/cns/Users/adaughterson/tmp/Tools/.svn/wc.db", 
> O_RDWR|O_CREAT|O_LARGEFILE, 0666) = 3
> fcntl64(3, F_GETFD) = 0
> fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
> close(3)= 0
> stat64("/mnt/cns/Users/adaughterson/tmp/Tools/.svn/wc.db", 
> {st_mode=S_IFREG|0755, st_size=0, ...}) = 0
> open("/mnt/cns/Users/adaughterson/tmp/Tools/.svn/wc.db", 
> O_RDWR|O_CREAT|O_LARGEFILE|O_CLOEXEC, 0644) = 3
> fstat64(3, {st_mode=S_IFREG|0755, st_size=0, ...}) = 0
> close(3)= 0
> write(2, "svn: E200030: sqlite[S22]: large"..., 58svn: E200030: sqlite[S22]: 
> large file support is disabled
> ) = 58

That's odd.  The open, fstat64, close all succeed so what triggered the
error?  The message corresponds to SQLITE_NOLFS in the sqlite
amalgamation, so I guess it's the code in findInodeInfo:

  rc = osFstat(fd, &statbuf);
  if( rc!=0 ){
pFile->lastErrno = errno;
#ifdef EOVERFLOW
if( pFile->lastErrno==EOVERFLOW ) return SQLITE_NOLFS;
#endif
return SQLITE_IOERR;
  }

but fstat64 didn't fail.

Does a checkout on a local disk work?

svnadmin create repo
svn co file://`pwd`/repo wc

I've been able to check the binary build logs and the binaries were
built with -D_LARGEFILE64_SOURCE and a 3.7.16.2 SQLite amalgamation.

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*

Re: SQLite appears to be compiled without large file support

[Adam Daughterson]

On 12/05/2013 09:47 AM, Philip Martin wrote:

Adam Daughterson  writes:


mkdir("/mnt/cns/Users/adaughterson/tmp/Tools/.svn", 0777) = 0
mkdir("/mnt/cns/Users/adaughterson/tmp/Tools/.svn/pristine", 0777) = 0
mkdir("/mnt/cns/Users/adaughterson/tmp/Tools/.svn/tmp", 0777) = 0
open("/mnt/cns/Users/adaughterson/tmp/Tools/.svn/wc.db", 
O_RDWR|O_CREAT|O_LARGEFILE, 0666) = 3
fcntl64(3, F_GETFD) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
close(3)= 0
stat64("/mnt/cns/Users/adaughterson/tmp/Tools/.svn/wc.db", 
{st_mode=S_IFREG|0755, st_size=0, ...}) = 0
open("/mnt/cns/Users/adaughterson/tmp/Tools/.svn/wc.db", 
O_RDWR|O_CREAT|O_LARGEFILE|O_CLOEXEC, 0644) = 3
fstat64(3, {st_mode=S_IFREG|0755, st_size=0, ...}) = 0
close(3)= 0
write(2, "svn: E200030: sqlite[S22]: large"..., 58svn: E200030: sqlite[S22]: 
large file support is disabled
) = 58

That's odd.  The open, fstat64, close all succeed so what triggered the
error?  The message corresponds to SQLITE_NOLFS in the sqlite
amalgamation, so I guess it's the code in findInodeInfo:

   rc = osFstat(fd,&statbuf);
   if( rc!=0 ){
 pFile->lastErrno = errno;
#ifdef EOVERFLOW
 if( pFile->lastErrno==EOVERFLOW ) return SQLITE_NOLFS;
#endif
 return SQLITE_IOERR;
   }

but fstat64 didn't fail.

Does a checkout on a local disk work?

svnadmin create repo
svn co file://`pwd`/repo wc

I've been able to check the binary build logs and the binaries were
built with -D_LARGEFILE64_SOURCE and a 3.7.16.2 SQLite amalgamation.

Checkouts on the local disk do work, and checkouts to Samba shares (not 
Windows) work as well.  I've only found operations on WC living on a 
Windows share to not work.


# Local disk
adaughterson@here:tmp$ mkdir svnTesting
adaughterson@here:tmp$ cd svnTesting/
adaughterson@here:svnTesting$ svnadmin create repo
adaughterson@here:svnTesting$ svn co file://`pwd`/repo wc
Checked out revision 0.

# Windows share
adaughterson@here:svnTesting$ pushd /mnt/cns/Users/adaughterson/tmp
/mnt/cns/Users/adaughterson/tmp ~/tmp/svnTesting
adaughterson@here:tmp$ mkdir svnTesting
adaughterson@here:tmp$ cd svnTesting/
adaughterson@here:svnTesting$ svnadmin create repo
adaughterson@LD3439:svnTesting$ strace svn co file://`pwd`/repo wc
execve("/usr/bin/svn", ["svn", "co", 
"file:///mnt/cns/Users/adaughters"..., "wc"], [/* 50 vars */]) = 0

brk(0)  = 0x88e6000
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or 
directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 
0) = 0xb7732000
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or 
directory)
open("/usr/lib/tls/i686/sse2/cmov/libsvn_client-1.so.0", O_RDONLY) = -1 
ENOENT (No such file or directory)
stat64("/usr/lib/tls/i686/sse2/cmov", 0xbfa1ad80) = -1 ENOENT (No such 
file or directory)
open("/usr/lib/tls/i686/sse2/libsvn_client-1.so.0", O_RDONLY) = -1 
ENOENT (No such file or directory)
stat64("/usr/lib/tls/i686/sse2", 0xbfa1ad80) = -1 ENOENT (No such file 
or directory)
open("/usr/lib/tls/i686/cmov/libsvn_client-1.so.0", O_RDONLY) = -1 
ENOENT (No such file or directory)
stat64("/usr/lib/tls/i686/cmov", 0xbfa1ad80) = -1 ENOENT (No such file 
or directory)
open("/usr/lib/tls/i686/libsvn_client-1.so.0", O_RDONLY) = -1 ENOENT (No 
such file or directory)
stat64("/usr/lib/tls/i686", 0xbfa1ad80) = -1 ENOENT (No such file or 
directory)
open("/usr/lib/tls/sse2/cmov/libsvn_client-1.so.0", O_RDONLY) = -1 
ENOENT (No such file or directory)
stat64("/usr/lib/tls/sse2/cmov", 0xbfa1ad80) = -1 ENOENT (No such file 
or directory)
open("/usr/lib/tls/sse2/libsvn_client-1.so.0", O_RDONLY) = -1 ENOENT (No 
such file or directory)
stat64("/usr/lib/tls/sse2", 0xbfa1ad80) = -1 ENOENT (No such file or 
directory)
open("/usr/lib/tls/cmov/libsvn_client-1.so.0", O_RDONLY) = -1 ENOENT (No 
such file or directory)
stat64("/usr/lib/tls/cmov", 0xbfa1ad80) = -1 ENOENT (No such file or 
directory)
open("/usr/lib/tls/libsvn_client-1.so.0", O_RDONLY) = -1 ENOENT (No such 
file or directory)
stat64("/usr/lib/tls", 0xbfa1ad80)  = -1 ENOENT (No such file or 
directory)
open("/usr/lib/i686/sse2/cmov/libsvn_client-1.so.0", O_RDONLY) = -1 
ENOENT (No such file or directory)
stat64("/usr/lib/i686/sse2/cmov", 0xbfa1ad80) = -1 ENOENT (No such file 
or directory)
open("/usr/lib/i686/sse2/libsvn_client-1.so.0", O_RDONLY) = -1 ENOENT 
(No such file or directory)

stat64("/usr/lib/i686/sse2", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
open("/usr/lib/i686/cmov/libsvn_client-1.so.0", O_RDONLY) = -1 ENOENT 
(No such file or directory)

stat64("/usr/lib/i686/cmov", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
open("/usr/lib/i686/libsvn_client-1.so.0", O_RDONLY) = -1 ENOENT (No 
such file or directory)

stat64("/usr/lib/i686", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
open("/usr/lib/sse2/cmov/libsvn_client-1.so.0", O_RDONLY) = -1 ENOENT 
(No such file or directory)
stat64("/usr

Re: SQLite appears to be compiled without large file support

[Les Mikesell]

On Thu, Dec 5, 2013 at 11:07 AM, Adam Daughterson
 wrote:
>
> Checkouts on the local disk do work, and checkouts to Samba shares (not
> Windows) work as well.  I've only found operations on WC living on a Windows
> share to not work.

This is starting to sound like one of those "if it hurts, don't do it"
things.  But maybe it's a version-specific samba bug.

-- 
   Les Mikesell
 lesmikes...@gmail.com

svn merge output: "R"

[C M]

Hello.

I ran "svn merge --reintegrate --dry-run" against branch. As part of the
dry-run preview, several files are marked with:

Rpath-to-file\src\Update.c

What does the "R" mean? I haven't encountered it before. Can someone please
explain?
Thank you.

Re: svn merge output: "R"

[Ben Reser]

On 12/5/13 9:29 AM, C M wrote:
> Hello.
> 
> I ran "svn merge --reintegrate --dry-run" against branch. As part of the
> dry-run preview, several files are marked with:
> 
> Rpath-to-file\src\Update.c
> 
> What does the "R" mean? I haven't encountered it before. Can someone please
> explain?
> Thank you.

>From `svn help merge`:
[[[
  For each merged item a line will be printed with characters reporting the
  action taken. These characters have the following meaning:

A  Added
D  Deleted
U  Updated
C  Conflict
G  Merged
E  Existed
R  Replaced
]]]

File we deleted and then added or copied in again.

Re: SQLite appears to be compiled without large file support

[Adam Daughterson]

On 12/05/2013 10:25 AM, Les Mikesell wrote:

On Thu, Dec 5, 2013 at 11:07 AM, Adam Daughterson
  wrote:

Checkouts on the local disk do work, and checkouts to Samba shares (not
Windows) work as well.  I've only found operations on WC living on a Windows
share to not work.

This is starting to sound like one of those "if it hurts, don't do it"
things.  But maybe it's a version-specific samba bug.


Personally, I blame Windows.  That's not trite at all, is it? ;)

I am all for "not doing it", but the rest of the organization will 
undoubtedly be difficult to convince.


Thanks,

Adam

Re: svn merge output: "R"

[C M]

Ben,

I should have checked "svn help" before posting...thank you for the
response.


On Thu, Dec 5, 2013 at 11:32 AM, Ben Reser  wrote:

> On 12/5/13 9:29 AM, C M wrote:
> > Hello.
> >
> > I ran "svn merge --reintegrate --dry-run" against branch. As part of the
> > dry-run preview, several files are marked with:
> >
> > Rpath-to-file\src\Update.c
> >
> > What does the "R" mean? I haven't encountered it before. Can someone
> please
> > explain?
> > Thank you.
>
> From `svn help merge`:
> [[[
>   For each merged item a line will be printed with characters reporting the
>   action taken. These characters have the following meaning:
>
> A  Added
> D  Deleted
> U  Updated
> C  Conflict
> G  Merged
> E  Existed
> R  Replaced
> ]]]
>
> File we deleted and then added or copied in again.
>

Re: SQLite appears to be compiled without large file support

[Les Mikesell]

On Thu, Dec 5, 2013 at 11:32 AM, Adam Daughterson
 wrote:
>
>>> Checkouts on the local disk do work, and checkouts to Samba shares (not
>>> Windows) work as well.  I've only found operations on WC living on a
>>> Windows
>>> share to not work.
>>
>> This is starting to sound like one of those "if it hurts, don't do it"
>> things.  But maybe it's a version-specific samba bug.
>>
> Personally, I blame Windows.  That's not trite at all, is it? ;)

I blame Microsoft for not opening the file share protocol long ago so
samba could interoperate better, but I don't think this specific
problem is on the server side.

> I am all for "not doing it", but the rest of the organization will
> undoubtedly be difficult to convince.

It is an odd scenario.  Doing it the other way around is probably more
common - but I thought Microsoft had a reasonable NFS these days that
MS-centric admins might be able to set up.

Anyway google turned up a few hits on possibly similar samba issues.
Does adding ,nounix,noserverinfo to the mount options help?

-- 
   Les Mikesell
 lesmikes...@gmail.com

Re: SQLite appears to be compiled without large file support

[Thorsten Schöning]

Guten Tag Adam Daughterson,
am Donnerstag, 5. Dezember 2013 um 18:07 schrieben Sie:

> Checkouts on the local disk do work, and checkouts to Samba shares (not
> Windows) work as well.  I've only found operations on WC living on a 
> Windows share to not work.
[...]
> fstat64(3, {st_mode=S_IFREG|0755, st_size=0, ...}) = 0
> close(3)= 0
> write(2, "svn: E200030: sqlite[S22]: large"..., 58svn: E200030: 
> sqlite[S22]: large file support is disabled
> ) = 58

You could try to run Process Monitor during the access of your test WC
and look for it's recorded output around wc.db. This could show you
what Windows is responding to the file accesses, maybe some error code
or stuff like that.

http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning   E-Mail:thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme  http://www.AM-SoFT.de/

Telefon...05151-  9468- 55
Fax...05151-  9468- 88
Mobil..0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow

Re: SQLite appears to be compiled without large file support

[David Kelly]

On Dec 5, 2013, at 11:32 AM, Adam Daughterson  
wrote:

> On 12/05/2013 10:25 AM, Les Mikesell wrote:
>> On Thu, Dec 5, 2013 at 11:07 AM, Adam Daughterson
>>   wrote:
>>> Checkouts on the local disk do work, and checkouts to Samba shares (not
>>> Windows) work as well.  I've only found operations on WC living on a Windows
>>> share to not work.
>> This is starting to sound like one of those "if it hurts, don't do it"
>> things.  But maybe it's a version-specific samba bug.
> 
> Personally, I blame Windows.  That's not trite at all, is it? ;)
> 
> I am all for "not doing it", but the rest of the organization will 
> undoubtedly be difficult to convince.

IMHO "client-fileshare" is the wrong way for groups to use SVN or similar. But 
I have witnessed that is exactly the first thought Windows shops have, and 
often stop thinking at that point.

--
David Kelly N4HHE, dke...@hiwaay.net

Whom computers would destroy, they must first drive mad.

Re: SQLite appears to be compiled without large file support

[Philip Martin]

Adam Daughterson  writes:

> On 12/05/2013 10:25 AM, Les Mikesell wrote:
>> On Thu, Dec 5, 2013 at 11:07 AM, Adam Daughterson
>>   wrote:
>>> Checkouts on the local disk do work, and checkouts to Samba shares (not
>>> Windows) work as well.  I've only found operations on WC living on a Windows
>>> share to not work.
>> This is starting to sound like one of those "if it hurts, don't do it"
>> things.  But maybe it's a version-specific samba bug.
>>
> Personally, I blame Windows.  That's not trite at all, is it? ;)
>
> I am all for "not doing it", but the rest of the organization will 
> undoubtedly be difficult to convince.

You could try the sqlite3 tool to see if it works on your Windows share:

rm /path/to/share/somefile
strace sqlite3 /path/to/share/somefile "create table foo(text)"

That will use your system SQLite rather than the 3.7.16.2 used by
Subversion.  The next step would be to build 3.7.16.2 and see if that
works.

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*

subversion hardcoded to look for libserf-1.so.1 when a newer libserf is available

[bzb.dev001]

I'm compiling subversion-1.8.5 from source with the following supporting 
projects.  The system is a linux box running Lubuntu 12.04 64bit.


subversion-1.8.5
serf-1.3.2
apache-apr-1.5.0
apache-apr-util-1.5.3


After compiling from source, when run 'svn', the following error occurs.

$ /usr/local/bin/subversion-1.8.5/bin/svn
/usr/local/bin/subversion-1.8.5/bin/svn: error while loading shared 
libraries: libserf-1.so.1: cannot open shared object file: No such file 
or directory



I know that serf had been compiled and it's location was given as a 
parameter to the subversion 'configure' app.  I do not know why it 
insists on finding libserf-1.so.1 when libserf-1.so.1.3.0 was compiled.


Any help is greatly appreciated.
Thanks in advance.



How to reproduce the issue:

o) compile apache-apr-1.5.0

./configure --prefix=/usr/local/bin/apache-apr-1.5.0
make; make test
sudo make install

o) compile apache-apr-util-1.5.3

./configure --prefix=/usr/local/bin/apache-apr-util-1.5.3 
--with-apr=/usr/local/bin/apache-apr-1.5.0

make; make test
sudo make install

o) compile serf-1.3.2

$ scons APR=/usr/local/bin/apache-apr-1.5.0 
APU=/usr/local/bin/apache-apr-util-1.5.3

$ sudo scons install

Details of the output are here: http://pastebin.ca/2492961

The resulting serf headers and libraries are installed here:

/usr/local/lib/libserf-1.a
/usr/local/lib/libserf-1.so.1.3.0
/usr/local/include/serf-1/serf.h
/usr/local/include/serf-1/serf_bucket_types.h
/usr/local/include/serf-1/serf_bucket_util.h
/usr/local/lib/pkgconfig/serf-1.pc

o) compile subversion-1.8.5

$ ./configure --prefix=/usr/local/bin/subversion-1.8.5 
--with-apxs=/usr/local/bin/apache-httpd-2.4.7/bin/apxs --with-jdk 
--enable-javahl --enable-mod-activation --enable-shared --with-openssl 
--with-serf=/usr/local

-output of the config.log is here: http://pastebin.ca/2492975
$ make
-output of the make is here: http://pastebin.ca/2492985
$ sudo make install


After a successful compile and install of all projects.

$ /usr/local/bin/subversion-1.8.5/bin/svn
/usr/local/bin/subversion-1.8.5/bin/svn: error while loading shared 
libraries: libserf-1.so.1: cannot open shared object file: No such file 
or directory

Re: Unable to open repository following reboot

[Pat Haley]

Hi Les,

Well that reboot was more of an adventure than I had
anticipated.  And in all the "adventure" we ended up
rolling back to the configuration without quotas, but
svn is working now.

Thanks for all of your time and help.

Pat



Hi Les,


On Wed, Dec 4, 2013 at 7:09 PM, Pat Haley  wrote:

One thing that didn't stand out in my original Email was the reason

for the reboot.  We turned quotas on.  Would svn react poorly
to this?


Only on a write that exceeds quota.


It is a generic linux box.  However doing dmesg before and
after generating an svn error doesn't show anything new.


Can you run the svnadmin verify on the box with the drives?   Maybe it
is just a client/network/mount issue and the things that worked (ls,
etc.) were running from cache.  Can you unmount/mount or reboot a
client?



svnadmin verify does work on the box with the drives.

# svnadmin verify /home/phaley/Papers/2011/ArpitVel/SvnPaper
* Verified revision 0.
* Verified revision 1.
(and so on)

I've scheduled a reboot on a client.  I'll let you know
how that works out.

Thanks.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Pat Haley  Email:  pha...@mit.edu
Center for Ocean Engineering   Phone:  (617) 253-6824
Dept. of Mechanical EngineeringFax:(617) 253-8125
MIT, Room 5-213http://web.mit.edu/phaley/www/
77 Massachusetts Avenue
Cambridge, MA  02139-4301



--

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Pat Haley  Email:  pha...@mit.edu
Center for Ocean Engineering   Phone:  (617) 253-6824
Dept. of Mechanical EngineeringFax:(617) 253-8125
MIT, Room 5-213http://web.mit.edu/phaley/www/
77 Massachusetts Avenue
Cambridge, MA  02139-4301

Re: subversion hardcoded to look for libserf-1.so.1 when a newer libserf is available

[Philip Martin]

"bzb.dev001"  writes:

> o) compile serf-1.3.2
>
> $ scons APR=/usr/local/bin/apache-apr-1.5.0 
> APU=/usr/local/bin/apache-apr-util-1.5.3
> $ sudo scons install
>
> Details of the output are here: http://pastebin.ca/2492961
>
> The resulting serf headers and libraries are installed here:
>
> /usr/local/lib/libserf-1.a
> /usr/local/lib/libserf-1.so.1.3.0
> /usr/local/include/serf-1/serf.h
> /usr/local/include/serf-1/serf_bucket_types.h
> /usr/local/include/serf-1/serf_bucket_util.h
> /usr/local/lib/pkgconfig/serf-1.pc

That looks like a serf problem, there should be symlinks

 libserf-1.so -> libserf-1.so.1.3.0
 libserf-1.so.1 -> libserf-1.so.1.3.0

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*

Re: subversion hardcoded to look for libserf-1.so.1 when a newer libserf is available

[bzb.dev001]

On 13-12-05 04:06 PM, Philip Martin wrote:

"bzb.dev001"  writes:


o) compile serf-1.3.2

$ scons APR=/usr/local/bin/apache-apr-1.5.0 
APU=/usr/local/bin/apache-apr-util-1.5.3
$ sudo scons install

Details of the output are here: http://pastebin.ca/2492961

The resulting serf headers and libraries are installed here:

/usr/local/lib/libserf-1.a
/usr/local/lib/libserf-1.so.1.3.0
/usr/local/include/serf-1/serf.h
/usr/local/include/serf-1/serf_bucket_types.h
/usr/local/include/serf-1/serf_bucket_util.h
/usr/local/lib/pkgconfig/serf-1.pc

That looks like a serf problem, there should be symlinks

  libserf-1.so -> libserf-1.so.1.3.0
  libserf-1.so.1 -> libserf-1.so.1.3.0



The serf installation does contain your specified symlinks. This is what 
I have in my directory listing at /usr/local/lib.  Since there is not 
problem with the permissions.  That means that subversion is looking 
elsewhere for libserf-1.so.1


# l
total 1.3M
drwxr-xr-x 2 root root  4.0K Dec  5 14:05 pkgconfig/
drwxrwsr-x 4 root staff 4.0K Oct  2 12:07 python2.7/
drwxr-xr-x 3 root root  4.0K Dec  5 09:54 scons-2.3.0/
drwxr-xr-x 3 root root  4.0K Nov 28 02:02 site_ruby/
-rw-r--r-- 1 root root  803K Dec  5 14:04 libserf-1.a
lrwxrwxrwx 1 root root18 Dec  5 14:05 libserf-1.so -> 
libserf-1.so.1.3.0*
lrwxrwxrwx 1 root root18 Dec  5 14:05 libserf-1.so.1 -> 
libserf-1.so.1.3.0*

-rwxr-xr-x 1 root root  451K Dec  5 14:05 libserf-1.so.1.3.0*

Re: subversion hardcoded to look for libserf-1.so.1 when a newer libserf is available

[Philip Martin]

"bzb.dev001"  writes:

> Since there is not problem with the permissions.  That means that
> subversion is looking elsewhere for libserf-1.so.1

The serf dependency is part of libsvn_ra_serf, you can see it using

$ objdump -x libsvn_ra_serf-1.so | grep NEEDED.*serf
  NEEDED   libserf-1.so.1

The tarball libtool might also add that dependency to the svn
executable.

You can see the RPATH in svn or libsvn_ra_serf-1.so using

$ objdump -x svn | grep RPATH
  RPATH/usr/local/serf/lib:/usr/local/subversion/lib

You can see the search as carried out by the linker using

$ LD_DEBUG=libs svn 2>&1 | grep -A1 libserf
 19995: find library=libserf-1.so.1 [0]; searching
 19995:  search path=/usr/local/subversion/lib:/usr/local/serf/lib  
(RPATH from file svn)
 19995:   trying file=/usr/local/subversion/lib/libserf-1.so.1
 19995:   trying file=/usr/local/serf/lib/libserf-1.so.1

I see I had to add an extra RPATH to svn and libsvn_ra_serf by
configuring Subversion with

 ./configure LDFLAGS=-Wl,-rpath,/usr/local/serf/lib

but I install serf in an non-standard place.

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*