Re: Diff Project --invoke-diff-cmd part

Daniel Shahaf wrote: >> + * @deprecated Provided for backward compatibility with the 1.8 API. >>   * @since New in 1.8. >>   */ >> +SVN_DEPRECATED >>   svn_error_t * >>   svn_client_diff6(const apr_array_header_t *diff_options, > > Since this API is new in 1.8, you should just extend it witho

Re: Merge bug causes changesets to be applied although this should not be the case

  -- Join WANdisco's free daily demo sessions on Scaling Subversion for the Enterprise - Original Message - > From: Stefan Sperling > To: Christoph Schulz > Cc: dev@subversion.apache.org > Sent: Thursday, 11 April 2013, 19:42 > Subject: Re

Re: Diff Project --invoke-diff-cmd part

Julian Foad wrote on Fri, Apr 12, 2013 at 00:58:55 +0100: > Gabriela Gibson wrote: > > * subversion/svn/cl.h > >   (struct svn_cl__opt_state_t): Add new variable. > >   (struct svn_cl__opt_state_t.diff): Add new variable. Nitpick: you mean "struct member", not "variable". And you might as well me

Re: Diff Project --invoke-diff-cmd part

Partial review, including only the public API changes, and only the diff hunks (without their context not in the patch): Gabriela Gibson wrote on Thu, Apr 11, 2013 at 22:39:24 +0100: > Index: subversion/include/svn_client.h > === > --

Re: Diff Project --invoke-diff-cmd part

Gabriela Gibson wrote: > This patch plugs in a new option --invoke-diff-cmd into the existing > diff command structure, but does leave the existing "diff-cmd" option > untouched. > > This addition allows the user to define a complex diff command, to be > applied in place of the internal diff, for

Re: Merge bug causes changesets to be applied although this should not be the case

On Thu, Apr 11, 2013 at 09:01:09PM +0200, Christoph Schulz wrote: > However, if I delete a > _directory_ in trunk and testing (the directories are also identical > and have the same ancestor) and then merge this deletion from trunk > to testing, a tree conflict is raised: > > ! C testing/a >

Diff Project --invoke-diff-cmd part

This patch plugs in a new option --invoke-diff-cmd into the existing diff command structure, but does leave the existing "diff-cmd" option untouched. This addition allows the user to define a complex diff command, to be applied in place of the internal diff, for example: svn diff --invoke-diff-c

Re: Merge bug causes changesets to be applied although this should not be the case

Hello! Julian Foad schrieb am Thu, 11 Apr 2013 20:59:56 +0100 (BST): [...] the problem is that [...] no conflict is _detected_ at all. I agree that this behaviour is not good when you want strict conflict detection. This particular behaviour is just one of several heuristics in Subversi

Re: Merge bug causes changesets to be applied although this should not be the case

Hi Christoph. Christoph Schulz wrote: > [...] silently ignoring the deletion of a non-existing file part is not a > sound decision in my opinion. > [...] the problem is that [...] no conflict is _detected_ at all. I agree that this behaviour is not good when you want strict conflict detection.

Re: Merge bug causes changesets to be applied although this should not be the case

Hello! Stefan Sperling schrieb am Thu, 11 Apr 2013 20:11:23 +0200: Yes, but silently ignoring the deletion of a non-existing file part is not a sound decision in my opinion. Well, the change says "this section of the file should not be there anymore, get rid of it". But the section in questio

Re: [PATCH] Re-localise conflict prompt

11 apr 2013 kl. 14.24 skrev C. Michael Pilato: On 04/11/2013 03:45 AM, Mattias Engdegård wrote: [...] 3. The options that appear in the conflict prompt. These, I strongly believe, should all be translated, since it is essentially a menu of choices for the user. Note that this means that they w

Re: [PATCH] Re-localise conflict prompt

11 apr 2013 kl. 14.03 skrev Stefan Sperling: The keys people type at the conflict prompt will eventually become part of muscle memory. What is mnemonic to one person might not be mnemonic to someone else. [...] In which case having to type different keys at a menu prompt depending on the langu

Re: Merge bug causes changesets to be applied although this should not be the case

Hello! Stefan Sperling schrieb am Thu, 11 Apr 2013 20:11:23 +0200: Yes, this is an important distinction. But detection only makes sense if there is more than one way of resolution, doesn't it? An additional aspect I forgot in my last answer: Subversion is inconsistent here when comparing t

Re: Merge bug causes changesets to be applied although this should not be the case

On Thu, Apr 11, 2013 at 07:48:52PM +0200, Christoph Schulz wrote: > >Why do you think Subversion treats merges just as if it was a patch tool? > > Well, because it *is* some sort of a patch tool, when it comes to > merging, isn't it? Not reallt. 'svn update' is using a diff3 merge. If you're look

Re: Merge bug causes changesets to be applied although this should not be the case

Hello! Stefan Sperling schrieb am Thu, 11 Apr 2013 19:32:10 +0200: Why do you think Subversion treats merges just as if it was a patch tool? Well, because it *is* some sort of a patch tool, when it comes to merging, isn't it? A patch tool does search and replace. It does not _need_ to

Re: Merge bug causes changesets to be applied although this should not be the case

On Thu, Apr 11, 2013 at 05:29:32PM +0200, Christoph Schulz wrote: > 1) p2 depends on p1, i.e. p2 can only be applied to a.txt if p1 is > applied to a.txt before > > 2) p2 does not depend on p1, i.e. p1 and p2 are independent of each > other, i.e. we can apply p1 to a.txt first, then p2 _or_ we can

Re: Merge bug causes changesets to be applied although this should not be the case

On Thu, Apr 11, 2013 at 05:29:32PM +0200, Christoph Schulz wrote: > I have another test case from the past where a) is also > broken with Subversion's internal diff3 library (but there are no > problems using external /usr/bin/diff3). This, however, is a > separate issue, and there exists a simple

Re: svn commit: r1465647 - /subversion/site/publish/docs/release-notes/1.8.html

On Mon, Apr 8, 2013 at 6:00 PM, Bert Huijben wrote: > > > > -Original Message- > > From: stef...@apache.org [mailto:stef...@apache.org] > > Sent: maandag 8 april 2013 16:11 > > To: comm...@subversion.apache.org > > Subject: svn commit: r1465647 - /subversion/site/publish/docs/release- > >

Re: Merge bug causes changesets to be applied although this should not be the case

Hello! Paul Burba schrieb am Thu, 11 Apr 2013 10:45:34 -0400: What do you mean exactly? The file could me marked as resolved via "svn resolve" if that's what the user wants, couldn't it? I was asking what contents of the resolved file would be; not the mechanics of resolution. Lets assume fo

Re: Merge bug causes changesets to be applied although this should not be the case

On Wed, Apr 10, 2013 at 1:03 PM, Christoph Schulz wrote: > Hello! > > Paul Burba schrieb am Wed, 10 Apr 2013 11:35:35 -0400: > > >> Hi Christoph, >> >> If the left side of the merge doesn't equal the right side, but the >> right side of the merge is identical to the target, then we have long >> tr

Re: Compatibility-promise-less API's Re: Let's branch on Friday.

On Thu, Apr 11, 2013 at 08:00:30AM -0400, C. Michael Pilato wrote: > The last thing we need is a new "class" of public APIs with special promises. I agree, it would add too much extra complexity. Our API rules are already quite complex.

Re: svn commit: r1463721 - in /subversion/trunk/subversion/libsvn_client: checkout.c client.h commit.c copy.c export.c externals.c revert.c switch.c update.c

> I (Julian Foad) wrote: >> Philip Martin wrote: >>> julianf...@apache.org writes: URL: http://svn.apache.org/r1463721 > [...] --- subversion/trunk/subversion/libsvn_client/copy.c (original) +++ subversion/trunk/subversion/libsvn_client/copy.c Tue Apr  2 @@ -212,7 +214,6 @@ do_

Re: svn commit: r1463721 - in /subversion/trunk/subversion/libsvn_client: checkout.c client.h commit.c copy.c export.c externals.c revert.c switch.c update.c

I (Julian Foad) wrote: > Philip Martin wrote: >> julianf...@apache.org writes: >>> URL: http://svn.apache.org/r1463721 [...] >>> * subversion/libsvn_client/copy.c >>>   (do_wc_to_wc_copies_with_write_lock, >>>    do_wc_to_wc_moves, >>>    repos_to_wc_copy_single): Return a flag instead of sleeping

Re: svn commit: r1463721 - in /subversion/trunk/subversion/libsvn_client: checkout.c client.h commit.c copy.c export.c externals.c revert.c switch.c update.c

Julian Foad writes: > I suppose I was thinking I couldn't be sure that the same path was > used in each possible case.  Looking at it again, if dst_path is not a > URL then it would be reasonable to assume that all relevant changes > are on the same filesystem as dst_path.  Even more so if we use

Re: PATCH: keyword expansion 1.8

Stefan Sperling wrote on Mon, Feb 11, 2013 at 12:36:29 +0100: > On Mon, Feb 11, 2013 at 09:38:05AM +, Philip Martin wrote: > > Stefan Sperling writes: > > >> +svn_error_t * > > >> +svn_subst_build_keywords3(apr_hash_t **kw, > > >> + const char *keywords_string, > > >>

Re: svn commit: r1463721 - in /subversion/trunk/subversion/libsvn_client: checkout.c client.h commit.c copy.c export.c externals.c revert.c switch.c update.c

Please pass at least some path in the same filesystem as the resulting files. This allows detecting whether we can use a shorter sleep. Bert Sent from Windows Mail From: Philip Martin Sent: ‎Thursday‎, ‎April‎ ‎11‎, ‎2013 ‎12‎:‎27‎ ‎PM To: dev@subversion.apache.org julianf...@apache.org

Re: [PATCH] Re-localise conflict prompt

On 04/11/2013 03:45 AM, Mattias Engdegård wrote: > 10 apr 2013 kl. 20.52 skrev Mattias Engdegård: > >> In this example, the valid shorthands for --accept ("mc" etc) also >> double as prompt answers, but that would not have to be the case in >> translations. > > On second thought, perhaps we shoul

Re: svn commit: r1463721 - in /subversion/trunk/subversion/libsvn_client: checkout.c client.h commit.c copy.c export.c externals.c revert.c switch.c update.c

  -- Join WANdisco's free daily demo sessions on Scaling Subversion for the Enterprise - Original Message - > From: Philip Martin > To: dev@subversion.apache.org > Cc: > Sent: Thursday, 11 April 2013, 6:27 > Subject: Re: svn commit: r14637

Re: [PATCH] Re-localise conflict prompt

On Wed, Apr 10, 2013 at 08:52:49PM +0200, Mattias Engdegård wrote: > 4. The abbreviated option codes for input at the conflict prompt > ("e", "mc", etc). I argue for localisation of these to make them go > with the rest of the conflict prompt and to be mnemonic for the > user; I agree with everyth

Re: Compatibility-promise-less API's Re: Let's branch on Friday.

On 04/10/2013 09:50 PM, Daniel Shahaf wrote: >> That's unprecedented, we've never released an API "without compatibility >> promises". We could do that but that's a separate discussion IMO. > > That might be a good idea. How about we introduce a class of public > APIs, disabled by default (i.e.,

Re: Compatibility-promise-less API's Re: Let's branch on Friday.

Ivan Zhakov wrote on Thu, Apr 11, 2013 at 13:24:32 +0400: > On Thu, Apr 11, 2013 at 5:50 AM, Daniel Shahaf wrote: > > Daniel Shahaf wrote on Thu, Apr 11, 2013 at 02:28:30 +0300: > >> Ivan Zhakov wrote on Wed, Apr 10, 2013 at 23:33:01 +0400: > >> > On Wed, Apr 10, 2013 at 10:02 PM, Daniel Shahaf

Re: svn commit: r1463721 - in /subversion/trunk/subversion/libsvn_client: checkout.c client.h commit.c copy.c export.c externals.c revert.c switch.c update.c

julianf...@apache.org writes: > Author: julianfoad > Date: Tue Apr 2 19:53:43 2013 > New Revision: 1463721 > > URL: http://svn.apache.org/r1463721 > Log: > Fix some sleep-for-timestamps code: avoid missing some cases where we need > to sleep -- especially error cases -- and avoid sleeping in some

Re: Compatibility-promise-less API's Re: Let's branch on Friday.

On Thu, Apr 11, 2013 at 5:50 AM, Daniel Shahaf wrote: > Daniel Shahaf wrote on Thu, Apr 11, 2013 at 02:28:30 +0300: >> Ivan Zhakov wrote on Wed, Apr 10, 2013 at 23:33:01 +0400: >> > On Wed, Apr 10, 2013 at 10:02 PM, Daniel Shahaf wrote: >> > > Ivan Zhakov wrote on Wed, Apr 10, 2013 at 21:48:39 +0

Re: [PATCH] Re-localise conflict prompt

10 apr 2013 kl. 20.52 skrev Mattias Engdegård: In this example, the valid shorthands for --accept ("mc" etc) also double as prompt answers, but that would not have to be the case in translations. On second thought, perhaps we should just drop --accept=mc and require the long word codes fo