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
18 matches
Mail list logo
