RE: svn commit: r1434913 - /subversion/trunk/subversion/libsvn_wc/wc_db.c

> -Original Message- > From: MARTIN PHILIP [mailto:codematt...@ntlworld.com] On Behalf Of > Philip Martin > Sent: vrijdag 18 januari 2013 20:13 > To: Bert Huijben > Cc: dev@subversion.apache.org > Subject: Re: svn commit: r1434913 - > /subversion/trunk/subversion/libsvn_wc/wc_db.c > > "Ber

Re: svn commit: r1434913 - /subversion/trunk/subversion/libsvn_wc/wc_db.c

"Bert Huijben" writes: > This problem will never occur with a storing moved-from in BASE > (op-depth 0). (Moved-from is always stored in the op-root of the > addition, so this can never have this problem... The problem is in the > moved-to scheme) I think the two schemes are equivalent. The imp

Re: [PATCH] Combine conflict callback API error messages differing only by punctuation

On Fri, Jan 18, 2013 at 9:31 AM, Stefan Sperling wrote: > Well, it also makes formatting of matching error messages consistent. > So I like the third hunk, too :) +1 to the third hunk here as well.

Re: svn commit: r1434913 - /subversion/trunk/subversion/libsvn_wc/wc_db.c

On Fri, Jan 18, 2013 at 8:01 AM, Stefan Sperling wrote: > svn mv A B > svn mv B A > > is a no-op, and the sequence: > > svn mv A B > # make changes in B > svn mv B A > > results in the equivalent of: > > # make changes in A > > I'm considering trying to work on this soon. +1, this is the only sen

Re: [PATCH] Combine conflict callback API error messages differing only by punctuation

On Fri, Jan 18, 2013 at 07:28:24PM +0200, Daniel Shahaf wrote: > The third one seems to be an unnecessary whitespace-only change. Well, it also makes formatting of matching error messages consistent. So I like the third hunk, too :) > Andreas Stieger wrote on Fri, Jan 18, 2013 at 17:25:06 +:

Re: [PATCH] Fix segfault in 'svnauthz' (missing command table sentinel)

On Fri, Jan 18, 2013 at 9:10 AM, Daniel Shahaf wrote: > Thanks, r1435252. > > Evgeny Kotkov wrote on Fri, Jan 18, 2013 at 20:57:28 +0400: >> This patch is a follow-up to r1428209. It adds the command table sentinel >> for 'svnauthz' tool (tools/server-side/svnauthz.c). Oops, not sure how I misse

Re: [PATCH] Combine conflict callback API error messages differing only by punctuation

On Fri, Jan 18, 2013 at 05:25:06PM +, Andreas Stieger wrote: > Hello, > > [[[ > Combine conflict callback API error messages differing only by punctuation > > * subversion/libsvn_wc/conflicts.c > (generate_propconflict,resolve_text_conflicts): Combine messages which >differ only by punc

Re: [PATCH] Combine conflict callback API error messages differing only by punctuation

+1 for the first two hunks. The third one seems to be an unnecessary whitespace-only change. Andreas Stieger wrote on Fri, Jan 18, 2013 at 17:25:06 +: > Hello, > > [[[ > Combine conflict callback API error messages differing only by punctuation > > * subversion/libsvn_wc/conflicts.c > (ge

[PATCH] Combine conflict callback API error messages differing only by punctuation

Hello, [[[ Combine conflict callback API error messages differing only by punctuation * subversion/libsvn_wc/conflicts.c (generate_propconflict,resolve_text_conflicts): Combine messages which differ only by punctuation, remove trailing period from another ]]] Andreas Index: subversion/libsv

Re: svn commit: r1434913 - /subversion/trunk/subversion/libsvn_wc/wc_db.c

On Fri, Jan 18, 2013 at 05:17:31PM +0100, Bert Huijben wrote: > Just allowing that parent folder to be renamed via move tracking is a much > to simple view. Moves of subtrees must be handled independent of their > parent. Isn't this exactly what Philip's multi-layer move scheme was supposed to all

Re: svn commit: r1434913 - /subversion/trunk/subversion/libsvn_wc/wc_db.c

On Fri, Jan 18, 2013 at 05:42:41PM +0100, Bert Huijben wrote: > Do we currently detect switched paths when handling move tracking... or just > mixed revisions? I think 'svn mv' only checks for mixed revs in the move source at present. Checking for switched paths and disallowing them sounds like a

Re: svn commit: r1434913 - /subversion/trunk/subversion/libsvn_wc/wc_db.c

Philip Martin writes: > "Bert Huijben" writes: > >> svn mv A Z >> svn mv Z/B B >> svn mv Z/C C >> svn rm Z > > The "svn rm Z" is removing half of a move (A-to-Z) so it currently > fails. If we allow the delete what happens to A? It can't be marked > moved-to Z because Z no longer exists. We c

Re: [PATCH] Fix segfault in 'svnauthz' (missing command table sentinel)

Thanks, r1435252. Evgeny Kotkov wrote on Fri, Jan 18, 2013 at 20:57:28 +0400: > This patch is a follow-up to r1428209. It adds the command table sentinel > for 'svnauthz' tool (tools/server-side/svnauthz.c).

[PATCH] Fix segfault in 'svnauthz' (missing command table sentinel)

Hi, This patch is a follow-up to r1428209. It adds the command table sentinel for 'svnauthz' tool (tools/server-side/svnauthz.c). The absense of this sentinel can result in undefined behavior (most likely segfault), e.g., during a "svnauthz help" call — we're iterating over the commands until we

RE: svn commit: r1434913 - /subversion/trunk/subversion/libsvn_wc/wc_db.c

> -Original Message- > From: Stefan Sperling [mailto:s...@elego.de] > Sent: vrijdag 18 januari 2013 17:01 > To: Bert Huijben; 'Philip Martin'; dev@subversion.apache.org > Subject: Re: svn commit: r1434913 - > /subversion/trunk/subversion/libsvn_wc/wc_db.c > > On Fri, Jan 18, 2013 at 04:5

RE: svn commit: r1434913 - /subversion/trunk/subversion/libsvn_wc/wc_db.c

> -Original Message- > From: MARTIN PHILIP [mailto:codematt...@ntlworld.com] On Behalf Of > Philip Martin > Sent: vrijdag 18 januari 2013 16:50 > To: Bert Huijben > Cc: dev@subversion.apache.org > Subject: Re: svn commit: r1434913 - > /subversion/trunk/subversion/libsvn_wc/wc_db.c > > "B

Re: svn commit: r1434913 - /subversion/trunk/subversion/libsvn_wc/wc_db.c

Stefan Sperling wrote: > On Fri, Jan 18, 2013 at 04:52:42PM +0100, Stefan Sperling wrote: >> like 'svn mv A B; svn mv B A' earlier, which >> also doesn't make sense). > > What I mean here is that I think this command sequence should > result in a no-op as far as the move operation is concerned.

RE: svn commit: r1434913 - /subversion/trunk/subversion/libsvn_wc/wc_db.c

> -Original Message- > From: Stefan Sperling [mailto:s...@elego.de] > Sent: vrijdag 18 januari 2013 16:53 > To: Bert Huijben > Cc: 'Philip Martin'; dev@subversion.apache.org > Subject: Re: svn commit: r1434913 - > /subversion/trunk/subversion/libsvn_wc/wc_db.c > > On Fri, Jan 18, 2013 at

Re: svn commit: r1434913 - /subversion/trunk/subversion/libsvn_wc/wc_db.c

On Fri, Jan 18, 2013 at 04:52:42PM +0100, Stefan Sperling wrote: > like 'svn mv A B; svn mv B A' earlier, which > also doesn't make sense). What I mean here is that I think this command sequence should result in a no-op as far as the move operation is concerned. Rather than running a copy+delete

Re: svn commit: r1430185 - in /subversion/trunk/subversion: include/svn_dav.h libsvn_ra_serf/options.c libsvn_ra_serf/ra_serf.h mod_dav_svn/version.c

On Fri, Jan 11, 2013 at 11:27 AM, Ivan Zhakov wrote: > On Thu, Jan 10, 2013 at 12:24 AM, Mark Phippard wrote: >> On Wed, Jan 9, 2013 at 3:22 PM, Ivan Zhakov wrote: >>> On Thu, Jan 10, 2013 at 12:14 AM, C. Michael Pilato >>> wrote: On 01/09/2013 03:10 PM, Ivan Zhakov wrote: > I'm think

Re: svn commit: r1434913 - /subversion/trunk/subversion/libsvn_wc/wc_db.c

On Fri, Jan 18, 2013 at 03:18:23PM +0100, Bert Huijben wrote: > I'm still not sure if the current scheme scales under the move of multiple > subtrees > > svn mv A Z > svn mv Z/B B > svn mv Z/C C > svn rm Z You need --force here for 'svn rm Z' to work, and this results in the moves being lost: $

Re: svn commit: r1434913 - /subversion/trunk/subversion/libsvn_wc/wc_db.c

"Bert Huijben" writes: > I'm still not sure if the current scheme scales under the move of multiple > subtrees > > svn mv A Z > svn mv Z/B B > svn mv Z/C C > svn rm Z The "svn rm Z" is removing half of a move (A-to-Z) so it currently fails. If we allow the delete what happens to A? It can't be

Re: [patch] fix macro in a gettexted string

Andreas Stieger wrote on Fri, Jan 18, 2013 at 15:06:04 +: > Hello, > > I found a macro in a gettexted string which breaks the scanner. > > [[[ > Fix spelling error in svnadmin message and make gettext-friendly > > * subversion/svnadmin/svnadmin.c > (sub_main) fix spelling, fix macro call b

[patch] fix macro in a gettexted string

Hello, I found a macro in a gettexted string which breaks the scanner. [[[ Fix spelling error in svnadmin message and make gettext-friendly * subversion/svnadmin/svnadmin.c (sub_main) fix spelling, fix macro call breaking gettext ]]] I would like to point out that the message contains SVN_VE

RE: svn commit: r1434913 - /subversion/trunk/subversion/libsvn_wc/wc_db.c

> -Original Message- > From: MARTIN PHILIP [mailto:codematt...@ntlworld.com] On Behalf Of > Philip Martin > Sent: vrijdag 18 januari 2013 11:20 > To: Bert Huijben > Cc: dev@subversion.apache.org > Subject: Re: svn commit: r1434913 - > /subversion/trunk/subversion/libsvn_wc/wc_db.c > > "B

Re: 1.8 Release Status : Issue triage

On 18.01.2013 12:42, Justin Erenkrantz wrote: > On Thu, Jan 17, 2013 at 1:19 AM, Branko Čibej > wrote: > > > 1 has not been marked as started nor been assigned but is tied to an > > open serf issue: > > 4274 DEFECT P3 All issues@subversion ph

Re: 1.8 Release Status : Issue triage

On Thu, Jan 17, 2013 at 1:19 AM, Branko Čibej wrote: > > 1 has not been marked as started nor been assigned but is tied to an > > open serf issue: > > 4274 DEFECT P3 All issues@subversion philip NEW > 1.8.0 serf > > client hangs when server crashes > > I reviewed this th

Re: svn commit: r1434913 - /subversion/trunk/subversion/libsvn_wc/wc_db.c

On Fri, Jan 18, 2013 at 11:29 AM, Branko Čibej wrote: > On 18.01.2013 11:20, Johan Corveleyn wrote: >> On Thu, Jan 17, 2013 at 10:59 PM, Ben Reser wrote: >>> On Thu, Jan 17, 2013 at 1:14 PM, Bert Huijben wrote: I think $ svn mv A B $ svn mv B A Will now store moved_from

Re: svn commit: r1434913 - /subversion/trunk/subversion/libsvn_wc/wc_db.c

On 18.01.2013 11:20, Johan Corveleyn wrote: > On Thu, Jan 17, 2013 at 10:59 PM, Ben Reser wrote: >> On Thu, Jan 17, 2013 at 1:14 PM, Bert Huijben wrote: >>> I think >>> $ svn mv A B >>> $ svn mv B A >>> >>> Will now store moved_from and moved_to in the same record, at the op-depth >>> of A. >>>

Re: svn commit: r1434913 - /subversion/trunk/subversion/libsvn_wc/wc_db.c

On Thu, Jan 17, 2013 at 10:59 PM, Ben Reser wrote: > On Thu, Jan 17, 2013 at 1:14 PM, Bert Huijben wrote: >> I think >> $ svn mv A B >> $ svn mv B A >> >> Will now store moved_from and moved_to in the same record, at the op-depth >> of A. >> (Or copy_tests.py move_file_back_and_forth wouldn't sh

Re: svn commit: r1434913 - /subversion/trunk/subversion/libsvn_wc/wc_db.c

"Bert Huijben" writes: > I think > $ svn mv A B > $ svn mv B A > > Will now store moved_from and moved_to in the same record, at the > op-depth of A. (Or copy_tests.py move_file_back_and_forth wouldn't > show moved_from and moved_to on a single node using status using the > code snippet here) >

Re: svn commit: r1434913 - /subversion/trunk/subversion/libsvn_wc/wc_db.c

On Fri, Jan 18, 2013 at 10:43 AM, Stefan Sperling wrote: > On Thu, Jan 17, 2013 at 10:14:11PM +0100, Bert Huijben wrote: >> I think >> $ svn mv A B >> $ svn mv B A >> >> Will now store moved_from and moved_to in the same record, at the op-depth >> of A. >> (Or copy_tests.py move_file_back_and_for

Re: svn commit: r1434913 - /subversion/trunk/subversion/libsvn_wc/wc_db.c

On Fri, Jan 18, 2013 at 10:43:35AM +0100, Stefan Sperling wrote: > If you move a node that isn't present in op_depth == 0, you don't need > to preserve the old location of the node. Should have phrased this better: "If you move a node that is newly added ..." Of course we can move nodes within co

Re: Functional and UI spec for local moves

On Thu, Jan 17, 2013 at 10:58:16PM +, Julian Foad wrote: >  Maybe experiment to document how trunk actually > behaves at the moment, and review that for any show-stopper issues? Yes, please! In my opinion this is what we need to do to get 1.8 into shape for release. The more eyes we get on the

Re: svn commit: r1434913 - /subversion/trunk/subversion/libsvn_wc/wc_db.c

On Thu, Jan 17, 2013 at 10:14:11PM +0100, Bert Huijben wrote: > I think > $ svn mv A B > $ svn mv B A > > Will now store moved_from and moved_to in the same record, at the op-depth of > A. > (Or copy_tests.py move_file_back_and_forth wouldn't show moved_from and > moved_to on a single node using

Re: svn commit: r1434913 - /subversion/trunk/subversion/libsvn_wc/wc_db.c

On Thu, Jan 17, 2013 at 10:14:11PM +0100, Bert Huijben wrote: > 21:10 <@breser> If our wc move design is predicated on not replacing the from > path we've made a major error. I don't think this is a design problem. The bug simply seems to be that the 'mkdir' in: svn mv A B svn mkdir A doesn't p