Re: Segmentation fault in "svn resolve"
On Tue, Jun 14, 2016 at 07:57:39PM -0300, Gustavo Chaves wrote: > I got a "segmentation fault" while performing a "svn resolve" to resolve a > conflict in a file with the svn:mime-type property set to > application/octet-stream. I got the same error using the WANdisco packages > for svn-1.9.4 at RHEL and using Ubuntu 16.04 native package for svn-1.9.3. > > I was able to reproduce the problem in a small scale following the steps > below, in my Ubuntu 16.04 machine. > > Should I open an issue? I can reproduce this problem. I will fix it. Thanks for your report!
Re: Segmentation fault in "svn resolve"
On Wed, Jun 15, 2016 at 09:33:52AM +0200, Stefan Sperling wrote:
> On Tue, Jun 14, 2016 at 07:57:39PM -0300, Gustavo Chaves wrote:
> > I got a "segmentation fault" while performing a "svn resolve" to resolve a
> > conflict in a file with the svn:mime-type property set to
> > application/octet-stream. I got the same error using the WANdisco packages
> > for svn-1.9.4 at RHEL and using Ubuntu 16.04 native package for svn-1.9.3.
> >
> > I was able to reproduce the problem in a small scale following the steps
> > below, in my Ubuntu 16.04 machine.
> >
> > Should I open an issue?
>
> I can reproduce this problem. I will fix it. Thanks for your report!
The problem here is that the working copy code wrongly assumes it can
create a merged version of the file.
I think we should fix it like this. Does this make sense?
$ svn resolve --accept mc file
svn: warning: apr_err=SVN_ERR_WC_CONFLICT_RESOLVER_FAILURE
svn: warning: W155027: Conflict on '/tmp/svn-sandbox/branch/file' cannot be
resolved to 'theirs-conflict' or 'mine-conflict' because a merged version of
the file cannot be created.
Index: subversion/libsvn_wc/conflicts.c
===
--- subversion/libsvn_wc/conflicts.c(revision 1748508)
+++ subversion/libsvn_wc/conflicts.c(working copy)
@@ -1633,6 +1633,15 @@ build_text_conflict_resolve_items(svn_skel_t **wor
? svn_diff_conflict_display_latest
: svn_diff_conflict_display_modified;
+ if (mine_abspath == NULL)
+return svn_error_createf(SVN_ERR_WC_CONFLICT_RESOLVER_FAILURE,
NULL,
+ _("Conflict on '%s' cannot be resolved to
"
+ "'theirs-conflict' or 'mine-conflict' "
+ "because a merged version of the file "
+ "cannot be created."),
+ svn_dirent_local_style(local_abspath,
+scratch_pool));
+
SVN_ERR(merge_showing_conflicts(&install_from_abspath,
db, local_abspath,
style, merge_options,
Re: Segmentation fault in "svn resolve"
On 6/15/2016 09:55, Stefan Sperling wrote:
> On Wed, Jun 15, 2016 at 09:33:52AM +0200, Stefan Sperling wrote:
>> On Tue, Jun 14, 2016 at 07:57:39PM -0300, Gustavo Chaves wrote:
>>> I got a "segmentation fault" while performing a "svn resolve" to resolve a
>>> conflict in a file with the svn:mime-type property set to
>>> application/octet-stream. I got the same error using the WANdisco packages
>>> for svn-1.9.4 at RHEL and using Ubuntu 16.04 native package for svn-1.9.3.
>>>
>>> I was able to reproduce the problem in a small scale following the steps
>>> below, in my Ubuntu 16.04 machine.
>>>
>>> Should I open an issue?
>> I can reproduce this problem. I will fix it. Thanks for your report!
> The problem here is that the working copy code wrongly assumes it can
> create a merged version of the file.
>
> I think we should fix it like this. Does this make sense?
>
> $ svn resolve --accept mc file
> svn: warning: apr_err=SVN_ERR_WC_CONFLICT_RESOLVER_FAILURE
> svn: warning: W155027: Conflict on '/tmp/svn-sandbox/branch/file' cannot be
> resolved to 'theirs-conflict' or 'mine-conflict' because a merged version of
> the file cannot be created.
>
> Index: subversion/libsvn_wc/conflicts.c
> ===
> --- subversion/libsvn_wc/conflicts.c (revision 1748508)
> +++ subversion/libsvn_wc/conflicts.c (working copy)
> @@ -1633,6 +1633,15 @@ build_text_conflict_resolve_items(svn_skel_t **wor
> ? svn_diff_conflict_display_latest
> : svn_diff_conflict_display_modified;
>
> + if (mine_abspath == NULL)
> +return svn_error_createf(SVN_ERR_WC_CONFLICT_RESOLVER_FAILURE,
> NULL,
> + _("Conflict on '%s' cannot be resolved
> to "
> + "'theirs-conflict' or 'mine-conflict'
> "
> + "because a merged version of the file
> "
> + "cannot be created."),
> + svn_dirent_local_style(local_abspath,
> +scratch_pool));
> +
>SVN_ERR(merge_showing_conflicts(&install_from_abspath,
>db, local_abspath,
>style, merge_options,
This sounds utterly familiar to me:
See this mail on the dev list: "[PATCH] error handling for
build_text_conflict_resolve_items" from 02/01/16:
http://mail-archives.apache.org/mod_mbox/subversion-dev/201602.mbox/%3C56AEA607.7030209%40posteo.de%3E
The position you add the check seems to differ slightly (I added the
mine_abspath check above the line which determines the conflict style,
but I'd be +1 (non-binding) with any of the two patches.
Regards,
Stefan
smime.p7s
Description: S/MIME Cryptographic Signature
Re: Segmentation fault in "svn resolve"
On Wed, Jun 15, 2016 at 10:13:08AM +0200, Stefan wrote: > This sounds utterly familiar to me: > > See this mail on the dev list: "[PATCH] error handling for > build_text_conflict_resolve_items" from 02/01/16: > http://mail-archives.apache.org/mod_mbox/subversion-dev/201602.mbox/%3C56AEA607.7030209%40posteo.de%3E > > The position you add the check seems to differ slightly (I added the > mine_abspath check above the line which determines the conflict style, > but I'd be +1 (non-binding) with any of the two patches. > > Regards, > Stefan Ah, I had missed that. Thanks! Too bad this fell through the cracks back in February. Please try to ping your own patches if you don't get a reply. We have a patch manager role in the community who regularly pings every patch posted, but our last patch manager has gone AWOL. http://subversion.apache.org/docs/community-guide/roles.html#patch-manager One problem with your version of this fix is that it creates a case where we run code before a variable declaration in the same block. We can't do that because we remain compatible with old compilers.
Re: Segmentation fault in "svn resolve"
On 6/15/2016 10:26 AM, Stefan Sperling wrote: On Wed, Jun 15, 2016 at 10:13:08AM +0200, Stefan wrote: This sounds utterly familiar to me: See this mail on the dev list: "[PATCH] error handling for build_text_conflict_resolve_items" from 02/01/16: http://mail-archives.apache.org/mod_mbox/subversion-dev/201602.mbox/%3C56AEA607.7030209%40posteo.de%3E The position you add the check seems to differ slightly (I added the mine_abspath check above the line which determines the conflict style, but I'd be +1 (non-binding) with any of the two patches. Regards, Stefan Ah, I had missed that. Thanks! Too bad this fell through the cracks back in February. Please try to ping your own patches if you don't get a reply. We have a patch manager role in the community who regularly pings every patch posted, but our last patch manager has gone AWOL. http://subversion.apache.org/docs/community-guide/roles.html#patch-manager I kept it on my backlog, but since I got no replies, I thought best to get a repro case demonstrating the issue and verifying the proposed fix really solves the issue (so it's verifiable). Unfortunately, I simply didn't get to that yet. So glad, you picked it up. :-) One problem with your version of this fix is that it creates a case where we run code before a variable declaration in the same block. We can't do that because we remain compatible with old compilers. Oh right. Completely overlooked that C89 violation in my patch. Nice spot. -- Regards, Stefan Hett, Developer/Administrator EGOSOFT GmbH, Heidestrasse 4, 52146 Würselen, Germany Tel: +49 2405 4239970, www.egosoft.com Geschäftsführer: Bernd Lehahn, Handelsregister Aachen HRB 13473
SVN upgrade
Hi, I am trying t compile the source code to upgrade from SVN 1.7 to 1.9.4 but I am getting the below error. Could you please send the steps for upgrading since I couldn't find any good document in web ? I am trying to follow the steps mentioned in http://svn.apache.org/repos/asf/subversion/trunk/INSTALL . And I want to upgrade in Linux [USER@server subversion-1.9.4]$ sh autogen.sh : command not found: : command not found: : command not found: ': not a valid identifiert: `CDPATH : command not found: 'utogen.sh: line 35: syntax error near unexpected token `in 'utogen.sh: line 35: ` case "$1" in ___ This email is intended only for the use of the individual(s) to whom it is addressed and may be privileged and confidential. Unauthorised use or disclosure is prohibited. If you receive This e-mail in error, please advise immediately and delete the original message. This message may have been altered without your or our knowledge and the sender does not accept any liability for any errors or omissions in the message. Ce courriel est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courriel par erreur, veuillez m'en aviser immédiatement, par retour de courriel ou par un autre moyen.
Re: SVN upgrade
On 6/15/2016 1:50 PM, Somashekarappa, Anup (CWM-NR) wrote: Hi, I am trying t compile the source code to upgrade from SVN 1.7 to 1.9.4 but I am getting the below error. Could you please send the steps for upgrading since I couldn’t find any good document in web ? I am trying to follow the steps mentioned in _http://svn.apache.org/repos/asf/subversion/trunk/INSTALL_ . And I want to upgrade in Linux [USER@server subversion-1.9.4]$ sh autogen.sh : command not found: : command not found: : command not found: ': not a valid identifiert: `CDPATH : command not found: 'utogen.sh: line 35: syntax error near unexpected token `in 'utogen.sh: line 35: ` case "$1" in Given the output you have here, I take it you downloaded the source as a tarball instead of getting it directly form the repository. In this case, please follow the instructions in INSTALL under II.A instead II.B. I.e. run ./configure make make install -- Regards, Stefan Hett
RE: SVN upgrade
Hello, Thank you for your quick response. I am able to proceed further but stuck at [USER@server subversion-1.9.4]$ make install /usr/bin/install -c -d /usr/local/lib /usr/local/share/pkgconfig /usr/bin/install: cannot change permissions of `/usr/local/share/pkgconfig': No such file or directory make: *** [install-fsmod-lib] Error 1 From: Stefan Hett [mailto:ste...@egosoft.com] Sent: 2016, June, 15 8:04 AM To: users@subversion.apache.org Subject: Re: SVN upgrade On 6/15/2016 1:50 PM, Somashekarappa, Anup (CWM-NR) wrote: Hi, I am trying t compile the source code to upgrade from SVN 1.7 to 1.9.4 but I am getting the below error. Could you please send the steps for upgrading since I couldn’t find any good document in web ? I am trying to follow the steps mentioned in http://svn.apache.org/repos/asf/subversion/trunk/INSTALL . And I want to upgrade in Linux [USER@server subversion-1.9.4]$ sh autogen.sh : command not found: : command not found: : command not found: ': not a valid identifiert: `CDPATH : command not found: 'utogen.sh: line 35: syntax error near unexpected token `in 'utogen.sh: line 35: ` case "$1" in Given the output you have here, I take it you downloaded the source as a tarball instead of getting it directly form the repository. In this case, please follow the instructions in INSTALL under II.A instead II.B. I.e. run ./configure make make install -- Regards, Stefan Hett ___ This email is intended only for the use of the individual(s) to whom it is addressed and may be privileged and confidential. Unauthorised use or disclosure is prohibited. If you receive This e-mail in error, please advise immediately and delete the original message. This message may have been altered without your or our knowledge and the sender does not accept any liability for any errors or omissions in the message. Ce courriel est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courriel par erreur, veuillez m'en aviser immédiatement, par retour de courriel ou par un autre moyen.
Re: SVN upgrade
Hi, Hello, Thank you for your quick response. I am able to proceed further but stuck at [USER@server subversion-1.9.4]$ make install /usr/bin/install -c -d /usr/local/lib /usr/local/share/pkgconfig /usr/bin/install: cannot change permissions of `/usr/local/share/pkgconfig': No such file or directory make: *** [install-fsmod-lib] Error 1 I take it you already troubleshooted the issue yourself and ruled out the obvious candidates like missing pkgconfig, missing permissions, and everything else google would point out in the first few links when searching the web for that error message, right? If so, knowing your linux distribution would be useful. *From:*Stefan Hett [mailto:ste...@egosoft.com] *Sent:* 2016, June, 15 8:04 AM *To:* users@subversion.apache.org *Subject:* Re: SVN upgrade On 6/15/2016 1:50 PM, Somashekarappa, Anup (CWM-NR) wrote: Hi, I am trying t compile the source code to upgrade from SVN 1.7 to 1.9.4 but I am getting the below error. Could you please send the steps for upgrading since I couldn’t find any good document in web ? I am trying to follow the steps mentioned in _http://svn.apache.org/repos/asf/subversion/trunk/INSTALL_. And I want to upgrade in Linux [USER@server subversion-1.9.4]$ sh autogen.sh : command not found: : command not found: : command not found: ': not a valid identifiert: `CDPATH : command not found: 'utogen.sh: line 35: syntax error near unexpected token `in 'utogen.sh: line 35: ` case "$1" in Given the output you have here, I take it you downloaded the source as a tarball instead of getting it directly form the repository. In this case, please follow the instructions in INSTALL under II.A instead II.B. I.e. run ./configure make make install -- Regards, Stefan Hett ___ This email is intended only for the use of the individual(s) to whom it is addressed and may be privileged and confidential. Unauthorised use or disclosure is prohibited. If you receive This e-mail in error, please advise immediately and delete the original message. This message may have been altered without your or our knowledge and the sender does not accept any liability for any errors or omissions in the message. Ce courriel est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courriel par erreur, veuillez m'en aviser immédiatement, par retour de courriel ou par un autre moyen. -- Regards, Stefan Hett
Re: Is there a way to 'sparsify' a working copy, without starting over?
On Tue, Jun 14, 2016 at 10:04 PM, Johan Corveleyn wrote: > On Mon, Jun 13, 2016 at 10:52 AM, Daniel Shahaf > wrote: >> Johan Corveleyn wrote on Mon, Jun 13, 2016 at 10:04:13 +0200: >>> But if you have local moves, it seems the 'Delete' part of the move is >>> lost when updating to depth empty, and the move is broken (converted >>> into just the A+ of the "Add" part). >>> >>> This looks like a bug in "update --set-depth" (losing information >>> about local deletes (potentially part of a move)). >>> Other than that, this technique seems to work fine. >> >> Is the bug specific to --set-depth? It sounds like a delete-delete tree >> conflict, in which case, I would expect the following scenario to >> trigger the same behaviour: >> >> # greek tree >> svnadmin create r >> svn co -q file://$PWD/r wc >> cd wc >> touch iota >> svn add -q iota >> svn ci -q -m r1 >> svn up -q >> # scenario: >> svn rm -q -m r2 ^/iota >> svn mv -q iota kappa >> svn up >> >> Sorry, I can't test this right now... > > No it doesn't trigger this behaviour. This gives a delete-delete tree > conflict, as expected. > > But watch this: > > [[[ > C:\svntest>svnadmin create r > > C:\svntest>svn co -q file:///c:/svntest/r wc > > C:\svntest>cd wc > > C:\svntest\wc>touch iota > > C:\svntest\wc>svn add -q iota > > C:\svntest\wc>svn ci -q -m r1 > > C:\svntest\wc>svn up -q > > C:\svntest\wc>svn mv iota kappa > A kappa > D iota > > C:\svntest\wc>svn st > D iota > > moved to kappa > A +kappa > > moved from iota > > C:\svntest\wc>svn up --set-depth empty > D iota > Updating '.': > Updated to revision 1. > > C:\svntest\wc>svn st > A +kappa > ]]] > > Oops. Delete information is lost, and with it also the move information. > > I don't think this should raise a tree conflict (just like when iota > is 'M', and you execute 'svn up --set-depth empty', the modified iota > is just left there as a part of the sparse tree -- no delete-edit > conflict is raised). So I think it should just leave the 'D's (and > move information) there. The "emptying" seems to be optional, IIUC the > intention is that anything that's modified in some way should be left > alone (which is cool when sparsifying). > > The above scenario looks like a bug, no? Similarly, a plain Delete is also lost when "emptying" the working copy. I think the "scheduled delete" should simply stay (keep all local changes, whether they are text or tree changes, when making the working copy more sparse). [[[ C:\svntest>svn co file:///c:/svntest/r wc2 Awc2\iota Checked out revision 1. C:\svntest>cd wc2 C:\svntest\wc2>svn rm iota D iota C:\svntest\wc2>svn st D iota C:\svntest\wc2>svn up --set-depth empty D iota Updating '.': Updated to revision 1. C:\svntest\wc2>svn st ]]] -- Johan
Performance Decrease After Moving Working Copy to Another Machine
Hello, I am trying to move/copy a Subversion (version 1.8.10) working copy from one linux machine to another. From researching similar questions/answers, this seems possible by simply moving the entire folder (along with the .svn subdirectory). I have implemented a solution that performs this copy using tar. On source machine: `tar -cpz -f checkout_directory.tar.gz checkout_directory` On destination machine (after copy of the tarball): `tar -xpz -f checkout_directory.tar.gz` This achieves the goal of moving the working copy to the destination machine; however the performance of svn operations becomes drastically slower. For example, a `svn status` on the original machine takes < 1 minute, but takes ~1 hour on the destination machine. The entire folder is ~50GB, but these timings include clearing out the linux buffers/caches and similar hardware/load on each machine. I can mitigate the performance hit by doing an `svn cleanup` on the destination machine, but this operation also takes ~1 hour. I suspect this updates the change times that Subversion uses to determine whether or not local changes have been made (http://svn.haxx.se/users/archive-2003-11/0595.shtml). Is there a better way of moving the working copy? P.S. I would like to avoid to doing another checkout on the destination machine because this must be done on many machines and the working copy has many untracked files (mostly binaries that are created from a nightly build). Thank you, Brandon
