Fredrik Orderud wrote on Sun, Aug 11, 2013 at 00:26:54 +0200:
> I've managed to rewrite the test script to use A/mu in the auto-generated
> greek tree, but I did not understand how to use svntest/actions.py to parse
> the output. Still, I took the liberty of attaching a 2nd revision of the
> failin
On Sat, Aug 10, 2013 at 9:30 PM, Fredrik Orderud wrote:
> On Fri, Aug 9, 2013 at 5:18 PM, Daniel Shahaf wrote:
>
>> Fredrik Orderud wrote on Tue, Aug 06, 2013 at 22:40:02 +0200:
>> > I've now written an XFAIL test for merging the same change change
>> twice.
>> > Patch attached. The test fails
On Sat, Aug 10, 2013 at 9:30 PM, Fredrik Orderud wrote:
> On Fri, Aug 9, 2013 at 5:18 PM, Daniel Shahaf wrote:
>
>> Fredrik Orderud wrote on Tue, Aug 06, 2013 at 22:40:02 +0200:
>> > I've now written an XFAIL test for merging the same change change
>> twice.
>> > Patch attached. The test fails
On Fri, Aug 9, 2013 at 5:18 PM, Daniel Shahaf wrote:
> Fredrik Orderud wrote on Tue, Aug 06, 2013 at 22:40:02 +0200:
> > I've now written an XFAIL test for merging the same change change twice.
> > Patch attached. The test fails as expected due to the lack of conflict.
> > This is the first test
Fredrik Orderud wrote on Tue, Aug 06, 2013 at 22:40:02 +0200:
> On Tue, Aug 6, 2013 at 3:19 PM, Johan Corveleyn wrote:
>
> > FYI, another user complained about this on the users list (Fredrik
> > Orderud, CC'd) [1]. He has filed issue #4405 [2]. Perhaps some of the
> > interested parties here can
On Fri, Aug 09, 2013 at 05:53:26PM +0300, Daniel Shahaf wrote:
> Johan Corveleyn wrote on Fri, Aug 09, 2013 at 16:35:36 +0200:
> > Thanks for the patch. Don't be put off by the lack of response, some
> > people are on holiday (I'm writing this response from the side of a
> > swimming pool myself :-
Johan Corveleyn wrote on Fri, Aug 09, 2013 at 16:35:36 +0200:
> Thanks for the patch. Don't be put off by the lack of response, some
> people are on holiday (I'm writing this response from the side of a
> swimming pool myself :-)). So it might take a couple more days /
> weeks.
It would also help
On Tue, Aug 6, 2013 at 10:40 PM, Fredrik Orderud wrote:
> On Tue, Aug 6, 2013 at 3:19 PM, Johan Corveleyn wrote:
>>
>> FYI, another user complained about this on the users list (Fredrik
>> Orderud, CC'd) [1]. He has filed issue #4405 [2]. Perhaps some of the
>> interested parties here can take a
On Tue, Aug 6, 2013 at 3:19 PM, Johan Corveleyn wrote:
> FYI, another user complained about this on the users list (Fredrik
> Orderud, CC'd) [1]. He has filed issue #4405 [2]. Perhaps some of the
> interested parties here can take a closer look? Or maybe Fredrik or
> anyone can start / continue d
On Thu, Apr 11, 2013 at 9:59 PM, Julian Foad wrote:
> 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
l 2013, 19:42
> Subject: 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 ide
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
>
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
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.
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
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
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
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
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
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
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
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
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
treated this as a no-op. As to why, I'm not entirely sure, but this
behavior is
On Wed, Apr 10, 2013 at 5:12 AM, Christoph Schulz wrote:
> Hello,
>
> in SVN 1.7.9 and earlier versions (als tested 1.7.7 and 1.7.8), it can
> happen that a merge succeeds although the patch definitely cannot be
> applied. This happens when the changeset to be applied deletes some lines at
> the v
24 matches
Mail list logo
