On Fri, Aug 31, 2018 at 11:06:07AM +0200, Dag-Erling Smørgrav wrote:
> Daniel Shahaf writes:
> > You probably know the following, but for the list's benefit I'll say it:
> > awk(1) is not a robust way to parse `svn status` output; the output is
> > columns-oriented, not whitespace-separated-fields
On Thu, Aug 30, 2018 at 10:08:36PM +, Daniel Shahaf wrote:
> Stefan Sperling wrote on Thu, 30 Aug 2018 14:06 +0200:
> > In --non-interactive mode the default value for --accept is 'recommended'.
>
> This is a backwards incompatible change to the semantics of `svn merge
> --non-interactive` (wi
Daniel Shahaf writes:
> You probably know the following, but for the list's benefit I'll say it:
> awk(1) is not a robust way to parse `svn status` output; the output is
> columns-oriented, not whitespace-separated-fields oriented. `svn st |
> cut` or `svn st --xml` are the recommended idioms.
N
Dag-Erling Smørgrav wrote on Thu, 30 Aug 2018 23:49 +0200:
> Daniel Shahaf writes:
> > Dag-Erling Smørgrav writes:
> > > % svn resolved $(svn stat | awk '$2 == "C" { print $3 }')
> > 'svn resolved -R ./' is equivalent and more robust.
>
> No. My command line only resolves tree conflicts. Yours
Stefan Sperling wrote on Thu, 30 Aug 2018 14:06 +0200:
> In --non-interactive mode the default value for --accept is 'recommended'.
This is a backwards incompatible change to the semantics of `svn merge
--non-interactive` (with no other --option flags): A workflow designed
under 1.9 and trusting s
Daniel Shahaf writes:
> Dag-Erling Smørgrav writes:
> > % svn resolved $(svn stat | awk '$2 == "C" { print $3 }')
> 'svn resolved -R ./' is equivalent and more robust.
No. My command line only resolves tree conflicts. Yours also resolves
text conflicts.
DES
--
Dag-Erling Smørgrav - d...@des.
Dag-Erling Smørgrav wrote on Thu, 30 Aug 2018 14:49 +0200:
> % svn resolved $(svn stat | awk '$2 == "C" { print $3 }')
'svn resolved -R ./' is equivalent and more robust.
Stefan Sperling writes:
> A tree conflict occurs because config.h.in was deleted from head in
> r294466: [...] However, config.h.in still exists on the
> vendor-branch, and during the merge of r338344 we get an edit for this
> file:
Correct, same goes for all the .0 files (which are prerendered
On Thu, Aug 30, 2018 at 06:15:58AM +, Chris wrote:
> By the way, if I remember correctly, --quiet works to stop the resolver, but
> --non-interactive did not.
This is correct. I misremembered how this was implemented.
The reason that the resolver runs in --non-interactive mode is that we
wan
On Thu, Aug 30, 2018 at 11:34:18AM +0200, Dag-Erling Smørgrav wrote:
> Stefan Sperling writes:
> > Could you provide a shell script I can use to actually run the problematic
> > merge myself in a working copy of the appropriate subdirectory of the
> > FreeBSD
> > repository?
>
> svn co -q svn://
Stefan Sperling writes:
> Could you provide a shell script I can use to actually run the problematic
> merge myself in a working copy of the appropriate subdirectory of the FreeBSD
> repository?
svn co -q svn://svn.freebsd.org/base/head@338344
cd head/crypto/openssh
svn merge --non-interactive -c
Chris writes:
> [...] The case reported in this thread seems to have the conflict far
> back so I guess that's why the mitigation doesn't work here.
No, it's stuck on a single revision. Look at the timings from the
trace:
35.021454 r338344
40.898214 r338059
40.898328 r333678
40.
ome theories on
what to test.
By the way, if I remember correctly, --quiet works to stop the resolver, but
--non-interactive did not.
/Chris
On Wed, 8/29/18, Stefan Sperling wrote:
Subject: Re: Tree conflict resolution considered harmful
To: "
On Wed, Aug 29, 2018 at 12:54:43PM +0200, Dag-Erling Smørgrav wrote:
> I'm using Subversion 1.10.2 to perform a non-interactive merge with
> around 15 tree conflicts (files that exist on the source branch but have
> been deleted from the target branch). It spends exactly two hours on
> each confli
On Wed, Aug 29, 2018 at 02:29:16PM +0200, Branko Čibej wrote:
> On 29.08.2018 12:54, Dag-Erling Smørgrav wrote:
> > Please add an option to disable conflict resolution entirely.
>
> Would not one of the --accept option values work? E.g.,
> `--accept=theirs-conflict', though that would also affect
On 29.08.2018 12:54, Dag-Erling Smørgrav wrote:
> I'm using Subversion 1.10.2 to perform a non-interactive merge with
> around 15 tree conflicts (files that exist on the source branch but have
> been deleted from the target branch). It spends exactly two hours on
> each conflict before the connect
Daniel Shahaf writes:
> Dag-Erling Smørgrav writes:
> > Please add an option to disable conflict resolution entirely.
> As a hotfix, I think this will do what you need?
Thanks, I will test this later.
DES
--
Dag-Erling Smørgrav - d...@des.no
Dag-Erling Smørgrav wrote on Wed, Aug 29, 2018 at 12:54:43 +0200:
> Please add an option to disable conflict resolution entirely.
As a hotfix, I think this will do what you need?
Index: subversion/libsvn_client/conflicts.c
===
--- su
I'm using Subversion 1.10.2 to perform a non-interactive merge with
around 15 tree conflicts (files that exist on the source branch but have
been deleted from the target branch). It spends exactly two hours on
each conflict before the connection is killed and it gives up and moves
on to the next.
19 matches
Mail list logo
