Re: Merge strategies?
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? 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? 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. Thank you for your valuable comments, Andrey Paramonov
Local repository move
This may seem like a dumb question, but I cannot find out how to do this. I have several local repositories on a WinXP machine, and I want to move them to another folder on the same machine, as part of renaming required to assist migration to Win7. 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 Can someone tell me what I need to do? Thanks, David White Principal Research Engineer | TDG Alcoa World Alumina t +61 8 9410 3402 f +61 8 9410 3197 m +61 (0) 432 877 949 Cockburn Road, Kwinana, Western Australia PO Box 161, Kwinana WA 6966 www.alcoa.com.au http://www.alcoa.com.au/ Sign up here http://www.alcoa.com/australia/en/news/community_enews/newsletter.asp to receive alcoa community e-news The contents of this e-mail and any attachments may be confidential. Any confidentiality is not waived or lost because this email has been sent to you by mistake. If you have received this e-mail in error, please notify the sender immediately, destroy any printed copies and delete the email from your computer image003.jpg
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: Case-only renames
On Fri, Oct 21, 2011 at 5:49 AM, Ryan Schmidt subversion-20...@ryandesign.com 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
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
-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: mergeinfo marked not inheritable on sparse checkout
On Thu, Oct 20, 2011 at 02:02:48PM -0700, Douglas Wilson wrote:
On Oct 20, 10:45 am, Stefan Sperling s...@elego.de 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
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
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
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
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
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?
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: [c0103b7a] show_trace_log_lvl+0x1a/0x30
Oct 20 22:43:23 andLinux kernel: [c0103cb2] show_trace+0x12/0x20
Oct 20 22:43:23 andLinux kernel: [c0104ae5] dump_stack+0x15/0x20
Oct 20 22:43:23 andLinux kernel: [c014197d] out_of_memory+0x19d/0x200
Oct 20 22:43:23 andLinux kernel: [c014319a] __alloc_pages+0x2da/0x330
Oct 20 22:43:23 andLinux kernel: [c0152b11] read_swap_cache_async+0xa1/0xe0
Oct 20 22:43:23 andLinux kernel: [c01492f5] swapin_readahead+0x55/0x70
Oct 20 22:43:23 andLinux kernel: [c014b98e] __handle_mm_fault+0x82e/0xa00
Oct 20 22:43:23 andLinux kernel: [c010b541] do_page_fault+0x351/0x690
Oct 20 22:43:23 andLinux kernel: [c02e81fa] error_code+0x6a/0x70
Oct 20 22:43:23 andLinux kernel: [c019d315] kmsg_read+0x25/0x50
Oct 20 22:43:23 andLinux kernel: [c015e105] vfs_read+0xb5/0x140
Oct 20 22:43:23 andLinux kernel: [c015e4ed] sys_read+0x3d/0x70
Oct 20 22:43:23 andLinux kernel: [c01028f2] 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
RE: why does my SVN client process die an hour after completion of commit?
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: [c0103b7a] show_trace_log_lvl+0x1a/0x30
Oct 20 22:43:23 andLinux kernel: [c0103cb2] show_trace+0x12/0x20
Oct 20 22:43:23 andLinux kernel: [c0104ae5] dump_stack+0x15/0x20
Oct 20 22:43:23 andLinux kernel: [c014197d] out_of_memory+0x19d/0x200
Oct 20 22:43:23 andLinux kernel: [c014319a] __alloc_pages+0x2da/0x330
Oct 20 22:43:23 andLinux kernel: [c0152b11]
read_swap_cache_async+0xa1/0xe0
Oct 20 22:43:23 andLinux kernel: [c01492f5] swapin_readahead+0x55/0x70
Oct 20 22:43:23 andLinux kernel: [c014b98e]
__handle_mm_fault+0x82e/0xa00
Oct 20 22:43:23 andLinux kernel: [c010b541] do_page_fault+0x351/0x690
Oct 20 22:43:23 andLinux kernel: [c02e81fa] error_code+0x6a/0x70
Oct 20 22:43:23 andLinux kernel: [c019d315] kmsg_read+0x25/0x50
Oct 20 22:43:23 andLinux kernel: [c015e105] vfs_read+0xb5/0x140
Oct 20 22:43:23 andLinux kernel: [c015e4ed] sys_read+0x3d/0x70
Oct 20 22:43:23 andLinux kernel: [c01028f2] 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?
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?
Stefan Sperling s...@elego.de 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?
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?
Jon Nicoll jnic...@hanoverdisplays.com 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 -
--- 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
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?
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?
On Tue, Oct 18, 2011 at 9:40 PM, Mark Utting ma...@cs.waikato.ac.nz 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?
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?
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
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
RE: Why Subversion 1.7.1 tagged but not announced?
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
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
On Oct 21, 2:10 am, Stefan Sperling s...@elego.de wrote: On Thu, Oct 20, 2011 at 02:02:48PM -0700, Douglas Wilson wrote: On Oct 20, 10:45 am, Stefan Sperling s...@elego.de wrote: Does that make sense? Yes, I get that. I was using Tortoise, but retested with command line SVN: C:\SVN\Testsvn merge -r 3:4 --dry-run file:///C:/SVN/TestRepo/trunk . --- Merging r4 into 'Dir1': UDir1\file1.txt C:\SVN\Testsvn 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\Testsvn 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\Testsvn 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
On Fri, Oct 21, 2011 at 13:37, Dextraze, Nicolas ndextr...@pcms.com 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
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!
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.dehttp://www.moltomedia.de detem...@moltomedia.demailto: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
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 ndextr...@pcms.com 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
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-1svn --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
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
