RE: Local repository move

[White, David (KWI C54)]

Uli,

I'm not using Apache.  I do, however, have TortoiseSVN installed.

My Repositories were originally in C:\DW and I want to move them to 
C:\Open\kwc54dw\DW
I have copied the repository "AHEAProps Repository" to this new location

My working files were originally in C:\Dev and I have moved them to 
c:\open\kwc54dw\Dev

When I try to do the switch from within TSVN:

Command: Switch C:\Open\kwc54dw\Dev\AHEAProps to 
file:///C:/Open/kwc54dw/DW/AHEAProps Repository, Revision HEAD  
Error: 'file:///C:/DW/AHEAProps%20Repository'  
Error: is not the same repository as  
Error: 'file:///C:/Open/kwc54dw/DW/AHEAProps%20Repository'  
Finished!:

If I try to use the Relocate command from TSVN, I get this message:

"If seems you are trying to relocate your working copy to a different path 
inside the same repository.
From: file:///C:/DW/AHEAProps Repository
To: file:///C:/open/kwc54dw/DW/AHEAProps Repository

A relocate is only needed if the path to a repository has changed. ... Improper 
use of relocate will corrupt your working copy!"

Stuck now :-(  Thought I understood this, apparently not.

Thanks,

David



-Original Message-
From: Ulrich Eckhardt [mailto:ulrich.eckha...@dominolaser.com] 
Sent: Friday, October 21, 2011 14:51
To: users@subversion.apache.org
Subject: Re: Local repository move

Am 21.10.2011 08:39, schrieb White, David (KWI C54):
> This may seem like a dumb question, but I cannot find out how to do
> this.

Make sure the repos are not accessed at the moment (turn off 
Apache/svnserve) and then just do a file-system move operation using 
your preferred file management utility.


> I thought I needed to use something like
>
> Svn switch -relocate "C:\Old Repository Location\Repository Name"
> "C:\New Repository Location\Repository Name"
>
> When I do this, I get the message "svn : '.' Is not a working copy"

Yes, you need to do that but on your working copies, not on the 
repositories. OTOH, if you are using any server for them, you only need 
to tell the server that they were moved. If the server still runs on the 
same machine/port then working copies don't need relocation.


Cheers!

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: Upgrade to svn 1.7 on cygwin causes W155007 not a working copy?

[Johan Corveleyn]

On Fri, Oct 21, 2011 at 2:10 AM, Mark Utting  wrote:
> Daniel and everyone,
>
> On 19 October 2011 19:40, Daniel Shahaf  wrote:
>>
>> Mark Utting wrote on Wed, Oct 19, 2011 at 11:40:08 +1000:
>> > Summary:
>> > It seems that the new top-level .svn directory spontaneously disappears
>> > sometimes?
>> > Which leaves me with a useless working copy...
>> >
>>
>> Do you have some cron job or other background process that walks around
>> and randomly deletes files or directories?
>
> Nope.
>
>>
>> > Since svn 1.7 was incompatible with my existing working copy, I did 'svn
>> > upgrade' in my top-level directory, which contains several projects from
>> > different SVN repositories.  It removed all the .svn directories in most
>> > of
>> > those subdirectories (all the ones that belonged to my main SVN
>> > repository),
>> > but then failed to create a top-level .svn directory!
>>
>> Actually, it doesn't "create" a top-level .svn dir; it re-uses the .svn
>> dir in the root of the 1.6 wc for itself.
>
> Yes, well this is the directory that is disappearing every day or so.  It
> has happened four times so far, and is a real pain, because it means that
> the working copy is completely disconnected from the repository, and you
> cannot use any svn commands like svn status or svn diff.  Requires lots of
> manual diff commands to copy changes across to a new checkout.
>
> I've found that if I take a backup copy of the .svn directory after each
> commit, I can restore it when the .svn directory disappears, which is at
> least a workaround.
>
> The only pattern I've noticed is that the times this has happened is when
> I've had Eclipse open on that working copy, and have put my laptop into
> sleep/hibernate node.  After it starts up again, the .svn directory is gone
> (sometimes!).

Well, it's obviously something in Eclipse then. I don't think SVN
itself can be the cause of this. Maybe something with the way Eclipse
monitors changes to files, or ignores certain files? Are you using
Subclipse, or Subversive? Maybe it's an issue with one of those
plugins, or with Eclipse itself (maybe try to ask your question on the
respective mailinglists)?

> Anyway, this has been such a pain that I've given up on svn 1.7 and have
> downgraded back to 1.6.17 (r1128011).
>
> I suppose the git-svn frontend might be another option?

Another option for what? What are you trying to achieve? Of course
git-svn is an option, it's always an option, whether you are on svn
1.6 or 1.7. Feel free to use it or to give it a try, but we can't
really give any advice about this if you don't tell us what you're
after...

-- 
Johan

Re: Local repository move

[Ulrich Eckhardt]

Am 21.10.2011 09:41, schrieb White, David (KWI C54):

My Repositories were originally in C:\DW and I want to move them to 
C:\Open\kwc54dw\DW
I have copied the repository "AHEAProps Repository" to this new location


Since you are using file:// access, you need to tell each working copy 
about the moved repository location.




My working files were originally in C:\Dev and I have moved them to 
c:\open\kwc54dw\Dev


I assume with "working file" you mean "SVN working copy" (it's a bit 
nitpicky, but better than misunderstanding). Anyhow, this is a second 
change which is independent of the movement of the repository. In 
general, you can move a working copy around as you like.




When I try to do the switch from within TSVN:

Command: Switch C:\Open\kwc54dw\Dev\AHEAProps to 
file:///C:/Open/kwc54dw/DW/AHEAProps Repository, Revision HEAD
Error: 'file:///C:/DW/AHEAProps%20Repository'
Error: is not the same repository as
Error: 'file:///C:/Open/kwc54dw/DW/AHEAProps%20Repository'
Finished!:

If I try to use the Relocate command from TSVN, I get this message:

"If seems you are trying to relocate your working copy to a different path 
inside the same repository.
From: file:///C:/DW/AHEAProps Repository
To: file:///C:/open/kwc54dw/DW/AHEAProps Repository

A relocate is only needed if the path to a repository has changed.
... Improper use of relocate will corrupt your working copy!"


You shouldn't need any switch operation. In general, the URL of a 
working copy consists of two parts, one is the location of the 
repository, the other is the location inside the repository. If you move 
the repository, you only need to change the former, which is achieved 
using "svn switch --relocate" or since SVN 1.7 with "svn relocate".


In other words, your first switch operation should not be necessary 
since you are not changing the path inside the repository. However, the 
second relocate operation is necessary and I'm surprised it didn't work. 
What strikes me there is that the space in the repository path was not 
escaped using "%20" as it was in the switch operation. This could be a 
bug in TSVN even.


You could try to create a new repository, check out a working copy and 
then move that repository, avoiding paths with spaces on the way. If 
that changes anything, you probably have discovered a bug. If you can 
relocate your working copy using the commandline SVN client, then you 
would also have shown that the bug is probably in TSVN.



BTW: It would be interesting to know if you are using 1.6 or the 
just-released 1.7, because a few things concerning the handling of 
working copies changed in that release. Also, if you are using 1.6 and 
considering upgrading, I would wait for 1.7.1 which is supposed to fix a 
few upgrade bugs.



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: Case-only renames

[Johan Corveleyn]

On Fri, Oct 21, 2011 at 5:49 AM, Ryan Schmidt
 wrote:
> The Subversion 1.7 release notes say:
>
> http://subversion.apache.org/docs/release-notes/1.7.html#windows-case-change
>
>> Changing case of file and directory names on Windows
>>
>> Subversion on Windows now fully supports changing the case of file and 
>> directory names. No more special workarounds, a simple 'svn mv file.java 
>> File.java' just does the right thing.
>
> Is this fix really Windows-specific, or is this also now fixed on OS X and 
> other systems with case-insensitive filesystems?

I think it's only supported on Windows + case-insensitve fs.

I've been working on this issue during the 1.7 release cycle, and I
know that it depends on APR support for "truepath-conversion" (being
able to convert a given path to the actual on-disk path). And AFAIU
there is no support for this in APR for OSX (because nobody has
stepped up yet to actually implement this -- volunteers welcome of
course).

But I'm not completely sure that this means it won't work on OSX +
case-insensitive fs. Maybe, in the absence of truepath-conversion, it
already "just works", without jumping through hoops ... I'm not a Mac
user myself, so I can't test this. Can anyone check this?

I thought OSX + case-insensitive was not a very common setup (i.e.
that it's mostly set up with a case-sensitive filesystem). But maybe
I'm wrong, I really don't know.

-- 
Johan

Re: Case-only renames

[Ryan Schmidt]

On Oct 21, 2011, at 03:17, Johan Corveleyn wrote:

> But I'm not completely sure that this means it won't work on OSX +
> case-insensitive fs. Maybe, in the absence of truepath-conversion, it
> already "just works", without jumping through hoops ... I'm not a Mac
> user myself, so I can't test this. Can anyone check this?

It doesn't work:


$ sw_vers
ProductName:Mac OS X
ProductVersion: 10.4.11
BuildVersion:   8S165
$ svn --version | head -n 2
svn, version 1.7.0 (r1176462)
   compiled Oct 20 2011, 04:25:50
$ cd /tmp
$ svnadmin create repo
$ svn co file:///tmp/repo wc
$ cd wc
$ touch foo
$ svn add foo
A foo
$ svn ci -m "add"
Adding foo
Transmitting file data .
Committed revision 1.
$ svn mv foo FOO
svn: E155007: Path '/private/tmp/wc/FOO' is not a directory
$ 


> I thought OSX + case-insensitive was not a very common setup (i.e.
> that it's mostly set up with a case-sensitive filesystem). But maybe
> I'm wrong, I really don't know.

Nope, all Macs ever made, from the Macintosh 128K 27 years ago right through 
current Macs with the latest OS X, have used case-insensitive filesystems by 
default. Several popular OS X GUI apps, especially by big publishers like 
Microsoft and Adobe, have at times had case errors in their apps, such that if 
you use a case-sensitive filesystem, these apps won't work right. Use of 
case-sensitive filesystems is not recommended on OS X.

There are some esoteric exceptions. For example, before Lion, if you had an 
Xsan filesystem, it was case-sensitive. (With Lion, these are case-insensitive 
by default too.)

RE: Case-only renames

[Bert Huijben]

> -Original Message-
> From: Ryan Schmidt [mailto:subversion-20...@ryandesign.com]
> Sent: vrijdag 21 oktober 2011 5:49
> To: Subversion Users
> Subject: Case-only renames
> 
> The Subversion 1.7 release notes say:
> 
> http://subversion.apache.org/docs/release-notes/1.7.html#windows-case-
> change
> 
> > Changing case of file and directory names on Windows
> >
> > Subversion on Windows now fully supports changing the case of file and
> directory names. No more special workarounds, a simple 'svn mv file.java
> File.java' just does the right thing.
> 
> Is this fix really Windows-specific, or is this also now fixed on OS X and
other
> systems with case-insensitive filesystems?
> 

It is fixed on all operating systems where APR implements it's 'truename'
handling for converting from 'aNYcASE' to 'TrueCase'. But this is currently
only implemented on Windows and some tests still fail on OS/X.

Some problems are fixed on OS/x by moving to SHA1 based pristines, but the
APR api fix is needed to detect naming collisions properly.

Bert

RE: Local repository move

[White, David (KWI C54)]

Uli,
 
I am still using 1.6 becuase when I last checked, the Collabnet distribution of 
the Windows executables had not been updated to 1.7
 
The lack of %20 in the messages could reflect the fact that I had to copy the 
messages into the email - they were in a dialog box, and as a text email, I 
could not paste the image.
 
I'm not on my own machine at present - when I am, I'll try to make the move 
again, possibly manually putting the %20 in there.
 
I suppose if I can't get the relocate to work, I  could dump the repository and 
reload it into the new one.  
 
Thanks,
 
I'll let you know how I get on.
 
David
 



From: Ulrich Eckhardt [mailto:ulrich.eckha...@dominolaser.com]
Sent: Fri 21-Oct-11 16:02
To: users@subversion.apache.org
Subject: Re: Local repository move



Am 21.10.2011 09:41, schrieb White, David (KWI C54):
> My Repositories were originally in C:\DW and I want to move them to 
> C:\Open\kwc54dw\DW
> I have copied the repository "AHEAProps Repository" to this new location

Since you are using file://   access, you need to tell each working 
copy
about the moved repository location.


> My working files were originally in C:\Dev and I have moved them to 
> c:\open\kwc54dw\Dev

I assume with "working file" you mean "SVN working copy" (it's a bit
nitpicky, but better than misunderstanding). Anyhow, this is a second
change which is independent of the movement of the repository. In
general, you can move a working copy around as you like.


> When I try to do the switch from within TSVN:
>
> Command: Switch C:\Open\kwc54dw\Dev\AHEAProps to 
> file:///C:/Open/kwc54dw/DW/AHEAProps Repository, Revision HEAD
> Error: 'file:///C:/DW/AHEAProps%20Repository'
> Error: is not the same repository as
> Error: 'file:///C:/Open/kwc54dw/DW/AHEAProps%20Repository'
> Finished!:
>
> If I try to use the Relocate command from TSVN, I get this message:
>
> "If seems you are trying to relocate your working copy to a different path 
> inside the same repository.
> From: file:///C:/DW/AHEAProps Repository
> To: file:///C:/open/kwc54dw/DW/AHEAProps Repository
>
> A relocate is only needed if the path to a repository has changed.
> ... Improper use of relocate will corrupt your working copy!"

You shouldn't need any switch operation. In general, the URL of a
working copy consists of two parts, one is the location of the
repository, the other is the location inside the repository. If you move
the repository, you only need to change the former, which is achieved
using "svn switch --relocate" or since SVN 1.7 with "svn relocate".

In other words, your first switch operation should not be necessary
since you are not changing the path inside the repository. However, the
second relocate operation is necessary and I'm surprised it didn't work.
What strikes me there is that the space in the repository path was not
escaped using "%20" as it was in the switch operation. This could be a
bug in TSVN even.

You could try to create a new repository, check out a working copy and
then move that repository, avoiding paths with spaces on the way. If
that changes anything, you probably have discovered a bug. If you can
relocate your working copy using the commandline SVN client, then you
would also have shown that the bug is probably in TSVN.


BTW: It would be interesting to know if you are using 1.6 or the
just-released 1.7, because a few things concerning the handling of
working copies changed in that release. Also, if you are using 1.6 and
considering upgrading, I would wait for 1.7.1 which is supposed to fix a
few upgrade bugs.


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: mergeinfo marked not inheritable on sparse checkout

[Stefan Sperling]

On Thu, Oct 20, 2011 at 02:02:48PM -0700, Douglas Wilson wrote:
> 
> 
> On Oct 20, 10:45 am, Stefan Sperling  wrote:
> >
> > Which version of SVN are you running when you hit the problem
> > you described in your first post? 1.6 or 1.7?
> 
> Subversion 1.7.0

Ok, in that case what you are seeing is related to this change in
mergeinfo recording behaviour:
http://subversion.apache.org/docs/release-notes/1.7.html#svn-merge-sparse-no-tree-conflict
Quote:
  Merges into shallow working copies used to cause tree conflicts on nodes
  which were affected by the merge but not present in the working copy. In
  1.7, no tree conflict is flagged. Instead, non-inheritable subtree
  mergeinfo is created on the parents of missing nodes, so that later
  merges into working copies that are not sparse will pick up any missing
  changes for those nodes.

The case you described is similar to the case where 1.6 used to flag a tree
conflict. But it only flagged a tree conflict if the incoming delta of the
merge applies changes to a missing (shallow) subtree. It sounds like
in your case, the incoming delta does not touch the shallow subtree,
so svn 1.6 won't flag a conflict, but svn 1.7 for some reason it creates
non-inheritable mergeinfo on the parent anyway -- which would be wrong,
since the missing subtree isn't affected by the merge.

Does that make sense?

However, I cannot reproduce this problem in quick manual testing.
In my testing, non-inheritable mergeinfo is only created if the
incoming change does modify the missing subtree (see below).
Are you really sure that your merge does not modify the missing subtree?
Because if it does, there is no problem at all, and everything is working
as designed.

My simple test, where a merge wants to modify the file 'epsilon/zeta',
and we perform the merge once the file missing due to a shallow
subtree 'epsilon', and once with the file present but with a different
shallow subtree ('gamma') in the working copy.

$ cd svn-sandbox/trunk
$ echo foo >> epsilon/zeta
$ svn ci -mm
Sendingepsilon/zeta
Transmitting file data .
Committed revision 3.
$ cd ../branch/
$ svn up -set-depth=empty epsilon/
D epsilon/zeta
Updating 'epsilon':
Updated to revision 3.
$ svn st
$ svn up
Updating '.':
At revision 3.
$ svn merge ^/trunk
Skipped missing target: 'epsilon/zeta'
--- Recording mergeinfo for merge of r2 through r3 into '.':
 U   .
--- Recording mergeinfo for merge of r2 through r3 into 'epsilon':
 U   epsilon
Summary of conflicts:
  Skipped paths: 1
$ svn st
 M  .
 M  epsilon
$ svn pl -v epsilon
Properties on 'epsilon':
  svn:mergeinfo
/trunk/epsilon:2-3*
$ svn diff
Index: .
===
--- .   (revision 3)
+++ .   (working copy)

Property changes on: .
___
Added: svn:mergeinfo
   Merged /trunk:r2-3
Index: epsilon
===
--- epsilon (revision 3)
+++ epsilon (working copy)

Property changes on: epsilon
___
Added: svn:mergeinfo
   Merged /trunk/epsilon:r2-3*
$ svn revert -R .
Reverted '.'
Reverted 'epsilon'
$ svn up --set-depth=infinity epsilon
Updating 'epsilon':
Aepsilon/zeta
Updated to revision 3.
$ svn up --set-depth empty gamma
D gamma/delta
Updating 'gamma':
Updated to revision 3.
$ svn merge ^/trunk
--- Merging r2 through r3 into '.':
Uepsilon/zeta
--- Recording mergeinfo for merge of r2 through r3 into '.':
 U   .
$ svn st
 M  .
M   epsilon/zeta
$ svn diff
Index: .
===
--- .   (revision 3)
+++ .   (working copy)

Property changes on: .
___
Added: svn:mergeinfo
   Merged /trunk:r2-3
Index: epsilon/zeta
===
--- epsilon/zeta(revision 3)
+++ epsilon/zeta(working copy)
@@ -1 +1,2 @@
 zeta
+foo
$

Re: FYI

[Stefan Sperling]

On Thu, Oct 20, 2011 at 01:54:57PM -0700, Eric Gervais wrote:
> After reverting changes to the a file I got the below exception.
> 
> I recently upgraded my client to 1.7 (from 1.6) and converted all my
> working copies.

Thanks. Your working copy didn't upgrade cleanly because of a bug
which will be fixed in 1.7.1. Sorry. You should get a new checkout.

Re: Error

[Stefan Sperling]

On Thu, Oct 20, 2011 at 10:25:33PM +0200, Orlando Helmer wrote:
> ---
> 
> Subversion Exception!
> 
> ---
> 
> Subversion encountered a serious problem.
> 
> Please take the time to report this on the Subversion mailing list
> 
> (users@subversion.apache.org)
> 
> 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.0\ext\subversion\subversion\l
> ibsvn_wc\entries.c'
> 
> line 1935: assertion failed (svn_checksum_match(entry_md5_checksum,
> 
> found_md5_checksum))

We're sorry, but your 1.6 working copy is corrupt and cannot be
upgraded. You should get a new checkout.

Subversion 1.7.1 will print a nicer error message pointing out the
file which is corrupt.

Re: Case-only renames

[Stefan Sperling]

On Fri, Oct 21, 2011 at 03:34:38AM -0500, Ryan Schmidt wrote:
> Nope, all Macs ever made, from the Macintosh 128K 27 years ago right
> through current Macs with the latest OS X, have used case-insensitive
> filesystems by default. Several popular OS X GUI apps, especially by
> big publishers like Microsoft and Adobe, have at times had case errors
> in their apps, such that if you use a case-sensitive filesystem, these
> apps won't work right. Use of case-sensitive filesystems is not
> recommended on OS X.
> 
> There are some esoteric exceptions. For example, before Lion, if you
> had an Xsan filesystem, it was case-sensitive. (With Lion, these are
> case-insensitive by default too.)

Sounds like it's worth filing an issue with the APR folks about this 
if there isn't one already.

Re: Case-only renames

[Ryan Schmidt]

On Oct 21, 2011, at 04:18, Stefan Sperling wrote:

> Sounds like it's worth filing an issue with the APR folks about this 
> if there isn't one already.

I couldn't find one so I filed this:

https://issues.apache.org/bugzilla/show_bug.cgi?id=52068

Re: Local repository move

[Ryan Schmidt]

On Oct 21, 2011, at 04:03, White, David (KWI C54) wrote:

> I suppose if I can't get the relocate to work, I  could dump the repository 
> and reload it into the new one.  

"relocate" has nothing to do with your repositories and everything to do with 
your working copies. You don't need to dump and load your repositories; it will 
have no effect on this problem. At worst, you just need to check out new 
working copies (though it should be possible to relocate the old ones, as 
you've been trying to do).

why does my SVN client process die an hour after completion of commit?

[Jon Nicoll]

Hi all
(This question is a combination of an SVN and a linux question)

I am running andLinux (a linux distribution which co-exists with Windows 7) on 
a PC and have a project with a large number (several tens of thousands) of 
files which I wanted to put under SVN.

I have an SVN server running over http, created a repo, and performed an 
initial commit of the files via an 'in-place commit' process:

cd ~/myproj
svn co http://revisioncontrol/svn/myproj/trunk .
svn add mylargesubdir
time svn ci

 This process took a long time (close to seven hours). At the end I got this 
prompt on my client console:

. . . . . Killed

(ie. many dots, over a period of hours, as the data was transmitted, followed 
by a message that my process had been killed.)

The server log seems to indicate that the commit completed successfully at time 
~9:48pm; there are no error messages .

If I look in /var/log/messages on my client machine, I see this:
{{{
Oct 20 21:00:48 andLinux -- MARK --
Oct 20 21:20:48 andLinux -- MARK --
Oct 20 21:40:48 andLinux -- MARK --
Oct 20 22:00:49 andLinux -- MARK --
Oct 20 22:21:09 andLinux -- MARK --
Oct 20 22:41:37 andLinux -- MARK --
Oct 20 22:43:23 andLinux kernel: kded4 invoked oom-killer: gfp_mask=0x201d2, 
order=0, oomkilladj=0
Oct 20 22:43:23 andLinux kernel: dd invoked oom-killer: gfp_mask=0x200d2, 
order=0, oomkilladj=0
Oct 20 22:43:23 andLinux kernel:  [] show_trace_log_lvl+0x1a/0x30
Oct 20 22:43:23 andLinux kernel:  [] show_trace+0x12/0x20
Oct 20 22:43:23 andLinux kernel:  [] dump_stack+0x15/0x20
Oct 20 22:43:23 andLinux kernel:  [] out_of_memory+0x19d/0x200
Oct 20 22:43:23 andLinux kernel:  [] __alloc_pages+0x2da/0x330
Oct 20 22:43:23 andLinux kernel:  [] read_swap_cache_async+0xa1/0xe0
Oct 20 22:43:23 andLinux kernel:  [] swapin_readahead+0x55/0x70
Oct 20 22:43:23 andLinux kernel:  [] __handle_mm_fault+0x82e/0xa00
Oct 20 22:43:23 andLinux kernel:  [] do_page_fault+0x351/0x690
Oct 20 22:43:23 andLinux kernel:  [] error_code+0x6a/0x70
Oct 20 22:43:23 andLinux kernel:  [] kmsg_read+0x25/0x50
Oct 20 22:43:23 andLinux kernel:  [] vfs_read+0xb5/0x140
Oct 20 22:43:23 andLinux kernel:  [] sys_read+0x3d/0x70
Oct 20 22:43:23 andLinux kernel:  [] syscall_call+0x7/0xb
Oct 20 22:43:23 andLinux kernel:  ===
Oct 20 22:43:23 andLinux kernel: Mem-info:
Oct 20 22:43:23 andLinux kernel: Normal per-cpu:
Oct 20 22:43:23 andLinux kernel: CPU0: Hot: hi:   90, btch:  15 usd:   5   
Cold: hi:   30, btch:   7 usd:   6
Oct 20 22:43:23 andLinux kernel: Active:30295 inactive:30529 dirty:0 
writeback:0 unstable:0
Oct 20 22:43:23 andLinux kernel:  free:509 slab:1850 mapped:42 pagetables:315 
bounce:0
Oct 20 22:43:23 andLinux kernel: Normal free:2036kB min:2036kB low:2544kB 
high:3052kB active:121180kB inactive:122116kB present:260096kB 
pages_scanned:407510 all_unreclaimable? yes
Oct 20 22:43:23 andLinux kernel: lowmem_reserve[]: 0
Oct 20 22:43:23 andLinux kernel: Normal: 11*4kB 3*8kB 1*16kB 1*32kB 0*64kB 
1*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 2036kB
Oct 20 22:43:23 andLinux kernel: Swap cache: add 1043236, delete 1043236, find 
25790/146554, race 0+0
Oct 20 22:43:23 andLinux kernel: Free swap  = 0kB
Oct 20 22:43:23 andLinux kernel: Total swap = 262120kB
Oct 20 22:43:23 andLinux kernel: Free swap:0kB
Oct 20 22:43:23 andLinux kernel: 65536 pages of RAM
Oct 20 22:43:23 andLinux kernel: 0 pages of HIGHMEM
Oct 20 22:43:23 andLinux kernel: 1542 reserved pages
Oct 20 22:43:23 andLinux kernel: 117 pages shared
Oct 20 22:43:23 andLinux kernel: 0 pages swap cached
Oct 20 22:43:23 andLinux kernel: 0 pages dirty
Oct 20 22:43:23 andLinux kernel: 0 pages writeback
Oct 20 22:43:23 andLinux kernel: 42 pages mapped
Oct 20 22:43:23 andLinux kernel: 1850 pages slab
Oct 20 22:43:23 andLinux kernel: 315 pages pagetables
# etc.
}}}

'oom-killer' is the Linux Out Of Memory killer. So, it looks like the kernel on 
my client machine killed the SVN process at around 10:43pm.

Clearly there may be an issue with the memory available on my client machine, 
and I need to look into this. But my question is related to the timings 
indicated here.

- The server says the process completed successfully at ~9:48pm
- my client svn process was killed at ~10:43pm.
- There were no other tasks running on the client that might have caused 
problems AFAIK (I left it on running just the checkin overnight)

So, my question is: is there something in the 'svn commit' protocol which 
causes the client process to do a lot of work, potentially causing the client 
machine to run out of memory, up to one hour after the server has determined 
that a checkin is complete?

If nothing else I'd like to learn a bit more about the svn/http protocol, and 
what is going on here. Thanks for any pointers.

jon N


 Please consider the environment before printing this email

The information transmitted is intended only for 

RE: why does my SVN client process die an hour after completion of commit?

[Dominik Psenner]

>If I look in /var/log/messages on my client machine, I see this:
>{{{
>Oct 20 21:00:48 andLinux -- MARK --
>Oct 20 21:20:48 andLinux -- MARK --
>Oct 20 21:40:48 andLinux -- MARK --
>Oct 20 22:00:49 andLinux -- MARK --
>Oct 20 22:21:09 andLinux -- MARK --
>Oct 20 22:41:37 andLinux -- MARK --
>Oct 20 22:43:23 andLinux kernel: kded4 invoked oom-killer:
>gfp_mask=0x201d2, order=0, oomkilladj=0
>Oct 20 22:43:23 andLinux kernel: dd invoked oom-killer: gfp_mask=0x200d2,
>order=0, oomkilladj=0
>Oct 20 22:43:23 andLinux kernel:  [] show_trace_log_lvl+0x1a/0x30
>Oct 20 22:43:23 andLinux kernel:  [] show_trace+0x12/0x20
>Oct 20 22:43:23 andLinux kernel:  [] dump_stack+0x15/0x20
>Oct 20 22:43:23 andLinux kernel:  [] out_of_memory+0x19d/0x200
>Oct 20 22:43:23 andLinux kernel:  [] __alloc_pages+0x2da/0x330
>Oct 20 22:43:23 andLinux kernel:  []
>read_swap_cache_async+0xa1/0xe0
>Oct 20 22:43:23 andLinux kernel:  [] swapin_readahead+0x55/0x70
>Oct 20 22:43:23 andLinux kernel:  []
>__handle_mm_fault+0x82e/0xa00
>Oct 20 22:43:23 andLinux kernel:  [] do_page_fault+0x351/0x690
>Oct 20 22:43:23 andLinux kernel:  [] error_code+0x6a/0x70
>Oct 20 22:43:23 andLinux kernel:  [] kmsg_read+0x25/0x50
>Oct 20 22:43:23 andLinux kernel:  [] vfs_read+0xb5/0x140
>Oct 20 22:43:23 andLinux kernel:  [] sys_read+0x3d/0x70
>Oct 20 22:43:23 andLinux kernel:  [] syscall_call+0x7/0xb
>Oct 20 22:43:23 andLinux kernel:  ===
>Oct 20 22:43:23 andLinux kernel: Mem-info:
>Oct 20 22:43:23 andLinux kernel: Normal per-cpu:
>Oct 20 22:43:23 andLinux kernel: CPU    0: Hot: hi:   90, btch:  15 usd:  
>5   Cold: hi:   30, btch:   7 usd:   6
>Oct 20 22:43:23 andLinux kernel: Active:30295 inactive:30529 dirty:0
>writeback:0 unstable:0
>Oct 20 22:43:23 andLinux kernel:  free:509 slab:1850 mapped:42
>pagetables:315 bounce:0
>Oct 20 22:43:23 andLinux kernel: Normal free:2036kB min:2036kB low:2544kB 
>high:3052kB active:121180kB inactive:122116kB present:260096kB 

Is this a virtual machine? 260096kB of RAM was probably not enough.
Therefore it used a lot of swap memory, which explains why the process took
so long.

>pages_scanned:407510 all_unreclaimable? yes
>Oct 20 22:43:23 andLinux kernel: lowmem_reserve[]: 0
>Oct 20 22:43:23 andLinux kernel: Normal: 11*4kB 3*8kB 1*16kB 1*32kB 0*64kB
>1*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 2036kB
>Oct 20 22:43:23 andLinux kernel: Swap cache: add 1043236, delete 1043236,
>find 25790/146554, race 0+0
>Oct 20 22:43:23 andLinux kernel: Free swap  = 0kB

*ouch* Looks like you've had no swap left, either. Probably you ran out of
memory during the commit and the process was killed by the kernel when the
process tried to allocate even more.

Cheers

Re: why does my SVN client process die an hour after completion of commit?

[Stefan Sperling]

On Fri, Oct 21, 2011 at 10:34:52AM +0100, Jon Nicoll wrote:
> So, my question is: is there something in the 'svn commit' protocol
> which causes the client process to do a lot of work, potentially
> causing the client machine to run out of memory, up to one hour after
> the server has determined that a checkin is complete?

This is a known issue in Subversion 1.6.
Adding many files in one commit uses too much memory, see:
http://subversion.tigris.org/issues/show_bug.cgi?id=1964#desc12

As a workaround, use 'svn import', or upgrade to Subversion 1.7.

Re: why does my SVN client process die an hour after completion of commit?

[Philip Martin]

Stefan Sperling  writes:

> On Fri, Oct 21, 2011 at 10:34:52AM +0100, Jon Nicoll wrote:
>> So, my question is: is there something in the 'svn commit' protocol
>> which causes the client process to do a lot of work, potentially
>> causing the client machine to run out of memory, up to one hour after
>> the server has determined that a checkin is complete?
>
> This is a known issue in Subversion 1.6.
> Adding many files in one commit uses too much memory, see:
> http://subversion.tigris.org/issues/show_bug.cgi?id=1964#desc12

The reason it happens after a commit is complete on the server is that
the client has to modify the metadata for all the items in the working
copy that were committed.  When the commit starts the items being
committed all have local modifications of some kind, when the commit is
complete they must all be change to unmodified.  This can involve a lot
of work, writing pristine text and properties, updating the revision
numbers.  This updating cannot happen until the client knows that the
commit was successful.

-- 
Philip

RE: why does my SVN client process die an hour after completion of commit?

[Jon Nicoll]

Hi Stefan, Philip

Thanks for your postings:

> On Fri, Oct 21, 2011 at 10:34:52AM +0100, Jon Nicoll wrote:
>> So, my question is: is there something in the 'svn commit' protocol
>> which causes the client process to do a lot of work, potentially
>> causing the client machine to run out of memory, up to one hour after
>> the server has determined that a checkin is complete?
>
> This is a known issue in Subversion 1.6.
> Adding many files in one commit uses too much memory, see:
> http://subversion.tigris.org/issues/show_bug.cgi?id=1964#desc12

The reason it happens after a commit is complete on the server is that the 
client has to modify the metadata for all the items in the working copy that 
were committed.  When the commit starts the items being committed all have 
local modifications of some kind, when the commit is complete they must all be 
change to unmodified.  This can involve a lot of work, writing pristine text 
and properties, updating the revision numbers.  This updating cannot happen 
until the client knows that the commit was successful.



Ah, that makes sense, thanks.

So for now I would be best off to regard my 'initial working directory' as 
suspect, and if I checkout from the server into a new directory, that directory 
should be correct, yes?

(this commit of a large number of files is not something I will have do very 
often, if at all, after this initial commit).

I'm using SVN client v.1.5.4 BTW - a bit older that I expected. I will also 
look into getting this updated to 1.7.

Thanks & Regards
Jon N




 Please consider the environment before printing this email

The information transmitted is intended only for the person or entity to which 
it is addressed and may contain confidential and/or privileged material. Any 
review, retransmission, dissemination or other use of, or taking of any action 
in reliance upon, this information by persons or entities other than the 
intended recipient is prohibited.

If you received this in error, please contact the sender or postmaster 
(postmas...@hanoverdisplays.com) and delete the material from any computer.

Although we routinely screen for viruses, addressees should check this e-mail 
and any attachment for viruses. We make no warranty as to absence of viruses in 
this e-mail or any attachments.

Our Company's email policy is to permit incidental personal use. If this email 
is of a personal nature, it must not be relied upon as expressing the views or 
opinions of the company.

Re: why does my SVN client process die an hour after completion of commit?

[Philip Martin]

Jon Nicoll  writes:

> So for now I would be best off to regard my 'initial working
> directory' as suspect, and if I checkout from the server into a new
> directory, that directory should be correct, yes?

You will probably need to run cleanup on the old working copy to remove
locks but it should be OK.  Items that have been not been updated to
commited revision will get pulled from the server on the next update.

-- 
Philip

Error message -

[Stewart MacKenzie]

---
Subversion Exception!
---


In file
 
'D:\Development\SVN\Releases\TortoiseSVN-1.7.0\ext\subversion\subversion\libsvn_wc\workqueue.c'
 line 672: assertion failed (checksum != NULL)
---
OK
---

There are plenty of refs to this error on the internet, but I can't find 
any resolutions.




Disclaimer:  This email and any attachments are confidential and are for the 
use of the addressee(s) only.  If you have received this e-mail in error please 
inform the sender and delete it from your mailbox.  Infotel Solutions cannot 
accept liability for any statements made which are clearly the senders own and 
not expressly made on behalf of Infotel Solutions. This message has been 
checked for all known viruses and is delivered through Barracuda Spam Firewall.

subversion exception

[Michail Shmundeac]

Hi

---
Subversion Exception!
---
Subversion encountered a serious problem.
Please take the time to report this on the Subversion mailing list
(users@subversion.apache.org)
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.0\ext\subversion\subversion\lib
svn_wc\workqueue.c'
 line 672: assertion failed (checksum != NULL)
---
OK   
---

--
WBR,
Michail "bLizzard" Shmundeac 

RE: Merge strategies?

[Bob Archer]

> On 21.10.2011 1:56, Bob Archer wrote:
> >> 1) Do you usually merge upstream or downstream?
> >> 2) Do you set mergeinfo when merging downstream?
> >> 3) Do you set mergeinfo when merging upstream?
> >> 4) Do you set mergeinfo when merging from feature branch?
> >>
> >
> > 1) We generally only merge up version. A fix is made in the earliest version
> path where we are going to release it and then merged up to the newer
> versions. There may be a case where we made a change in a version and
> needed it in the old version. I'm not sure that happened yet. I assume if it 
> is
> ever don I would do a record-only merge of the rev in the next version's path
> so it won't conflict in future merges.
> >
> > 2, 3 and 4) We always use mergeinfo. (svn sets it automatically)
> >
> > BOb
> 
> Hm, it looks like you should have really huge svn:mergeinfo in your latest
> VersionX. Did you notice any slowdown?

I'm not sure I would call it huge. Here is the mergeinfo on our newest in dev  
version path root:

/Product/branches/B_01490:39129-39612
/Product/branches/v6.0.0.1:3913-4250
/Product/branches/v6.0.1-BOD:29569-30097
/Product/branches/v6.5.1 B-06016 and B-06017:38413-38505
/Product/branches/v6.5.2:39097-39128
/Product/trunk:39633-40031
/Product/v6.5.1:40032-42329
/Product/v6.5.2:40827-45486
/Product/v6.5.3:42165-45488
/Product/v6.5.4:44500-46506
/Product/v7.0.1:45519-46535
/Product/v7.0.2:46560-47506
/Product/v7.1.0:47440-48031

(of course product isn't actually the product name)

Keep in mind... whenever you merge the merge info is updated. The high number 
of the range is changed rather than a new line being added. So each merge line 
there from say 7.1.0 represents multiple merges (I think three at this point). 
This also includes some merge info from back when we still used trunk and 
release branches. As you see we do very few feature branches.

No, I don't notice any slowdown.

> Also, as you usually merge upstream, I presume you could encounter
> svn:mergeinfo conflict when 2 users merge i.e. into latest VersionX
> simultaneously. Has it ever happened to you?

No, we have a weekly task to merge and usually one person does it. However, I 
don't see how there could be a conflict since it would be caught as a conflict 
at commit time if two people tried to commit the same merge.


>  From what I read, I see you use mergeinfo to prevent accidental cyclic
> merges. Do you use it for something else? So far I don't understand how the
> mergeinfo about upstream merges could be really useful.

No, our merge policy is to prevent cyclic merges not the mergeinfo. The 
mergeinfo is used for exactly what it is meant for. To keep track of previous 
merges so they won't be duplicated. Prior to merginfo (was it added in 1.5 I 
guess?) we had to record that info in our commit message and find it when the 
next merge was done. Now svn does that record keeping for us.


> Thank you for your valuable comments,
> Andrey Paramonov

Hope it helps,
BOb

Re: Upgrade to svn 1.7 on cygwin causes W155007 not a working copy?

[Mark Phippard]

On Tue, Oct 18, 2011 at 9:40 PM, Mark Utting  wrote:
> Summary:
> It seems that the new top-level .svn directory spontaneously disappears
> sometimes?
> Which leaves me with a useless working copy...
>
>
> Details:
> I updated my Cygwin installation recently, which (unexpectedly) gave me an
> upgrade to svn 1.7.
> This is on a Windows 7 64-bit Dell Latitude E6520.
> $ svn --version
> svn, version 1.7.0 (r1176462)
>    compiled Oct 11 2011, 10:36:16
>
> Since svn 1.7 was incompatible with my existing working copy, I did 'svn
> upgrade' in my top-level directory, which contains several projects from
> different SVN repositories.  It removed all the .svn directories in most of
> those subdirectories (all the ones that belonged to my main SVN repository),
> but then failed to create a top-level .svn directory!
>
> This made my working copy useless.  But I thought maybe this 'bug' happened
> because there were working copies from multiple repositories within that
> directory (which is a convenient way to work, with Eclipse).  So I decided
> to do something simpler to see if I could work around this bug.
>
> So I did a fresh svn checkout into a new directory, which worked fine.
> (Except that Eclipse could not read the new-style working copy, and gave
> several warnings about this, so I eventually upgraded its subclipse plugin
> as well, to version 1.8.0 using the "JavaHL (JNI) 1.7.0 (r1176462)" client).
>
> After working normally for that day, the next day I got the same error:
>
>     svn: warning: W155007: '/cygdrive/c/marku/qut/networkmodel' is not a
> working copy
>
> Once again, the top-level .svn folder had completely disappeared!  Leaving
> my working copy useless.
> Note that that 'networkmodel' directory was a fresh checkout with svn 1.7,
> so contains only projects from one repository (which is a svn 1.6 repository
> I think).
>
> I did a full system disk scan for disk errors, no problems reported.
>
>
>
> Has anyone else had problems like this since upgrading to svn 1.7?
>
> Is it possible that the Eclipse plugin is deleting the top-level .svn
> directory?


It is definitely suspicious.  Generally Subclipse does not directly
touch the .svn folders at all.  It only makes calls to the JavaHL API
which is just a bridge to the normal SVN API provided in the SVN
DLL's.  Cygwin seems to be a relevant wrinkle, but I do not see why
TortoiseSVN would not have problems.  I am not aware of any special
handling for Cygwin that it includes.

-- 
Thanks

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

Re: Merge strategies?

[Andrey Paramonov]

On 21.10.2011 17:32, Bob Archer wrote:

Hm, it looks like you should have really huge svn:mergeinfo in your latest
VersionX. Did you notice any slowdown?


I'm not sure I would call it huge. Here is the mergeinfo on our newest in dev  
version path root:

/Product/branches/B_01490:39129-39612
/Product/branches/v6.0.0.1:3913-4250
/Product/branches/v6.0.1-BOD:29569-30097
/Product/branches/v6.5.1 B-06016 and B-06017:38413-38505
/Product/branches/v6.5.2:39097-39128
/Product/trunk:39633-40031
/Product/v6.5.1:40032-42329
/Product/v6.5.2:40827-45486
/Product/v6.5.3:42165-45488
/Product/v6.5.4:44500-46506
/Product/v7.0.1:45519-46535
/Product/v7.0.2:46560-47506
/Product/v7.1.0:47440-48031

(of course product isn't actually the product name)

Keep in mind... whenever you merge the merge info is updated. The high number 
of the range is changed rather than a new line being added. So each merge line 
there from say 7.1.0 represents multiple merges (I think three at this point). 
This also includes some merge info from back when we still used trunk and 
release branches. As you see we do very few feature branches.

No, I don't notice any slowdown.


Also, as you usually merge upstream, I presume you could encounter
svn:mergeinfo conflict when 2 users merge i.e. into latest VersionX
simultaneously. Has it ever happened to you?


No, we have a weekly task to merge and usually one person does it. However, I 
don't see how there could be a conflict since it would be caught as a conflict 
at commit time if two people tried to commit the same merge.


Yes, I'd like to avoid this "conflict at commit time". Such things tend 
to confuse users big time.



   From what I read, I see you use mergeinfo to prevent accidental cyclic
merges. Do you use it for something else? So far I don't understand how the
mergeinfo about upstream merges could be really useful.


No, our merge policy is to prevent cyclic merges not the mergeinfo. The 
mergeinfo is used for exactly what it is meant for. To keep track of previous 
merges so they won't be duplicated. Prior to merginfo (was it added in 1.5 I 
guess?) we had to record that info in our commit message and find it when the 
next merge was done. Now svn does that record keeping for us.



Ah, I now see that you basically merge everything, not cherry-pick. It 
makes sense for your setup. I now see that we could also do this (in 
rather rare cases when we merge upstream) if we have mergeinfo filled 
for our release branches.


Thank you for sharing your experience,
Andrey Paramonov

Re: Upgrade to svn 1.7 on cygwin causes W155007 not a working copy?

[Mark Phippard]

Can you make a little diagram of what your Eclipse workspace looks
like?  For example, one of mine looks like this:

/workspace
 |- Project1
 |-|-.svn
 |- Project2
 |-|-.svn


And I have others where my Eclipse workspace folder is empty:

/workspace

Because all of my Eclipse projects are imported into the workspace and
just pointing to working copies I have checked out elsewhere.  For
example. on my Mac I have Subclipse checked out here:

$HOME/work/subclipse

This contains a /trunk/plugins folder with a child folder for each
Eclipse plugin project.

My Eclipse workspace lives at:

$HOME/Documents/workspaces/e3.7

The workspace folder is empty other than the Eclipse .metadata folder.
 This contains the pointers to all the projects I have imported.

In other cases, I do my checkouts directly from Eclipse which leave my
with a workspace that looks like the first example.

How would you describe your working copy?

svn dump failure with bad revison

[Stefan Lock]

Hi,
we are using  subversion 1.6.11 (r934486) with FSFS database on  
CentOS  and i get the following error while using svnadmin dump:


* Dumped revision 8233.
svnadmin: File not found: revision 8234, path

Some times ago, we committed a file with an bad filename. I think we  
used a blank or other special characters. Afterwards we deleted this  
file so we created exactly one revision with this bad file.
Now, we are not able to dump this Repository because we get an "file  
not found!" error for that revision while dumping.


As I read in the FAQ:
http:subversion.apache.org/faq.html#removal
It´s planned to delete  revisions out of a repository but still not  
implemented and I have to pipe my dumpfile into the svndumpfilter


So I tried:
svnadmin dump REPO/ | svndumpfilter exclude revision 8234 > exclude.dump
but still get

svnadmin: File not found: revision 8234, path.

As i´m not used to the svndumpfilter I tried different syntax (just  
8234, the path ) all with the same failure. Unfortunately the man page  
is not very helpful.


After this I tried:

svnadmin dump REPO/ 0:8233 > inkr.dump

to append the rest with a incremental dump using  >>.
But I´m wondering cause get the same failure:

* Dumped revision 8233.
svnadmin: File not found: revision 8234, path '/PATH'

Does anybody know how to dump a repository excluding exactly one  
revision or perhaps anybody has an other idea solving this problem.


Thanks,
Stefan

(-) Stefan Lock
(-) SIGNAL 7 Gesellschaft für Informationstechnologie mbH
(-) Pallaswiesenstraße 174 - 64293 Darmstadt,
(-) Tel: +49 (0) 6151 969 96 17, Fax: +49 (0) 6151 969 96 29
(-) mailto:l...@signal7.de, www.signal7.de
(-) Amtsgericht Darmstadt, HRB 6833
(-) Geschäftsführer: Robert Krüger, Frank Peters, Jochen Strunk

Why Subversion 1.7.1 tagged but not announced?

[Ludovic Lambert]

Hi,

Has anybody a clue on why SVN 1.7.1 has been tagged in the repo but not
announced as available?
According to the release note it contains many improvements and bug fixes,
teasing me for an upgrade...

Regards,
Ludovic

RE: Merge strategies?

[Bob Archer]

> On 21.10.2011 17:32, Bob Archer wrote:
> >> Hm, it looks like you should have really huge svn:mergeinfo in your
> >> latest VersionX. Did you notice any slowdown?
> >
> > I'm not sure I would call it huge. Here is the mergeinfo on our newest in
> dev  version path root:
> >
> > /Product/branches/B_01490:39129-39612
> > /Product/branches/v6.0.0.1:3913-4250
> > /Product/branches/v6.0.1-BOD:29569-30097
> > /Product/branches/v6.5.1 B-06016 and B-06017:38413-38505
> > /Product/branches/v6.5.2:39097-39128
> > /Product/trunk:39633-40031
> > /Product/v6.5.1:40032-42329
> > /Product/v6.5.2:40827-45486
> > /Product/v6.5.3:42165-45488
> > /Product/v6.5.4:44500-46506
> > /Product/v7.0.1:45519-46535
> > /Product/v7.0.2:46560-47506
> > /Product/v7.1.0:47440-48031
> >
> > (of course product isn't actually the product name)
> >
> > Keep in mind... whenever you merge the merge info is updated. The high
> number of the range is changed rather than a new line being added. So each
> merge line there from say 7.1.0 represents multiple merges (I think three at
> this point). This also includes some merge info from back when we still used
> trunk and release branches. As you see we do very few feature branches.
> >
> > No, I don't notice any slowdown.
> >
> >> Also, as you usually merge upstream, I presume you could encounter
> >> svn:mergeinfo conflict when 2 users merge i.e. into latest VersionX
> >> simultaneously. Has it ever happened to you?
> >
> > No, we have a weekly task to merge and usually one person does it.
> However, I don't see how there could be a conflict since it would be caught
> as a conflict at commit time if two people tried to commit the same merge.
> 
> Yes, I'd like to avoid this "conflict at commit time". Such things tend to
> confuse users big time.

This strikes me as a training issue. Even on an update there is a possibility 
that a merge conflict will occur. Your users need to understand them and know 
how to deal with them for them to effectively use the system. 

BOb

> 
> >>From what I read, I see you use mergeinfo to prevent accidental
> >> cyclic merges. Do you use it for something else? So far I don't
> >> understand how the mergeinfo about upstream merges could be really
> useful.
> >
> > No, our merge policy is to prevent cyclic merges not the mergeinfo. The
> mergeinfo is used for exactly what it is meant for. To keep track of previous
> merges so they won't be duplicated. Prior to merginfo (was it added in 1.5 I
> guess?) we had to record that info in our commit message and find it when
> the next merge was done. Now svn does that record keeping for us.
> >
> 
> Ah, I now see that you basically merge everything, not cherry-pick. It makes
> sense for your setup. I now see that we could also do this (in rather rare
> cases when we merge upstream) if we have mergeinfo filled for our release
> branches.
> 
> Thank you for sharing your experience,
> Andrey Paramonov

RE: Why Subversion 1.7.1 tagged but not announced?

[Bob Archer]

> Has anybody a clue on why SVN 1.7.1 has been tagged in the repo but not
> announced as available?
> According to the release note it contains many improvements and bug fixes,
> teasing me for an upgrade...
> 
> Regards,
> Ludovic

Because it is going through the approval and signing process (follow the dev 
list). I expect it will be released pretty soon.

BOb

ra_serf error 400 over http

[Dextraze, Nicolas]

Should I report this problem or it is already known?

I got this error while trying to update v8 using ra_serf :

svn: E175002: GET request failed: 400 Bad Request

Url: http://v8.googlecode.com/svn/trunk

Firewall: Microsoft ForeFront 2010

Thanks,




[Groupe PCMS]

Nicolas Dextraze
Analyste-Programmeur

514 931-3324 poste 228

Re: mergeinfo marked not inheritable on sparse checkout

[Douglas Wilson]

On Oct 21, 2:10 am, Stefan Sperling  wrote:
> On Thu, Oct 20, 2011 at 02:02:48PM -0700, Douglas Wilson wrote:
>
> > On Oct 20, 10:45 am, Stefan Sperling  wrote:
>
> Does that make sense?
Yes, I get that.

I was using Tortoise, but retested with command line SVN:

C:\SVN\Test>svn merge -r 3:4 --dry-run file:///C:/SVN/TestRepo/trunk .
--- Merging r4 into 'Dir1':
UDir1\file1.txt

C:\SVN\Test>svn merge -r 3:4  file:///C:/SVN/TestRepo/trunk .
--- Merging r4 into 'Dir1':
UDir1\file1.txt
--- Recording mergeinfo for merge of r4 into '.':
 U   .
--- Recording mergeinfo for merge of r4 into 'Dir1':
 U   Dir1

C:\SVN\Test>svn diff
Index: .
===
--- .   (revision 4)
+++ .   (working copy)

Property changes on: .
___
Added: svn:mergeinfo
   Merged /trunk:r4*
Index: Dir1
===
--- Dir1(revision 4)
+++ Dir1(working copy)

Property changes on: Dir1
___
Added: svn:mergeinfo
   Merged /trunk/Dir1:r4
Index: Dir1/file1.txt
===
--- Dir1/file1.txt  (revision 4)
+++ Dir1/file1.txt  (working copy)
@@ -0,0 +1 @@
+New stuff

C:\SVN\Test>svn log -r 4 -v file:///C:/SVN/TestRepo

r4 | dwilson | 2011-10-20 15:07:07 -0700 (Thu, 20 Oct 2011) | 1 line
Changed paths:
   M /trunk/Dir1/file1.txt

Commit trunk changes

Re: ra_serf error 400 over http

[Andy Levy]

On Fri, Oct 21, 2011 at 13:37, Dextraze, Nicolas  wrote:
> Should I report this problem or it is already known?
>
> I got this error while trying to update v8 using ra_serf :
>
> svn: E175002: GET request failed: 400 Bad Request
>
> Url: http://v8.googlecode.com/svn/trunk
>
> Firewall: Microsoft ForeFront 2010

OS? Subversion version? Have you tried ra_neon? Could your firewall be
interfering with the request? It's impossible to say if it's an
"already known" problem with so few details provided.

Error when updating

[Wabe W]

Hello,

When I click SVN update I get an error message (see below).
When I first commit something (doens't matter what), I can update only the same 
folder after the commit. For all other folders the update still doesn't work. 
Once I get the error message it will pop up for all SVN folders. Until I commit 
something, again, only that folder will be available for update.

The problem arose immediately after installing SVN 1.7

Do you have a solution for this?

With kind regards,

Wabe Koelmans.

P.S. Error message:

---
Subversion Exception!
---
Subversion encountered a serious problem.
Please take the time to report this on the Subversion mailing list
(users@subversion.apache.org)
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.0\ext\subversion\subversion\libsvn_wc\wc_db.c'
 line 11039: assertion failed (base_status == svn_wc__db_status_incomplete)
---
OK   
---

  

Subversion Exception!

[Philipp Detemple]

In file
'D:\Development\SVN\Releases\TortoiseSVN-1.7.0\ext\subversion\subversion\libsvn_wc\wc_db.c'
line 9465: assertion failed (work_presence == svn_wc__db_status_normal ||
work_presence == svn_wc__db_status_not_present || work_presence ==
svn_wc__db_status_base_deleted)

Philipp Detemple   Softwareentwicklung
..
moltomedia GmbH & Co. KG
Heinrich-Barth-Straße 29   66115 Saarbrücken
Telefon 06 81 / 9 48 81 - 0   Fax 06 81 / 9 48 81 - 10
www.moltomedia.de   
detem...@moltomedia.de
Amtsgericht Saarbrücken   HRA 10719

persönlich haftende Gesellschafterin
moltomedia Geschäftsführung GmbH, Saarbrücken
Amtsgericht Saarbrücken HRB 17993
Geschäftsführer Erik Pazzi

RE : ra_serf error 400 over http

[Dextraze, Nicolas]

Sorry I forgot all those details. Here they are:

OS? 
Windows 7 64-bit

Subversion version?  
I'm using the 32-bit command line client
svn, version 1.7.0 (r1176462) compiled Oct 11 2011, 22:11:05

Have you tried ra_neon? 
yes, it works fine with ra_neon

Could your firewall be interfering with the request? 
Not supposed to and as it work with ra_neon, I doubt so. But i mentioned it 
because i thought it was relevant.

Thanks,


Nicolas Dextraze


De : Andy Levy [andy.l...@gmail.com]
Date d'envoi : 21 octobre 2011 13:45
À : Dextraze, Nicolas
Cc : users@subversion.apache.org
Objet : Re: ra_serf error 400 over http

On Fri, Oct 21, 2011 at 13:37, Dextraze, Nicolas  wrote:
> Should I report this problem or it is already known?
>
> I got this error while trying to update v8 using ra_serf :
>
> svn: E175002: GET request failed: 400 Bad Request
>
> Url: http://v8.googlecode.com/svn/trunk
>
> Firewall: Microsoft ForeFront 2010

OS? Subversion version? Have you tried ra_neon? Could your firewall be
interfering with the request? It's impossible to say if it's an
"already known" problem with so few details provided.

Assertion on updated

[Marc Strapetz]

I just got following assertion on "svn update":

Fetching external item into 'ext-normal':
...

svn: E235000: In file '..\..\..\subversion\libsvn_wc\update_editor.c'
line 1582: assertion failed (action == svn_wc_conflict_action_edit ||
action == svn_wc_conflict_action_delete || action ==
svn_wc_conflict_action_replace)



D:\svntest\small-1.7-1>svn --version
svn, version 1.7.0 (r1176462)
   compiled Oct 12 2011, 16:57:34

--
Best regards,
Marc Strapetz
=
syntevo GmbH
http://www.syntevo.com
http://blog.syntevo.com

Re: svn dump failure with bad revison

[Ryan Schmidt]

On Oct 21, 2011, at 11:04, Stefan Lock wrote:

> we are using  subversion 1.6.11 (r934486) with FSFS database on CentOS  and i 
> get the following error while using svnadmin dump:
> 
> * Dumped revision 8233.
> svnadmin: File not found: revision 8234, path
> 
> Some times ago, we committed a file with an bad filename. I think we used a 
> blank or other special characters. Afterwards we deleted this file so we 
> created exactly one revision with this bad file.
> Now, we are not able to dump this Repository because we get an "file not 
> found!" error for that revision while dumping.

That sounds like a bug in Subversion... if the file could be committed, then we 
should be able to dump or otherwise deal with it, even if the name is unusual. 
I'd recommend you try the latest version of Subversion 1.6.x and see if the 
problem persists. You could also try 1.7.0 but you may want to wait on 
upgrading important systems to that version due to other issues you can read 
about on the mailing list.


> As I read in the FAQ:
> http:subversion.apache.org/faq.html#removal
> It´s planned to delete  revisions out of a repository but still not 
> implemented and I have to pipe my dumpfile into the svndumpfilter
> 
> So I tried:
> svnadmin dump REPO/ | svndumpfilter exclude revision 8234 > exclude.dump
> but still get 
> 
> svnadmin: File not found: revision 8234, path.
> 
> As i´m not used to the svndumpfilter I tried different syntax (just 8234, the 
> path ) all with the same failure. Unfortunately the man page is not very 
> helpful.

The failure is in svnadmin dump, so the next svndumpfilter command isn't even 
getting run; it's failing before that.


> After this I tried:
> 
> svnadmin dump REPO/ 0:8233 > inkr.dump
> 
> to append the rest with a incremental dump using  >>.
> But I´m wondering cause get the same failure:
> 
> * Dumped revision 8233.
> svnadmin: File not found: revision 8234, path '/PATH'
> 
> Does anybody know how to dump a repository excluding exactly one revision or 
> perhaps anybody has an other idea solving this problem.

You got it mostly right:

$ svnadmin help dump | head -n 1
dump: usage: svnadmin dump REPOS_PATH [-r LOWER[:UPPER] [--incremental]]

You just forgot the "-r" switch before your revision range.

svnadmin dump REPO -r 0:8233 > REPO.dump
svnadmin dump REPO -r 8234:HEAD --incremental >> REPO.dump

If you don't plan to filter the dump, you can save quite a lot of space by 
using deltas:

svnadmin dump REPO -r 0:8233 --deltas > REPO.dump
svnadmin dump REPO -r 8234:HEAD --deltas --incremental >> REPO.dump

Re: Why Subversion 1.7.1 tagged but not announced?

[Erik Huelsmann]

On Fri, Oct 21, 2011 at 7:11 PM, Bob Archer  wrote:
>> Has anybody a clue on why SVN 1.7.1 has been tagged in the repo but not
>> announced as available?
>> According to the release note it contains many improvements and bug fixes,
>> teasing me for an upgrade...
>>
>> Regards,
>> Ludovic
>
> Because it is going through the approval and signing process (follow the dev 
> list). I expect it will be released pretty soon.


The status as of three hours ago is:

""
Thanks everybody for the quick turnaround on the signatures; I've put
the tarballs up for mirroring, and hope to publish the release
tomorrow.

-Hyrum
""

Bye,

Erik.