RE: Pristiine copy not present

[Simon Heffer]

Thanks all,

svn --version gives:
svn, version 1.7.2 (r1207936)
   compiled Nov 29 2011, 22:11:27

There's no build system issue here. We build a number of different machines 
(windows and UNIXs) and copy the results onto the final machine (Windows Server 
2003 SP2). A script is then run to copy the files into the working copy and 
another to commit to the repository. This system has been in place for over 
three years.

I have checked out a clean copy already to try and fix this but still get the 
same problem. Those messages are what we get.

Unlikely I'll be able to poke around too much on this system as it's used to 
control all our production builds but I'll see what's possible. We do have SQL 
server 2005 installed - is there a way to use that?

Simon

-Original Message-
From: Johan Corveleyn [mailto:jcor...@gmail.com] 
Sent: 24 August 2012 20:59
To: Simon Heffer
Cc: Daniel Shahaf; Bert Huijben; users@subversion.apache.org
Subject: Re: Pristiine copy not present

On Fri, Aug 24, 2012 at 7:12 PM, Bert Huijben  wrote:
>
>
>> -Original Message-
>> From: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
>> Sent: vrijdag 24 augustus 2012 18:32
>> To: Simon Heffer
>> Cc: users@subversion.apache.org
>> Subject: Re: Pristiine copy not present
>>
>> Simon Heffer wrote on Fri, Aug 24, 2012 at 15:55:29 +:
>> >
>> > We seem to have a deadlock of some kind...
>> > At the end of a system build we commit our built components to a 
>> > binary
>> repository...
>> >
>> > svn cleanup --username x --password x
>> >
>>
>> Last I checked, 'cleanup' does not access the repository (well, maybe 
>> except for upgraded 1.0 working copies or something like that, Bert 
>> would know :)), so it doesn't need these arguments.
>
> svn upgrade needs access to the repository for 1.0 working copies, but 
> svn cleanup never.
> (Very early in 1.7 development we used svn cleanup for the upgrade, 
> but we never released that code)
>
>> > svn commit -m "build msg" --username x --password 
>> > svn: E155010: Pristine text 'd9b41b57756396b9cb236801fc02e0da0a83dffe'
>> not present
>> > svn: E155004: Commit failed (details follow):
>> > svn: E155004: Working copy 'D:\xx\Base' locked.
>> > svn: E155004: 'D:\x\Base' is already locked.
>> > svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
> details)
>> >
>> > If I run svn cleanup again I get:
>> > svn: E155010: Pristine text 'd9b41b57756396b9cb236801fc02e0da0a83dffe'
>> not present
>> >
>> > or update:
>> > svn update
>> > svn: E155004: Working copy 'D:\xx\Base' locked.
>> > svn: E155004: 'D:\x\Base' is already locked.
>> > svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
> details)
>> >
>> > The working copy is quite new i.e. not much opportunity to screw it 
>> > up
> :(
>
> Which build system do you use?
>
> Some very popular java based buildsystems automatically use svnkit, 
> and in that case we might have to call in others to help in diagnosinroblem.

Indeed, I've seen similar issues after svnkit usage (though I believe they 
fixed some subtle corruption bugs in their most recent release (1.7.5-v1)). It 
would be nice if you could confirm if svnkit is involved (has ever been used on 
this working copy), and if so, which version. I've never seen 
'pristine-text-not-present' problems with only native svn usage.

Now, if you want to repair this working copy, and you're feeling adventurous, 
here is something you can try (I've had some success with this, but YMMV -- 
WARNING: this involves direct manipulation of the working copy metadata. If 
something goes wrong you might destroy your working copy):

1) Get an sqlite executable (for Windows: download a pre-compiled binary from 
http://www.sqlite.com/download.html). Put it somewhere in your PATH.

2) Open a command prompt and go to the root of your working copy. Execute:

sqlite3 .svn\wc.db "select * from nodes where checksum like 
'%d9b41b57756396b9cb236801fc02e0da0a83dffe'"

This should return exactly 1 row from the svn working copy database.
You can see in that row the local path that's related to that pristine file.

3) Now execute:

sqlite3 .svn\wc.db "update nodes set presence='not-present' where checksum like 
'%d9b41b57756396b9cb236801fc02e0da0a83dffe'"

Now you've changed the presence value of that particular row to "not-present", 
giving svn a chance to recover from the actually missing pristine file.

4) "svn cleanup" again. There might be more missing pristines. Repeat steps 2 
and 3 for them.

5) Finally:

svn update --force

This makes svn actually restore the pristines. The --force is there because svn 
will also try to install the working versions of the "not-present" files. But 
those files are still there. Without --force you'll get tree conflicts on those 
files because of the "unversioned obstructions" that svn thinks they are 
(because of "not-present" svn thinks they shouldn't be there).


HTH
--
Johan

This message has been scanned b

Bug: svn: E000002: Can't create temporary file from template '/tmp/svn-XXXXXX': No such file or directory

[Edwin Goh]

OS: HP-UX

SVN: svn, version 1.7.6 (r1370777) compiled Aug 20 2012, 15:40:19

SVN are download from http://hpux.connect.org.uk/
HP-UX mktemp man page
http://docstore.mik.ua/manuals/hp-ux/en/B2355-60130/mktemp.3C.html

 

When I tried to perform a commit with HP-UX svn client, I received the
following error:

 

svn: E02: Can't create temporary file from template '/tmp/svn-XX':
No such file or directory

svn: E02: Your commit message was left in a temporary file:

svn: E02:'/home/nginhui/svn-commit.2.tmp'

 

After some investigation into SVN 1.7.6 and APR source code, I noticed:

 

SVN client: io.c:4036 - temp_file_create function call apr_file_mktemp with
flag set to not delete when close

APR: mktemp.c:190 - apr_file_mktemp function call Unix mktemp

 

It seems the problem due to mktemp HP-UX open file with the following format
(base on template "svn-XX") svn-[a-z] .

For instance: 

PID= 23451, first call to mktemp you will have a temp file open as
/tmp/svn-a23451 the next call to mktemp will result in /tmp/svn-b23451 and
so on, eventually it will reach z (26 files later), it simple exit with
error since it run out of character

 

What I am not sure is if this is a bug in SVN or APR, shouldn't SVN client
set the flag to delete the temp file as soon as it is close? On the other
hands, APR should have use tmpfile function instead of mktemp or the
internally implementation gettemp.

 

Regards,

Edwin

 

Re: Pristiine copy not present

[Ulrich Eckhardt]

Note up front: Please don't top-post, it makes it difficult to 
understand what exactly you are referring to.



Am 28.08.2012 10:14, schrieb Simon Heffer:

svn --version gives:
 svn, version 1.7.2 (r1207936) compiled Nov 29 2011, 22:11:27

There's no build system issue here.


So you don't use svnkit, neither directly nor indirectly via the build 
system?




We build a number of different machines (windows and UNIXs) and copy
the results onto the final machine (Windows Server 2003 SP2). A
script is then run to copy the files into the working copy and
another to commit to the repository.


There is the danger of mismatches between SVN versions, in particular 
since there are different machines involved. Do you copy working copies 
around or just files?




This system has been in place for over three years.


That's unlikely, since SVN 1.7 was not around at that time and that 
version drastically changed the WC format. At least it was modified 
since the initial installation.




I have checked out a clean copy already to try and fix this but still
get the same problem. Those messages are what we get.


You are able to reproduce this from a clean checkout? That's good, 
because it makes the issue actually diagnosable.




Unlikely I'll be able to poke around too much on this system as it's
used to control all our production builds but I'll see what's
possible.



We do have SQL server 2005 installed - is there a way to
use that?


For what? As backing storage for SVN repositories? No way. You don't 
seem to have any issue with the backing storage anyway, but rather a 
corruption in your working copies, probably caused by the build system.


In any case, there is one thing that looks suspicious:


svn commit -m "build msg" --username x --password 
svn: E155010: Pristine text 'd9b41b57756396b9cb236801fc02e0da0a83dffe'
not present
svn: E155004: Commit failed (details follow):
svn: E155004: Working copy 'D:\xx\Base' locked.

> svn: E155004: 'D:\x\Base' is already locked.
> svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for

details)


The first error E155010 could actually be caused by a bug in SVN, since 
it tries to access the pristine copy before getting a lock on the WC, 
which would be a classic race condition. It could also be an 
opportunistic read-only locking schema, I'm not sure.


The second error E155004 is that it stumbles over the fact that the 
working copy is already locked. This smells of concurrent accesses, like 
if you run two svn operations simultaneously on one WC. For example, it 
could be one that performs some "svn add" operations and the other an 
"svn commit" operation. If your build system starts the first and then 
the second without waiting for the first to fisish, that's exactly what 
you get. Actually, the advise at the end is misleading in that case. You 
don't need a cleanup but only have to wait until a previous operation 
has finished, which will remove the lock.


Good luck!

Uli
**
Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**
Visit our website at http://www.dominolaser.com
**
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten 
bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen 
Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein 
sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, 
weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte 
Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht 
verantwortlich.
**

Re: Bug: svn: E000002: Can't create temporary file from template '/tmp/svn-XXXXXX': No such file or directory

[Stefan Sperling]

Hi Edwin,

Seems like HP-UX's mktemp() shouldn't be used by APR.
Cross-posting this to apr-dev. I believe it should be addressed
in APR rather than Subversion.

On Tue, Aug 28, 2012 at 11:33:48AM +0300, Edwin Goh wrote:
> OS: HP-UX
> 
> SVN: svn, version 1.7.6 (r1370777) compiled Aug 20 2012, 15:40:19
> 
> SVN are download from http://hpux.connect.org.uk/
> HP-UX mktemp man page
> http://docstore.mik.ua/manuals/hp-ux/en/B2355-60130/mktemp.3C.html
> 
>  
> 
> When I tried to perform a commit with HP-UX svn client, I received the
> following error:
> 
>  
> 
> svn: E02: Can't create temporary file from template '/tmp/svn-XX':
> No such file or directory
> 
> svn: E02: Your commit message was left in a temporary file:
> 
> svn: E02:'/home/nginhui/svn-commit.2.tmp'
> 
>  
> 
> After some investigation into SVN 1.7.6 and APR source code, I noticed:
> 
>  
> 
> SVN client: io.c:4036 - temp_file_create function call apr_file_mktemp with
> flag set to not delete when close
> 
> APR: mktemp.c:190 - apr_file_mktemp function call Unix mktemp
> 
>  
> 
> It seems the problem due to mktemp HP-UX open file with the following format
> (base on template "svn-XX") svn-[a-z] .
> 
> For instance: 
> 
> PID= 23451, first call to mktemp you will have a temp file open as
> /tmp/svn-a23451 the next call to mktemp will result in /tmp/svn-b23451 and
> so on, eventually it will reach z (26 files later), it simple exit with
> error since it run out of character
> 
>  
> 
> What I am not sure is if this is a bug in SVN or APR, shouldn't SVN client
> set the flag to delete the temp file as soon as it is close? On the other
> hands, APR should have use tmpfile function instead of mktemp or the
> internally implementation gettemp.
> 
>  
> 
> Regards,
> 
> Edwin
> 
>  
> 

Re: svn 1.7 client issues error on update of single file externals

[Philip Martin]

"Boe, Aasmund"  writes:

> For reference, the server side uses a very old version (1.1.4
> [r13838]), but from what I know externals is a client "feature" so an
> old server should not be a problem. Besides, this workes well using
> subversion 1.6.x (client).
>
> This is the scenario I observe:
>
> 1. Checkout a project (that has single file svn:externals)
>svn checkout http://my/repo/projects/proj1 proj1
>
> 2. Browsing to the folder in my working copy with single file svn:externals.
>E.g.
>myFile.txt http://my/repo/components/comp1/myFile.txt
>
> 3. Executing svn update and I get the following output:
>Fetching external item into 'trunk\proj1\source\myFile.txt':
>: warning: W160016: Failure opening
>'/components/comp1/myFile.txt/myFile.txt'

W160016 is the server-side error SVN_ERR_FS_NOT_DIRECTORY so it looks as
if the server might be the problem.  I don't have a 1.1.4 server to try.
If you provide a complete reproduction recipe it would allow you to try
a newer server and allow other people to try as well.

-- 
Philip

Re: svn 1.7 client issues error on update of single file externals

[Johan Corveleyn]

On Tue, Aug 28, 2012 at 8:17 AM, Boe, Aasmund  wrote:
> Bump. Has anyone observed the below issue, where subversion 1.7.x client 
> issues an error when using 'svn update' on folders containing single file 
> svn:externals? Note that subversion does indeed update the externals, it 
> marely issues an error.
>
> Any response is appreciated!
>
> Best regards,
> Åsmund B. BØ
>
>
> Texas Instruments Norway AS, Gaustadalléen 21, NO-0349 Oslo, Norway. Org. NO 
> 980499480 MVA
>
> -Original Message-
> From: Boe, Aasmund
> Sent: 24. juli 2012 08:53
> To: 'users@subversion.apache.org'
> Subject: svn 1.7 client issues error on update of single file externals
>
> Using subversion 1.7(.5), updating a working copy that has single file 
> svn:externals results in an error, even if the update does indeed work.
> Bug, or am I doing something wrong?
>
> Details posted on stackoverflow.com (before I was aware of this mailing list):
> http://stackoverflow.com/questions/11615043/subversion-client-1-7-file-externals-update-error
>
> And the content of the above url:
> I have come across an error using svn update on a working copy folder with 
> single file svn:externals. I wonder if there is a work-around for this, if I 
> am doing something wrong, or if this is a bug in the client 1.7.x of 
> subversion.
>
> The error occurs when calling svn update using subversion 1.7.5 (tried 
> TortoiseSvn 1.7.7 and slikSvn 1.7.5) on a folder that has single file 
> svn:externals. I'm tempted to say it's a bug in the subversion client, 
> because the update does indeed occur, but it says it fails.
>
> For reference, the server side uses a very old version (1.1.4 [r13838]), but 
> from what I know externals is a client "feature" so an old server should not 
> be a problem. Besides, this workes well using subversion 1.6.x (client).

Hm, you should really upgrade your server. Anything < 1.6 is not
supported anymore (but of course people on this list will still try to
help). I have no idea whether the server version is related to the
problem, but it might be. It might be best if you can reproduce the
issue with a more recent server.

> This is the scenario I observe:
>
> 1. Checkout a project (that has single file svn:externals)
>svn checkout http://my/repo/projects/proj1 proj1
>
> 2. Browsing to the folder in my working copy with single file svn:externals.
>E.g.
>myFile.txt http://my/repo/components/comp1/myFile.txt
>
> 3. Executing svn update and I get the following output:
>Fetching external item into 'trunk\proj1\source\myFile.txt':
>: warning: W160016: Failure opening
>'/components/comp1/myFile.txt/myFile.txt'
>
> If change the svn:externals so that the local file has a different name, like 
> below:
>my_file.txt http://my/repo/components/comp1/myFile.txt
>
> Then the error message in 3. becomes as below, so the the file after the last
> forward slash ('/') is the local version of the file.
>
>Fetching external item into 'trunk\proj1\source\myFile.txt':
>: warning: W160016: Failure opening
>'/components/comp1/myFile.txt/my_file.txt'

Strange indeed.

An important thing to know is that a externals syntax was introduced
in 1.5 (but the old format should still work).

The old format is (line format inside the multiline svn:externals property):

local_relative_path [-rREV] external_url

The new format is:

[-rREV] external_url[@PEGREV] local_relative_path

In the new format the external_url can be a relative url (in the old
format only fully qualified urls without peg revision are accepted).
See [1] for more details and examples.

Since there is some kind of mixup between the local relative path and
the external url, it seems that there is some problem with the
interpretation between the old and the new syntax by the client, or
something like that. Important to know: ../, ^/, // and / are used to
start a relative url (see [1]), so if your local_relative_path starts
with those, it would be interpreted as a url by the client, and it
would parse everything with the new syntax.

Could you show us the exact svn:externals property (maybe redacted to
hide urls and such, but preferably as close as possible to the
original)? Or it would be even better if you could reproduce the issue
with a self-contained recipe, starting with 'svnadmin create
testrepo', and checking out a working copy with 'svn checkout
file:///path/to/testrepo'.


[1] http://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html

-- 
Johan

RE: svn 1.7 client issues error on update of single file externals

[Boe, Aasmund]

> W160016 is the server-side error SVN_ERR_FS_NOT_DIRECTORY so it looks as
> if the server might be the problem.  I don't have a 1.1.4 server to try.
> If you provide a complete reproduction recipe it would allow you to try
> a newer server and allow other people to try as well.
>
> --
> Philip

I will see if I can reproduce the problem with a newer server version.
It seems to me that the 1.7.x client does something that the 1.6.x does not - 
since updating svn:externals works just fine using a 1.6.x client ..?

--
Åsmund



Texas Instruments Norway AS, Gaustadalléen 21, NO-0349 Oslo, Norway. Org. NO 
980499480 MVA

-Original Message-
From: MARTIN PHILIP [mailto:codematt...@ntlworld.com] On Behalf Of Philip Martin
Sent: 28. august 2012 11:56
To: Boe, Aasmund
Cc: users@subversion.apache.org
Subject: Re: svn 1.7 client issues error on update of single file externals

"Boe, Aasmund"  writes:

> For reference, the server side uses a very old version (1.1.4
> [r13838]), but from what I know externals is a client "feature" so an
> old server should not be a problem. Besides, this workes well using
> subversion 1.6.x (client).
>
> This is the scenario I observe:
>
> 1. Checkout a project (that has single file svn:externals)
>svn checkout http://my/repo/projects/proj1 proj1
>
> 2. Browsing to the folder in my working copy with single file svn:externals.
>E.g.
>myFile.txt http://my/repo/components/comp1/myFile.txt
>
> 3. Executing svn update and I get the following output:
>Fetching external item into 'trunk\proj1\source\myFile.txt':
>: warning: W160016: Failure opening
>'/components/comp1/myFile.txt/myFile.txt'

W160016 is the server-side error SVN_ERR_FS_NOT_DIRECTORY so it looks as
if the server might be the problem.  I don't have a 1.1.4 server to try.
If you provide a complete reproduction recipe it would allow you to try
a newer server and allow other people to try as well.

--
Philip

[no subject]

[James French]

Hi,

Using svn 1.7.6 I've had an error a couple of times on reintegration. Here is 
the scenario:

- A file called checkBackwardsCompatibilty.bat is on trunk and has merge info 
on it (I don't want it to but that's a separate discussion).
- The merge info on this file gets updated regularly as people sync 
up/reintegrate branches (again, I hate this, but separate discussion).
- This file is deleted on a dev branch.
- Reintegrate dev branch.

=> Error Can't set properies on 'trunk\checkBackwardsCompatibility.bat': 
invalid status for updating properties.

I'm pretty sure I had the same sort of error as the one I'm describing here 
when I synced up from trunk too.

It does not seem to have broken anything catastrophically, but I don't like it. 
I've been using 1.7.5/1.7.6 for a while now and this seems to be the main 
wrinkle, except for getting wc.db into a bad state and not knowing how to 
recover.

I've attached a screenshot from tortoisesvn.

Cheers,
James<>

Re: JavaHL info2 problem

[Mark Phippard]

On Mon, Aug 27, 2012 at 6:40 PM, Marcin Porwit  wrote:


> I'm running into a problem with the info2 call in the 1.6 JavaHL library. I 
> am attempting to use this to fake password
> validation for a user, so if this is a bass-ackwards way of doing things, 
> please let me know. I issue two calls to
> svnclient.info2. The first one does an info2 on the local, checked out 
> directory, and the callback stores the serverUrl
> (gotten using the getUrl() call). I get the correct value:

Which method are you calling?  What are you passing for the Revision
and pegRevision arguments?

It seems like it is interpreting the String you are passing as a local
path.  I am guessing you are passing null or something else in the
revision arguments that would cause it do this.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: 'invalid status for updateting properties' error during reintegrate merge (was: no subject)

[Stefan Sperling]

On Tue, Aug 28, 2012 at 01:15:08PM +0100, James French wrote:
> Hi,
> 
> Using svn 1.7.6 I've had an error a couple of times on reintegration. Here is 
> the scenario:
> 
> - A file called checkBackwardsCompatibilty.bat is on trunk and has merge info 
> on it (I don't want it to but that's a separate discussion).
> - The merge info on this file gets updated regularly as people sync 
> up/reintegrate branches (again, I hate this, but separate discussion).
> - This file is deleted on a dev branch.
> - Reintegrate dev branch.
> 
> => Error Can't set properies on 'trunk\checkBackwardsCompatibility.bat': 
> invalid status for updating properties.
> 
> I'm pretty sure I had the same sort of error as the one I'm describing here 
> when I synced up from trunk too.
> 
> It does not seem to have broken anything catastrophically, but I don't like 
> it. I've been using 1.7.5/1.7.6 for a while now and this seems to be the main 
> wrinkle, except for getting wc.db into a bad state and not knowing how to 
> recover.
> 
> I've attached a screenshot from tortoisesvn.

Hi James,

Can you provide a more detailed recipe that shows how to reproduce
the problem starting from an empty repository and running Subversion
operations on it?

If you like you can use the script below as a starting point.
The interesting part is marked with a comment saying:
  # List of steps starts here
Currently this fails to reproduce your problem. Can you show me what
additional steps need to be done to trigger the error? Thanks!

#!/bin/sh

set -e

cwd=`pwd`
basename=`basename $0`
scratch_area="`echo $basename | sed -e s/\.sh$//`"
repos=$scratch_area/repos
trunk=$scratch_area/trunk
branch=$scratch_area/branch
trunk_url=file:///$cwd/$repos/trunk
branch_url=file:///$cwd/$repos/branch

set -x

rm -rf $scratch_area
mkdir -p $scratch_area

mkdir -p $trunk
echo alpha > $trunk/alpha
echo beta > $trunk/beta
mkdir $trunk/gamma
echo delta > $trunk/gamma/delta
mkdir $trunk/epsilon
echo zeta > $trunk/epsilon/zeta

svnadmin create $cwd/$repos
svn import $trunk $trunk_url -m "importing project tree"
svn copy $trunk_url $branch_url -m "creating branch"
rm -rf $trunk
svn checkout $trunk_url $trunk
svn checkout $trunk_url ${trunk}2
svn checkout $branch_url $branch

# List of steps starts here

svn ps foo bar $trunk/alpha
svn commit $trunk -m "set prop"

svn merge $trunk_url $branch
svn commit $branch -m "merge from trunk"

svn rm $branch/alpha
svn commit $branch -m "delete from branch"

svn update $trunk
svn merge --reintegrate $branch_url $trunk

assertion failed (status != svn_wc__db_status_normal)

[Peter Amstutz]

I get the following error when trying to update a checkout.  I did a 
cleanup of the checkout, but that did not affect the error.  The problem 
occurs only with one specific checkout, and on re-downloading out the 
same repository I do not get the error on the new checkout.  I am using 
TortoiseSVN on Windows 7, 64 bit.


---
Subversion Exception!
---
Subversion encountered a serious problem.
Please take the time to report this on the Subversion mailing list
with as much information as possible about what
you were trying to do.
But please first search the mailing list archives for the error message
to avoid reporting the same problem repeatedly.
You can find the mailing list archives at
http://subversion.apache.org/mailing-lists.html

Subversion reported the following
(you can copy the content of this dialog
to the clipboard using Ctrl-C):

In file
 
'D:\Development\SVN\Releases\TortoiseSVN-1.7.8\ext\subversion\subversion\libsvn_wc\update_editor.c'
 line 2899: assertion failed (status != svn_wc__db_status_normal)

TortoiseSVN 1.7.8, Build 23174 - 64 Bit , 2012/08/13 19:49:45
Subversion 1.7.6,
apr 1.4.6
apr-utils 1.3.12
neon 0.29.6
OpenSSL 1.0.1c 10 May 2012
zlib 1.2.7

--
Peter Amstutz
Senior Software Engineer
Technology Solutions Experts
Natick, MA
02131

Re: assertion failed (status != svn_wc__db_status_normal)

[Stefan Sperling]

On Tue, Aug 28, 2012 at 10:02:06AM -0400, Peter Amstutz wrote:
> I get the following error when trying to update a checkout.  I did a
> cleanup of the checkout, but that did not affect the error.  The
> problem occurs only with one specific checkout, and on
> re-downloading out the same repository I do not get the error on the
> new checkout.  I am using TortoiseSVN on Windows 7, 64 bit.

Hi Peter,

does this error happen before the update reports any progress?
Or does it report some progress?

Do you have the sqlite3.exe tool to run some sql commands on the
.svn/wc.db file for further diagnosis? Alternatively, can you share
the .svn/wc.db file (privately, if you prefer, since it might contain
sensitive information)?

Thanks!

RE: 'invalid status for updateting properties' error during reintegrate merge (was: no subject)

[James French]

From: Stefan Sperling [s...@elego.de]
Sent: 28 August 2012 15:03
To: James French
Cc: users@subversion.apache.org
Subject: Re: 'invalid status for updateting properties' error during 
reintegrate merge  (was: no subject)

On Tue, Aug 28, 2012 at 01:15:08PM +0100, James French wrote:
> Hi,
>
> Using svn 1.7.6 I've had an error a couple of times on reintegration. Here is 
> the scenario:
>
> - A file called checkBackwardsCompatibilty.bat is on trunk and has merge info 
> on it (I don't want it to but that's a separate discussion).
> - The merge info on this file gets updated regularly as people sync 
> up/reintegrate branches (again, I hate this, but separate discussion).
> - This file is deleted on a dev branch.
> - Reintegrate dev branch.
>
> => Error Can't set properies on 'trunk\checkBackwardsCompatibility.bat': 
> invalid status for updating properties.
>
> I'm pretty sure I had the same sort of error as the one I'm describing here 
> when I synced up from trunk too.
>
> It does not seem to have broken anything catastrophically, but I don't like 
> it. I've been using 1.7.5/1.7.6 for a while now and this seems to be the main 
> wrinkle, except for getting wc.db into a bad state and not knowing how to 
> recover.
>
> I've attached a screenshot from tortoisesvn.

Hi James,

Can you provide a more detailed recipe that shows how to reproduce
the problem starting from an empty repository and running Subversion
operations on it?

If you like you can use the script below as a starting point.
The interesting part is marked with a comment saying:
  # List of steps starts here
Currently this fails to reproduce your problem. Can you show me what
additional steps need to be done to trigger the error? Thanks!

#!/bin/sh

set -e

cwd=`pwd`
basename=`basename $0`
scratch_area="`echo $basename | sed -e s/\.sh$//`"
repos=$scratch_area/repos
trunk=$scratch_area/trunk
branch=$scratch_area/branch
trunk_url=file:///$cwd/$repos/trunk
branch_url=file:///$cwd/$repos/branch

set -x

rm -rf $scratch_area
mkdir -p $scratch_area

mkdir -p $trunk
echo alpha > $trunk/alpha
echo beta > $trunk/beta
mkdir $trunk/gamma
echo delta > $trunk/gamma/delta
mkdir $trunk/epsilon
echo zeta > $trunk/epsilon/zeta

svnadmin create $cwd/$repos
svn import $trunk $trunk_url -m "importing project tree"
svn copy $trunk_url $branch_url -m "creating branch"
rm -rf $trunk
svn checkout $trunk_url $trunk
svn checkout $trunk_url ${trunk}2
svn checkout $branch_url $branch

# List of steps starts here

svn ps foo bar $trunk/alpha
svn commit $trunk -m "set prop"

svn merge $trunk_url $branch
svn commit $branch -m "merge from trunk"

svn rm $branch/alpha
svn commit $branch -m "delete from branch"

svn update $trunk
svn merge --reintegrate $branch_url $trunk



Thanks ever so much for getting me started on this Stefan. I know its lame but 
I only have 2 days before going on holiday and I won't have time to try and 
reproduce this. I have made a note in our bug tracker to tell me to pick this 
up. Thanks for your help.

Utilisateurs francophones de systèmes de gestion de code source

[Mihamina Rakotomandimby]

Hello,

I was looking for a french speaking place to discuss about Git, Hg, SVN 
and all other SCM in use and did not find.


This is then an attempt to create one.
I created a Google group:
https://groups.google.com/forum/?fromgroups#!forum/sgcs-fr

I invite french sepaking people to join.

The group wouldn't be limited to one SCM but is global.
The topic is the usage of all of them.

Thank you.
--
RMA.

Re: JavaHL info2 problem

[Marcin Porwit]

Hi Mark,

I'm calling the non-deprecated version of info2:
http://subversion.apache.org/docs/javahl/1.7/org/tigris/subversion/javahl/SVNClientInterface.html#info2(java.lang.String,
 org.tigris.subversion.javahl.Revision, org.tigris.subversion.javahl.Revision, 
int, java.lang.String[], org.tigris.subversion.javahl.InfoCallback)

You're right in that it looks like it is treating the URL as a local file 
system path… and yes, I'm passing in null for both the Revsion and pegRevision 
arguments.  What should I be passing in instead? The svn info from the command 
line does not take a revision -- does it pass one in implicitly?

My first call to info2 uses the local file system path:
svnclient.info2(destdir, null, null, 0, null, infoCallback);

The second call to info2 uses the server URL I got from the first info2 call:
svnclient.info2(serverURI, null, null, 0, null, infoCallback);

The actual infoCallback is as follows:
class InformationCallback implements InfoCallback {
private SubversionRepository repo;

InformationCallback(SubversionRepository repo) {
this.repo = repo;
}

public void singleInfo(Info2 info) {
repo.setServerURI(info.getReposRootUrl());
}

}

Thanks,

MKP
On Aug 28, 2012, at 6:06 AM, Mark Phippard wrote:

> On Mon, Aug 27, 2012 at 6:40 PM, Marcin Porwit  wrote:
> 
> 
>> I'm running into a problem with the info2 call in the 1.6 JavaHL library. I 
>> am attempting to use this to fake password
>> validation for a user, so if this is a bass-ackwards way of doing things, 
>> please let me know. I issue two calls to
>> svnclient.info2. The first one does an info2 on the local, checked out 
>> directory, and the callback stores the serverUrl
>> (gotten using the getUrl() call). I get the correct value:
> 
> Which method are you calling?  What are you passing for the Revision
> and pegRevision arguments?
> 
> It seems like it is interpreting the String you are passing as a local
> path.  I am guessing you are passing null or something else in the
> revision arguments that would cause it do this.
> 
> -- 
> Thanks
> 
> Mark Phippard
> http://markphip.blogspot.com/

Re: JavaHL info2 problem

[Mark Phippard]

On Tue, Aug 28, 2012 at 1:14 PM, Marcin Porwit  wrote:

> I'm calling the non-deprecated version of info2:
> http://subversion.apache.org/docs/javahl/1.7/org/tigris/subversion/javahl/SVNClientInterface.html#info2(java.lang.String,
>  org.tigris.subversion.javahl.Revision, 
> org.tigris.subversion.javahl.Revision, int, java.lang.String[], 
> org.tigris.subversion.javahl.InfoCallback)
>
> You're right in that it looks like it is treating the URL as a local file 
> system path… and yes, I'm passing in null for both the Revsion and 
> pegRevision arguments.  What should I be passing in instead? The svn info 
> from the command line does not take a revision -- does it pass one in 
> implicitly?

Yes.  The command line is implicitly passing Revision.HEAD for both of
those arguments.  I would also pass Depth.Empty for the depth.

The first call to the API that gives you the URL, should also give you
the Revision of the item in the working copy.  It would be safer to
use that Revision object for the revision and pegRevision.  That way
if the item has been renamed/deleted or moved in the HEAD revision
your API call will still work correctly.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: svn 1.7 client issues error on update of single file externals

[Daniel Shahaf]

Johan Corveleyn wrote on Tue, Aug 28, 2012 at 11:56:44 +0200:
> On Tue, Aug 28, 2012 at 8:17 AM, Boe, Aasmund  wrote:
> > Bump. Has anyone observed the below issue, where subversion 1.7.x client 
> > issues an error when using 'svn update' on folders containing single file 
> > svn:externals? Note that subversion does indeed update the externals, it 
> > marely issues an error.
> >
> > Any response is appreciated!
> >
> > Best regards,
> > Åsmund B. BØ
> >
> >
> > Texas Instruments Norway AS, Gaustadalléen 21, NO-0349 Oslo, Norway. Org. 
> > NO 980499480 MVA
> >
> > -Original Message-
> > From: Boe, Aasmund
> > Sent: 24. juli 2012 08:53
> > To: 'users@subversion.apache.org'
> > Subject: svn 1.7 client issues error on update of single file externals
> >
> > Using subversion 1.7(.5), updating a working copy that has single file 
> > svn:externals results in an error, even if the update does indeed work.
> > Bug, or am I doing something wrong?
> >
> > Details posted on stackoverflow.com (before I was aware of this mailing 
> > list):
> > http://stackoverflow.com/questions/11615043/subversion-client-1-7-file-externals-update-error
> >
> > And the content of the above url:
> > I have come across an error using svn update on a working copy folder with 
> > single file svn:externals. I wonder if there is a work-around for this, if 
> > I am doing something wrong, or if this is a bug in the client 1.7.x of 
> > subversion.
> >
> > The error occurs when calling svn update using subversion 1.7.5 (tried 
> > TortoiseSvn 1.7.7 and slikSvn 1.7.5) on a folder that has single file 
> > svn:externals. I'm tempted to say it's a bug in the subversion client, 
> > because the update does indeed occur, but it says it fails.
> >
> > For reference, the server side uses a very old version (1.1.4 [r13838]), 
> > but from what I know externals is a client "feature" so an old server 
> > should not be a problem. Besides, this workes well using subversion 1.6.x 
> > (client).
> 
> Hm, you should really upgrade your server. Anything < 1.6 is not
> supported anymore (but of course people on this list will still try to
> help). I have no idea whether the server version is related to the
> problem, but it might be. It might be best if you can reproduce the
> issue with a more recent server.
> 
> > This is the scenario I observe:
> >
> > 1. Checkout a project (that has single file svn:externals)
> >svn checkout http://my/repo/projects/proj1 proj1
> >
> > 2. Browsing to the folder in my working copy with single file svn:externals.
> >E.g.
> >myFile.txt http://my/repo/components/comp1/myFile.txt
> >
> > 3. Executing svn update and I get the following output:
> >Fetching external item into 'trunk\proj1\source\myFile.txt':
> >: warning: W160016: Failure opening
> >'/components/comp1/myFile.txt/myFile.txt'
> >
> > If change the svn:externals so that the local file has a different name, 
> > like below:
> >my_file.txt http://my/repo/components/comp1/myFile.txt
> >
> > Then the error message in 3. becomes as below, so the the file after the 
> > last
> > forward slash ('/') is the local version of the file.
> >
> >Fetching external item into 'trunk\proj1\source\myFile.txt':
> >: warning: W160016: Failure opening
> >'/components/comp1/myFile.txt/my_file.txt'
> 
> Strange indeed.
> 
> An important thing to know is that a externals syntax was introduced
> in 1.5 (but the old format should still work).

A 1.5 _client_ is required for the new externals format.  It
will work with any server version.

svn merge help

[Douglass Davis]

Hi,

Client is svn, version 1.6.11 (r934486)

I read the manual, but I'm not sure what I'm doing wrong.

I copied https://mydomain/services/trunk (services) to  
https://mydomain/online/trunk (online) at revision 9884.

There were several bugfixes made on services that I wanted to put in online.  
Some I just edited the code manually in my working copy of online.

Right now, what I would like to do is just take the changes from revisions 9938 
up to and including 9995 (about 20 revisions) from services 
(https://mydomain/services/trunk), and apply those to online 
(https://mydomain/online/trunk).

So, I go to my working copy of online.  I have tried this:

svn merge -r 9937:9996 https://mydomain/services/trunk .

And that just gives me the changes from revision 9995 of services.

I revert, then tried

svn merge https://svn.northcarolina.edu/os/cms/apps/services/trunk@9937 
https://svn.northcarolina.edu/os/cms/apps/services/trunk@9995 .

And still it only gave me the changes from 9995.

How do I get all changes from 9937-9995 (inclusive) and apply them to my 
working copy of online?


Thanks,
Doug

RE: svn merge help

[John Maher]

I can be wrong because I'm struggling with this myself, but shouldn't
rev 9995 already include all the prior changes?

 

JPM

 



From: Douglass Davis [mailto:dda...@northcarolina.edu] 
Sent: Tuesday, August 28, 2012 3:55 PM
To: users@subversion.apache.org
Subject: svn merge help

 

Hi,

 

Client is svn, version 1.6.11 (r934486)

 

I read the manual, but I'm not sure what I'm doing wrong.

 

I copied https://mydomain/services/trunk (services) to
https://mydomain/online/trunk (online) at revision 9884.

 

There were several bugfixes made on services that I wanted to put in
online.  Some I just edited the code manually in my working copy of
online.

 

Right now, what I would like to do is just take the changes from
revisions 9938 up to and including 9995 (about 20 revisions) from
services (https://mydomain/services/trunk), and apply those to online
(https://mydomain/online/trunk).

 

So, I go to my working copy of online.  I have tried this:

 

svn merge -r 9937:9996 https://mydomain/services/trunk .

 

And that just gives me the changes from revision 9995 of services.

 

I revert, then tried

 

svn merge https://svn.northcarolina.edu/os/cms/apps/services/trunk@9937
https://svn.northcarolina.edu/os/cms/apps/services/trunk@9995 .

 

And still it only gave me the changes from 9995.

 

How do I get all changes from 9937-9995 (inclusive) and apply them to my
working copy of online?  

 

 

Thanks,

Doug

 

RE: svn merge help

[Douglass Davis]

The changes are included in the services branch, but not in the online branch.  
I want to take changes from one branch (services) and apply them to the other 
(online).
- Doug

From: John Maher [mailto:jo...@rotair.com]
Sent: Tuesday, August 28, 2012 4:08 PM
To: Douglass Davis; users@subversion.apache.org
Subject: RE: svn merge help

I can be wrong because I'm struggling with this myself, but shouldn't rev 9995 
already include all the prior changes?

JPM


From: Douglass Davis 
[mailto:dda...@northcarolina.edu]
Sent: Tuesday, August 28, 2012 3:55 PM
To: users@subversion.apache.org
Subject: svn merge help

Hi,

Client is svn, version 1.6.11 (r934486)

I read the manual, but I'm not sure what I'm doing wrong.

I copied https://mydomain/services/trunk (services) to  
https://mydomain/online/trunk (online) at revision 9884.

There were several bugfixes made on services that I wanted to put in online.  
Some I just edited the code manually in my working copy of online.

Right now, what I would like to do is just take the changes from revisions 9938 
up to and including 9995 (about 20 revisions) from services 
(https://mydomain/services/trunk), and apply those to online 
(https://mydomain/online/trunk).

So, I go to my working copy of online.  I have tried this:

svn merge -r 9937:9996 https://mydomain/services/trunk .

And that just gives me the changes from revision 9995 of services.

I revert, then tried

svn merge https://svn.northcarolina.edu/os/cms/apps/services/trunk@9937 
https://svn.northcarolina.edu/os/cms/apps/services/trunk@9995 .

And still it only gave me the changes from 9995.

How do I get all changes from 9937-9995 (inclusive) and apply them to my 
working copy of online?


Thanks,
Doug

vendor branch merge: how to highlight patches for review?

[Q. Chap]

Hello,

 I've been reading:
http://svnbook.red-bean.com/en/1.7/svn-book.html#svn.advanced.vendorbr 
http://svnbook.red-bean.com/en/1.7/svn-book.html#svn.advanced.vendorbr&lang= 

 This looks great, but I have a question. (Assuming, per the examples, that I 
have local patches to "libcomplex-1.0")

 When I merge the updates from "/vendor/libcomplex/2.0" to my project 
trunk/branch I will have many updated files in that working copy prior to 
commit.

 Most of these updates I'd like to accept as-is, because they reflect the 
vendor's changes. However, I'd like carefully examine the files that I've 
previously patched just to ensure things still make sense or are required. 
(Even if SVN can "successfully" merge the changes.) 

 What command(s) should I use to bring in the "libcomplex/2.0" changes but 
identify the all files I ever messed with?

 Or am I missing something here?

 Thank you
 David

Re: vendor branch merge: how to highlight patches for review?

[Ryan Schmidt]

On Aug 28, 2012, at 15:57, "Q. Chap" wrote:

> When I merge the updates from "/vendor/libcomplex/2.0" to my project 
> trunk/branch I will have many updated files in that working copy prior to 
> commit.
> 
> Most of these updates I'd like to accept as-is, because they reflect the 
> vendor's changes.  However, I'd like carefully examine the files that I've 
> previously patched just to ensure things still make sense or are required.  
> (Even if SVN can "successfully" merge the changes.) 
> 
> What command(s) should I use to bring in the "libcomplex/2.0" changes but 
> identify the all files I ever messed with?

These are two separate operations.


Merging is as in the book:

$ cd working-copies/calc
$ svn merge ^/vendor/libcomplex/1.0  \
^/vendor/libcomplex/current  \
libcomplex
… # resolve all the conflicts between their changes and our changes
$ svn commit -m "merging libcomplex-1.1 into the main branch"
…

In fact I prefer to be explicit about what I'm merging, so if I'm upgrading my 
copy of the code from 1.0 to 2.0 then I do:

$ svn merge ^/vendor/libcomplex/1.0  \
^/vendor/libcomplex/2.0  \
libcomplex


And if you want to figure out what files you've modified in your copy of the 
code, that's a different separate command. Assuming you originally copied 
libcomplex 1.0 into your "calc" project as the book shows:

$ svn copy http://svn.example.com/repos/vendor/libcomplex/1.0  \
   http://svn.example.com/repos/calc/libcomplex\
   -m "bringing libcomplex-1.0 into the main branch"

And then subsequently modified your copy in "calc" in some way and committed 
those changes, you can see which files you changed using this command:

$ svn diff --summarize \
   http://svn.example.com/repos/vendor/libcomplex/1.0 \
   http://svn.example.com/repos/calc/libcomplex

If you want to see the actual diffs, not just the names of the files, omit the 
--summarize flag.

Svn 1.7 merge info property

[Rp0013]

Hi

I wanted to mute the svn merge info property on my subversion server 

Is there such a way 

We don't need the info currently and when merging it is causing a huge log with 
all changes to property being recorded and what we need is only the code merge 

Regards,

Rajesh

Sent from my iPhone

Re: vendor branch merge: how to highlight patches for review?

[Q. Chap]

> >
> > What command(s) should I use to bring in the "libcomplex/2.0" changes but 
> > identify the all files I ever messed with?
>
> These are two separate operations.
>
>  [snip]
>
> $ svn merge ^/vendor/libcomplex/1.0 \
>  ^/vendor/libcomplex/2.0 \
>  libcomplex
>
> [snip]
> 
> And then subsequently modified your copy in "calc" in some way and committed 
> those changes, you can see which files you changed using this command:
>
> $ svn diff --summarize \
>  http://svn.example.com/repos/vendor/libcomplex/1.0 \
>  http://svn.example.com/repos/calc/libcomplex
>
>

Thank you for the help.

It's that last diff command that comes too late for my taste, though. I'd like 
to avoid checking in the "libcomplex/2.0"->project merge before doing a review.

Ideally, after the merge (but before commit) I'd like to be able to run a 
command like:
"svn diff --show-patches-to-vendor-code"  

Output: list of lib files that I've changed at any point since the previous 
vendor drop.

Could I do something like diff the (pre commit) project working copy against 
"^/vendor/libcomplex/2.0"?

David

svnsync in post commit script

[dhanushka ranasinghe]

Hi..

im trying to setup svn replication using svnsync,

when i ran  flowing the svnsync command [1] in master server's terminal its
syncing fine  , but when i put same svnsync command in post-commit script
it gives the following error [2]

[1]  /usr/bin/svnsync --source-username=svnsync --sync-username=svnsync
sync https://svnslave.example.com/repos/proxy-sync  --sync-password=abc
--source-password=abc

[2]

svnsync: E070014: Unable to connect to a repository at URL '
https://svnslave.example.com/repos/proxy-sync'
svnsync: E070014: Can't read stdin: End of file found


Is there any way to fix that issue

Thank you

Re: vendor branch merge: how to highlight patches for review?

[Ryan Schmidt]

On Aug 28, 2012, at 17:56, Q. Chap  wrote:

> 
>>> 
>>> What command(s) should I use to bring in the "libcomplex/2.0" changes but 
>>> identify the all files I ever messed with?
>> 
>> These are two separate operations.
>> 
>>  [snip]
>> 
>> $ svn merge ^/vendor/libcomplex/1.0 \
>>  ^/vendor/libcomplex/2.0 \
>>  libcomplex
>> 
>> [snip]
>> 
>> And then subsequently modified your copy in "calc" in some way and committed 
>> those changes, you can see which files you changed using this command:
>> 
>> $ svn diff --summarize \
>>  http://svn.example.com/repos/vendor/libcomplex/1.0 \
>>  http://svn.example.com/repos/calc/libcomplex
>> 
>> 
> 
> Thank you for the help.
> 
> It's that last diff command that comes too late for my taste, though.

You can run the diff command at any time that's convenient for you.

As I wrote it above, it shows the changes between version 1.0 of the vendor 
code and the version of the vendor code committed to the "calc" project in the 
repository.


> I'd like to avoid checking in the "libcomplex/2.0"->project merge before 
> doing a review.

Sure. In fact, as I wrote it above, the command would not give correct output 
if you had already committed the merge. If you had committed the merge already, 
then you'd want to compare the original 2.0 code (not the original 1.0 code) 
with your code.


> Ideally, after the merge (but before commit) I'd like to be able to run a 
> command like:
> "svn diff --show-patches-to-vendor-code"  
> 
> Output: list of lib files that I've changed at any point since the previous 
> vendor drop.
> 
> Could I do something like diff the (pre commit) project working copy against 
> "^/vendor/libcomplex/2.0"?

Yes that sounds fine. Something like:

$ svn diff --summarize \
 http://svn.example.com/repos/vendor/libcomplex/1.0 \
 path/to/workingcopyofcalc/libcomplex