[no subject]

[sbremal]

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

[Cooke, Mark]

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

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

[Ryan Schmidt]

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.

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?

[Bob Archer]

> 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

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

[Ryan Schmidt]

Remember to Reply All so the discussion stays on the mailing list.

On Dec 4, 2013, at 07:52, Cooke, Mark wrote:

>> -Original Message-
>> From: Ryan Schmidt [mailto:subversion-20...@ryandesign.com] 
>> Sent: 04 December 2013 12:15
>> 
>> 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.
> 
> You seem to be right but that is not what I understand from the docs.  The 
> only reference to the -c option says "Use the last-changed revisions rather 
> than the current (i.e., highest locally available) revisions." which to me 
> means that I should get the similar results as I would expect without using 
> -c.  In other words, a fully updated, unmodified WC should give a single 
> revision number and I would expect -c to also give a single revision number 
> (at least that is what I think I want) but it does not:
> 
> D:\PROJECT>svn update
> Updating '.':
> At revision 1770.
> 
> D:\PROJECT>svnversion .
> 1770M
> 
> D:\PROJECT>svnversion . -c
> 2:1764M
> 
> ...I tried the same on a fresh checkout of one of our tags and got similar 
> results (without the `M` flag).  The book could do with some clarification 
> but I am not certain yet what the definitive answer actually is.

Based on my testing, the `-c` flag “use[s] the last-changed revisions” (of each 
item) “rather than the current (i.e., highest locally available) revisions” (of 
each item), as it says.


>>> And `svnversion` without any flag does seem to give the 
>>> latest revision to which the working copy was updated, not 
>>> the last changed revision.
>> 
>> If you want the last changed revision, you could use:
>> 
>> svn info | sed -n 's/^Last Changed Rev: //p'
> 
> We are not allowed to install unapproved apps  and sed 
> is not available here (obviously there are similar ways to achieve this but I 
> was hoping to avoid complicating things any more than I have to).
> 
> The `Last Changed Date` would also be useful so I guess I'll have to go a 
> scripted svn info route.  Oh, hang on, doesn't `svn info` need to be called 
> recursively whereas `svnversion` doesn't?
> 
> Thanks for your help,
> 
> ~ mark c

`svnversion` recursively scans the working copy. `svn info` operates on the 
current directory only.

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

[Daniel Shahaf]

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

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

> 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?

[Daniel Shahaf]

Ryan Schmidt wrote on Wed, Dec 04, 2013 at 10:06:02 -0600:
> `svnversion` recursively scans the working copy. `svn info` operates
> on the current directory only.

In case it's not clear: 'svn info' operates on the current directory
*node* only; it's like "stat ./", not like "ls ./".

That is, if ./README is ta r50 and ./ is at r40, 'svn info' will report
r40.

Daniel

Re: svn log -g doesn't return merge info when operating against repository root

[Henrik Carlqvist]

On Wed, 25 Jul 2012 11:17:55 -0500
Justin Johnson  wrote:

> The command "svn log -vg" is not returning merge info when I execute
> the command while sitting in a working copy of the root level of a
> repository or when I pass in the URL to the root level of root level
> on the command line.  A simple test case can be seen below.

Sorry for my reply to a really old post, but it seems as if no one else
has replied and this problem also seems to still be there.

> echo "## Create repo ##"
> svnadmin create repo
> 
> echo "## Add initial project ##"
> svn co file://`pwd`/repo wc
> cd wc
> mkdir -p p/trunk p/branches
> echo hi > p/trunk/file.txt
> svn add p
> svn ci -m "initial import"
> 
> echo "## Copy trunk to A and make changes ##"
> svn cp p/trunk p/branches/A
> svn ci -m "Create branch A"
> echo hello >> p/branches/A/file.txt
> svn ci -m "Changes on A"
> svn up
> 
> echo "## Merge A to trunk ##"
> cd p/trunk
> svn merge "^/p/branches/A"
> svn ci -m "Commit merge results"
> svn up
> 
> echo "## Log from WC - trunk ##"
> svn log -vg
> cd ../..
> 
> echo "## Log from WC - repo root ##"
> svn log -vg
> cd ..
> 
> echo "## Log from URL - repo root ##"
> svn log -vg file://`pwd`/repo

However, this problem has not allways been like this, it seems as if this
bug came 2012. When I try an older version of svn it works as expected.
This is the output from 1.6.16:

-8<---
minotaur:/tmp> svn --version
svn, version 1.6.16 (r1073529)
   compiled Mar  9 2011, 19:14:47

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 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

minotaur:/tmp> echo "## Create repo ##"
## Create repo ##
minotaur:/tmp> svnadmin create repo
minotaur:/tmp> 
minotaur:/tmp> echo "## Add initial project ##"
## Add initial project ##
minotaur:/tmp> svn co file://`pwd`/repo wc
Checked out revision 0.
minotaur:/tmp> cd wc
minotaur:/tmp/wc> mkdir -p p/trunk p/branches
minotaur:/tmp/wc> echo hi > p/trunk/file.txt
minotaur:/tmp/wc> svn add p
A p
A p/trunk
A p/trunk/file.txt
A p/branches
minotaur:/tmp/wc> svn ci -m "initial import"
Adding p
Adding p/branches
Adding p/trunk
Adding p/trunk/file.txt
Transmitting file data .
Committed revision 1.
minotaur:/tmp/wc> 
minotaur:/tmp/wc> echo "## Copy trunk to A and make changes ##"
## Copy trunk to A and make changes ##
minotaur:/tmp/wc> svn cp p/trunk p/branches/A
A p/branches/A
minotaur:/tmp/wc> svn ci -m "Create branch A"
Adding p/branches/A

Committed revision 2.
minotaur:/tmp/wc> echo hello >> p/branches/A/file.txt
minotaur:/tmp/wc> svn ci -m "Changes on A"
Sendingp/branches/A/file.txt
Transmitting file data .
Committed revision 3.
minotaur:/tmp/wc> svn up
At revision 3.
minotaur:/tmp/wc> 
minotaur:/tmp/wc> echo "## Merge A to trunk ##"
## Merge A to trunk ##
minotaur:/tmp/wc> cd p/trunk
minotaur:/tmp/wc/p/trunk> svn merge "^/p/branches/A"
--- Merging r2 through r3 into '.':
Ufile.txt
minotaur:/tmp/wc/p/trunk> svn ci -m "Commit merge results"
Sendingtrunk
Sendingtrunk/file.txt
Transmitting file data .
Committed revision 4.
minotaur:/tmp/wc/p/trunk> svn up
At revision 4.
minotaur:/tmp/wc/p/trunk> 
minotaur:/tmp/wc/p/trunk> echo "## Log from WC - trunk ##"
## Log from WC - trunk ##
minotaur:/tmp/wc/p/trunk> svn log -vg

r4 | henca | 2013-12-04 19:46:17 +0100 (Wed, 04 Dec 2013) | 1 line
Changed paths:
   M /p/trunk
   M /p/trunk/file.txt

Commit merge results

r3 | henca | 2013-12-04 19:46:14 +0100 (Wed, 04 Dec 2013) | 1 line
Changed paths:
   M /p/branches/A/file.txt
Merged via: r4

Changes on A

r2 | henca | 2013-12-04 19:46:13 +0100 (Wed, 04 Dec 2013) | 1 line
Changed paths:
   A /p/branches/A (from /p/trunk:1)
Merged via: r4

Create branch A

r1 | henca | 2013-12-04 19:46:11 +0100 (Wed, 04 Dec 2013) | 1 line
Changed paths:
   A /p
   A /p/branches
   A /p/trunk
   A /p/trunk/file.txt

initial import

minotaur:/tmp/wc/p/trunk> cd ../..
minotaur:/tmp/wc> 
minotaur:/tmp/wc> echo "## Log from WC - repo root ##"
## Log from WC - repo root ##
minotaur:/tmp/wc> svn log -vg

Re: svn log -g doesn't return merge info when operating against repository root

[Philip Martin]

Henrik Carlqvist  writes:

> On Wed, 25 Jul 2012 11:17:55 -0500
> Justin Johnson  wrote:
>
>> The command "svn log -vg" is not returning merge info when I execute
>> the command while sitting in a working copy of the root level of a
>> repository or when I pass in the URL to the root level of root level
>> on the command line.  A simple test case can be seen below.
>
> Sorry for my reply to a really old post, but it seems as if no one else
> has replied and this problem also seems to still be there.

There is a behaviour change but I believe it is deliberate.  Running log
without -g shows a certain set of revision.  Adding -g causes log to
show more revision and those extra revision, and only those extra
revisions, are marked "Merged via".  The "Merged via" marking indicates
that these revisions are not part of the direct history.

svnadmin create repo --compatible-version 1.6
svn mkdir -mm --parents file://`pwd`/repo/P/A  # r1
svn cp -mm file://`pwd`/repo/P/A ^/P/B # r2
svn cp -mm file://`pwd`/repo/P/B ^/C   # r3
svn mkdir -mm file://`pwd`/repo/C/X# r4
svn co file://`pwd`/repo wc
svn merge ^/C wc/P/B
svn ci -mm wc  # r5
svn merge ^/P/B wc/P/A
svn ci -mm wc  # r6

Log on ^/P/A shows revisions 6 and 1; adding -g includes the extra
revisions 2, 3, 4 and 5 marked "Merged via".

Log on ^/P shows revisions 6, 5, 2 and 1; adding -g includes 3 and 4
marked "Merged via".

Log on ^/ shows all revisions; adding -g includes no more revisions.

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

Unable to open repository following reboot

[Pat Haley]

Hi,

I am not currently a member of this list, so please
cc me on any replies to this message.  Thanks.

We are using svn version 1.6.11 in a linux cluster running
CentOS 6.2.  We have been using svn for several years.  Last
week we rebooted the NAS server which hosts the disk where
(among other things) our svn repositories reside, in order
to enable quotas on that disk.  Since that time, we have been
unable to work with these repositories.  We see the following
error messages

-
(trying local access)
-

mseas(PaperWork)% svn update
svn: Unable to open an ra_local session to URL
svn: Unable to open repository 
'file:///home/phaley/Papers/2011/ArpitVel/SvnPaper'

svn: disk I/O error
svn: disk I/O error

---
(trying network access)
---

chris@optiplex:~/Desktop$ svn update 3DDG
Updating '3DDG':
svn: E200030: Unable to connect to a repository at URL 
'svn+ssh://mseas/software/Students/3DDG'

svn: E200030: disk I/O error
svn: E200030: disk I/O error


Prior to the reboot we were working with these repositories
just fine.

Any thoughts on how to fix this, or what I should look at
to further debug this?

Thank you very much.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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

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

[Adam Daughterson]

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: svn log -g doesn't return merge info when operating against repository root

[Henrik Carlqvist]

Thanks for your quick reply!

> Log on ^/ shows all revisions; adding -g includes no more revisions.

Yep, that is the problem. IMHO the flag -g should also give output which
shows merge information, not only on deeper levels but also on the root
level of the repository. I can understand if most people don't want the
extra merge information, but if you don't want it you simply call svn
without the flag -g.

I don't know why Justin needs the feature of -g on the repository root,
but I can tell how I use it:

I have written a utility which does call "svn log -q -g file://`pwd`/repo"
and uses the information it gets from that to draw revision tree graphs.
My utility is at http://svn2cvsgraph.sourceforge.net/ , using that utility
together with svn versions newer than about two years will give no merge
arrows in the produced graphs. It would probably be possible to rewrite my
utility to get all merge information also from newer versions of svn, but
it would be slower as it would require at least one extra call to svn for
each created branch.

regards Henrik

Re: Unable to open repository following reboot

[Henrik Carlqvist]

> Last week we rebooted the NAS server which hosts the disk where
> (among other things) our svn repositories reside, in order
> to enable quotas on that disk.  Since that time, we have been
> unable to work with these repositories.  We see the following
> error messages
> 
> -
> (trying local access)
> -
> 
> mseas(PaperWork)% svn update
> svn: Unable to open an ra_local session to URL
> svn: Unable to open repository 
> 'file:///home/phaley/Papers/2011/ArpitVel/SvnPaper'
> svn: disk I/O error
> svn: disk I/O error

Are you able to do

ls -al /home/phaley/Papers/2011/ArpitVel/SvnPaper
?

What about: 
find /home/phaley/Papers/2011/ArpitVel/SvnPaper -type f -exec cat {}\; >
/dev/null
?

To me it sounds as if your NAS has some disk problem which might be
hardware related, or, if you are lucky, only a logical error caused by a
clumsy uncontrolled boot. If you have a logical error it might be possible
to fix with some kind of fsck depending upon what kind of NAS you have.

regards Henrik

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

[Ben Reser]

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.

Re: Unable to open repository following reboot

[Pat Haley]

Hi Henrik,


Last week we rebooted the NAS server which hosts the disk where
(among other things) our svn repositories reside, in order
to enable quotas on that disk.  Since that time, we have been
unable to work with these repositories.  We see the following
error messages

-
(trying local access)
-

mseas(PaperWork)% svn update
svn: Unable to open an ra_local session to URL
svn: Unable to open repository 
'file:///home/phaley/Papers/2011/ArpitVel/SvnPaper'

svn: disk I/O error
svn: disk I/O error


Are you able to do

ls -al /home/phaley/Papers/2011/ArpitVel/SvnPaper
?


Sorry that I forgot to mention it in my original Email,
but yes I can look in the directory, and I seem to
see everything I expected

% ls -al /home/phaley/Papers/2011/ArpitVel/SvnPaper
total 32
drwxrwxr-x  6 phaley phaley 4096 Aug 17  2011 .
drwxrwxr-x 13 phaley phaley 4096 Nov  9 20:31 ..
drwxrwxr-x  2 phaley phaley 4096 Aug 17  2011 conf
drwxrwsr-x  6 phaley phaley 4096 Nov  9 20:36 db
-r--r--r--  1 phaley phaley2 Aug 17  2011 format
drwxrwxr-x  2 phaley phaley 4096 Aug 17  2011 hooks
drwxrwxr-x  2 phaley phaley 4096 Aug 17  2011 locks
-rw-rw-r--  1 phaley phaley  229 Aug 17  2011 README.txt



What about: 
find /home/phaley/Papers/2011/ArpitVel/SvnPaper -type f -exec cat {}\; >

/dev/null
?


% find /home/phaley/Papers/2011/ArpitVel/SvnPaper -type f
/home/phaley/Papers/2011/ArpitVel/SvnPaper/conf/svnserve.conf
/home/phaley/Papers/2011/ArpitVel/SvnPaper/conf/authz
/home/phaley/Papers/2011/ArpitVel/SvnPaper/conf/passwd
/home/phaley/Papers/2011/ArpitVel/SvnPaper/hooks/pre-unlock.tmpl
/home/phaley/Papers/2011/ArpitVel/SvnPaper/hooks/post-commit.tmpl
/home/phaley/Papers/2011/ArpitVel/SvnPaper/hooks/post-unlock.tmpl
/home/phaley/Papers/2011/ArpitVel/SvnPaper/hooks/start-commit.tmpl
/home/phaley/Papers/2011/ArpitVel/SvnPaper/hooks/post-lock.tmpl
/home/phaley/Papers/2011/ArpitVel/SvnPaper/hooks/pre-lock.tmpl
/home/phaley/Papers/2011/ArpitVel/SvnPaper/hooks/post-revprop-change.tmpl
/home/phaley/Papers/2011/ArpitVel/SvnPaper/hooks/pre-revprop-change.tmpl
/home/phaley/Papers/2011/ArpitVel/SvnPaper/hooks/pre-commit.tmpl
/home/phaley/Papers/2011/ArpitVel/SvnPaper/locks/db-logs.lock
/home/phaley/Papers/2011/ArpitVel/SvnPaper/locks/db.lock
/home/phaley/Papers/2011/ArpitVel/SvnPaper/db/revs/0/65
/home/phaley/Papers/2011/ArpitVel/SvnPaper/db/revs/0/115
/home/phaley/Papers/2011/ArpitVel/SvnPaper/db/revs/0/38

followed by many more similar lines



To me it sounds as if your NAS has some disk problem which might be
hardware related, or, if you are lucky, only a logical error caused by a
clumsy uncontrolled boot. If you have a logical error it might be possible
to fix with some kind of fsck depending upon what kind of NAS you have.

regards Henrik



-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: Unable to open repository following reboot

[Les Mikesell]

On Wed, Dec 4, 2013 at 4:06 PM, Pat Haley  wrote:
>
>>> svn: Unable to open repository
>>> 'file:///home/phaley/Papers/2011/ArpitVel/SvnPaper'
>>> svn: disk I/O error
>>> svn: disk I/O error

> Sorry that I forgot to mention it in my original Email,
> but yes I can look in the directory, and I seem to
> see everything I expected
>
> % ls -al /home/phaley/Papers/2011/ArpitVel/SvnPaper

How about 'svnadmin verify /home/phaley/Papers/2011/ArpitVel/SvnPaper'?

Also, does the NAS physically holding the disks have any logging
facility where you could see physical disk errors reported?

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

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

[Les Mikesell]

On Wed, Dec 4, 2013 at 4:05 PM, 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.

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
 lesmikes...@gmail.com

Re: Unable to open repository following reboot

[Pat Haley]

Hi Les,


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

svn: Unable to open repository
'file:///home/phaley/Papers/2011/ArpitVel/SvnPaper'
svn: disk I/O error
svn: disk I/O error



Sorry that I forgot to mention it in my original Email,
but yes I can look in the directory, and I seem to
see everything I expected

% ls -al /home/phaley/Papers/2011/ArpitVel/SvnPaper


How about 'svnadmin verify /home/phaley/Papers/2011/ArpitVel/SvnPaper'?


No, that also fails

mseas(MeanAvg)% svnadmin verify /home/phaley/Papers/2011/ArpitVel/SvnPaper
svnadmin: disk I/O error
svnadmin: disk I/O error



Also, does the NAS physically holding the disks have any logging
facility where you could see physical disk errors reported?



I looked in /var/log, but none of the files had any
messages at the times I did the above tests.


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: Unable to open repository following reboot

[Les Mikesell]

On Wed, Dec 4, 2013 at 4:31 PM, Pat Haley  wrote:
>
>> How about 'svnadmin verify /home/phaley/Papers/2011/ArpitVel/SvnPaper'?
>
>
> No, that also fails
>
> mseas(MeanAvg)% svnadmin verify /home/phaley/Papers/2011/ArpitVel/SvnPaper
> svnadmin: disk I/O error
> svnadmin: disk I/O error

So, I'm guessing it's a disk error...

>> Also, does the NAS physically holding the disks have any logging
>> facility where you could see physical disk errors reported?
>>
>
> I looked in /var/log, but none of the files had any
> messages at the times I did the above tests.

It if is a generic linux box 'dmesg' might show it.  If it is some
dedicated file server you'll have to find its own diagnostic
procedures.

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

Re: Unable to open repository following reboot

[Ben Reser]

On 12/4/13 12:52 PM, Pat Haley wrote:
> -
> (trying local access)
> -
> 
> mseas(PaperWork)% svn update
> svn: Unable to open an ra_local session to URL
> svn: Unable to open repository 
> 'file:///home/phaley/Papers/2011/ArpitVel/SvnPaper'
> svn: disk I/O error
> svn: disk I/O error
> 
> ---
> (trying network access)
> ---
> 
> chris@optiplex:~/Desktop$ svn update 3DDG
> Updating '3DDG':
> svn: E200030: Unable to connect to a repository at URL
> 'svn+ssh://mseas/software/Students/3DDG'
> svn: E200030: disk I/O error
> svn: E200030: disk I/O error

The second error contains an error code for an error from sqlite:
$ which-error.py 200030
00200030  SVN_ERR_SQLITE_ERROR

An update wouldn't be touching a sqlite database on the server since the only
sqlite database on the server side is the rep-cache.db which is only used at
commit time.

Additionally I believe the error message "disk I/O error" only occurs in the
sqlite code.

Are you sure that disk that your working copy is on is ok?

On 12/4/13 2:31 PM, Pat Haley wrote:
>> How about 'svnadmin verify /home/phaley/Papers/2011/ArpitVel/SvnPaper'?
>
> No, that also fails
>
> mseas(MeanAvg)% svnadmin verify /home/phaley/Papers/2011/ArpitVel/SvnPaper
> svnadmin: disk I/O error
> svnadmin: disk I/O error

This still looks like some sort of sqlite error.  The rep-cache.db I mentioned
above does get checked as part of svnadmin verify.

Can you run the svnadmin verify under strace:
strace svnadmin verify /home/phaley/Papers/2011/ArpitVel/SvnPaper

You'll get a lot of output but look for the error string in the output and then
look for the preceeding failing system call.  It'll probably be a file handle
so you'll need to dig further up looking for where it was opened.

If you want you could post the output someplace.  If you want to avoid your
data being exposed use "-s 0" to avoid data being printed (but the error string
won't be included).

You can cause strace to write to a file with "-o myoutputfile"

So if you want to post I'd do:
strace -o myoutputfile -s 0 svnadmin verify
/home/phaley/Papers/2011/ArpitVel/SvnPaper

Re: Unable to open repository following reboot

[Pat Haley]

Hi Les,


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

How about 'svnadmin verify /home/phaley/Papers/2011/ArpitVel/SvnPaper'?


No, that also fails

mseas(MeanAvg)% svnadmin verify /home/phaley/Papers/2011/ArpitVel/SvnPaper
svnadmin: disk I/O error
svnadmin: disk I/O error


So, I'm guessing it's a disk error...


If it is, it's a mighty peculiar one:

   (1) We have many other files & directories (including all of
   our user areas) and nothing else is coming up with errors

   (2) These different svn repositories are in widely disparate
   locations under our directory trees, yet all are giving
   similar errors.

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?




Also, does the NAS physically holding the disks have any logging
facility where you could see physical disk errors reported?


I looked in /var/log, but none of the files had any
messages at the times I did the above tests.


It if is a generic linux box 'dmesg' might show it.  If it is some
dedicated file server you'll have to find its own diagnostic
procedures.



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

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: Unable to open repository following reboot

[Pat Haley]

Hi Ben,


On 12/4/13 12:52 PM, Pat Haley wrote:

-
(trying local access)
-

mseas(PaperWork)% svn update
svn: Unable to open an ra_local session to URL
svn: Unable to open repository 
'file:///home/phaley/Papers/2011/ArpitVel/SvnPaper'
svn: disk I/O error
svn: disk I/O error

---
(trying network access)
---

chris@optiplex:~/Desktop$ svn update 3DDG
Updating '3DDG':
svn: E200030: Unable to connect to a repository at URL
'svn+ssh://mseas/software/Students/3DDG'
svn: E200030: disk I/O error
svn: E200030: disk I/O error


The second error contains an error code for an error from sqlite:
$ which-error.py 200030
00200030  SVN_ERR_SQLITE_ERROR

An update wouldn't be touching a sqlite database on the server since the only
sqlite database on the server side is the rep-cache.db which is only used at
commit time.

Additionally I believe the error message "disk I/O error" only occurs in the
sqlite code.

Are you sure that disk that your working copy is on is ok?


Reasonably so.  All the other files are ok.  Only svn is
giving us errors.



On 12/4/13 2:31 PM, Pat Haley wrote:

How about 'svnadmin verify /home/phaley/Papers/2011/ArpitVel/SvnPaper'?

No, that also fails

mseas(MeanAvg)% svnadmin verify /home/phaley/Papers/2011/ArpitVel/SvnPaper
svnadmin: disk I/O error
svnadmin: disk I/O error


This still looks like some sort of sqlite error.  The rep-cache.db I mentioned
above does get checked as part of svnadmin verify.

Can you run the svnadmin verify under strace:
strace svnadmin verify /home/phaley/Papers/2011/ArpitVel/SvnPaper

You'll get a lot of output but look for the error string in the output and then
look for the preceeding failing system call.  It'll probably be a file handle
so you'll need to dig further up looking for where it was opened.

If you want you could post the output someplace.  If you want to avoid your
data being exposed use "-s 0" to avoid data being printed (but the error string
won't be included).

You can cause strace to write to a file with "-o myoutputfile"

So if you want to post I'd do:
strace -o myoutputfile -s 0 svnadmin verify
/home/phaley/Papers/2011/ArpitVel/SvnPaper


That line is complaining about a stale file handle:

fcntl(3, F_SETLK, {type=F_RDLCK, whence=SEEK_SET, start=1073741824, 
len=1}) = -1 ESTALE (Stale NFS file handle)

write(2, "svnadmin: disk I/O error\n", 25) = 25
write(2, "svnadmin: disk I/O error\n", 25) = 25
exit_group(1)   = ?

From a couple of lines above it looks like the file it's
complaining about is
   /home/phaley/Papers/2011/ArpitVel/SvnPaper/db/rep-cache.db
however, I can use the "file" command successfully on that file

% 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


I haven't figured out anything more from the full version of that
strace.  The post-safe version you suggested is at

http://mseas.mit.edu/download/phaley/Svn/svnverify_post.txt

I also did similar straces on an "svn update" from that
same repository.  That is also showing the same
stale file handle error

fcntl(3, F_SETLK, {type=F_RDLCK, whence=SEEK_SET, start=1073741824, 
len=1}) = -1 ESTALE (Stale NFS file handle)

write(2, "svn: Unable to open an ra_local "..., 47) = 47
write(2, "svn: Unable to open repository '"..., 89) = 89
write(2, "svn: disk I/O error\n", 20)   = 20
write(2, "svn: disk I/O error\n", 20)   = 20
lstat(".svn/log", 0x7fff48dcbec0)   = -1 ENOENT (No such file or 
directory)

unlink("Figures/.svn/lock") = 0
unlink(".svn/lock") = 0
exit_group(1)   = ?

The post-safe version of that strace is at

http://mseas.mit.edu/download/phaley/Svn/svnupdate_error_post.txt

Any thoughts on what I should look at next?

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: Linux svn clients > 1.7 have issues operating on WC which physically lives on Windows shares

[Adam Daughterson]

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 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*
Adam 

Re: Unable to open repository following reboot

[David Chapman]

On 12/4/2013 5:20 PM, Pat Haley wrote:



You can cause strace to write to a file with "-o myoutputfile"

So if you want to post I'd do:
strace -o myoutputfile -s 0 svnadmin verify
/home/phaley/Papers/2011/ArpitVel/SvnPaper


That line is complaining about a stale file handle:

fcntl(3, F_SETLK, {type=F_RDLCK, whence=SEEK_SET, start=1073741824, 
len=1}) = -1 ESTALE (Stale NFS file handle)

write(2, "svnadmin: disk I/O error\n", 25) = 25
write(2, "svnadmin: disk I/O error\n", 25) = 25
exit_group(1)   = ?

From a couple of lines above it looks like the file it's
complaining about is
   /home/phaley/Papers/2011/ArpitVel/SvnPaper/db/rep-cache.db
however, I can use the "file" command successfully on that file


You say that the NAS server was rebooted.  Were any of the machines 
accessing the NAS rebooted?  "Stale file handle" looks like a problem 
within the server accessing the data, not the NAS.  If you can't reboot, 
can you umount/mount the NAS from one of the affected machines and then 
try again on that machine?


--
David Chapman  dcchap...@acm.org
Chapman Consulting -- San Jose, CA
Software Development Done Right.
www.chapman-consulting-sj.com

Re: Unable to open repository following reboot

[Les Mikesell]

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?

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

SQLite appears to be compiled without large file support

[Adam Daughterson]

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

Any help is appreciated.

Adam Daughterson

Issue - SVN cannot create SASL context

[John]

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

Re: SQLite appears to be compiled without large file support

[David Kelly]

On Dec 4, 2013, at 7:54 PM, Adam Daughterson  
wrote:

> 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
>  
> Any help is appreciated.

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.


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

Whom computers would destroy, they must first drive mad.