On Mon, Apr 13, 2015 at 10:58 AM, Pete Harlan wrote:
>> My scripts are Bash scripts similar to the script I originally posted
>> to this thread. I can share them if you think that would be useful,
>> or I'm happy to rerun them against other versions upon request.
...
> Attached. Disclaimer: they
On Mon, Apr 13, 2015 at 9:31 AM, Julian Foad wrote:
> Pete Harlan wrote:
>> Julian Foad wrote:
> [...]
>>> Another way to help would be to think about how the client could
>>> present the "WC is in a merged state" notion, and how that would
>>> affect various operations. Just assume that we can im
On Fri, Apr 10, 2015 at 6:40 PM, Branko Čibej wrote:
> On 11.04.2015 02:01, Pete Harlan wrote:
>> On Thu, Apr 2, 2015 at 11:00 AM, Julian Foad
>> wrote:
>>> Pete Harlan wrote:
>> ...
If you have suggestions for how I could further help this issue along,
please let me know. And thanks
Pete Harlan wrote:
> Julian Foad wrote:
[...]
>> Another way to help would be to think about how the client could
>> present the "WC is in a merged state" notion, and how that would
>> affect various operations. Just assume that we can implement it, and
>> imagine how it should behave in order to b
Hi Pete. Just one quick point before I take the time to digest
everything else...
Pete Harlan wrote:
> I wrote a list of cases I could think of to test, and tested them
> against 1.8.13.
[...]
> FAILED: dir-add-add.sh (Dir of same name added to both sides.)
> FAILED: dir-copy-add.sh (Same, only
On 11.04.2015 02:01, Pete Harlan wrote:
> On Thu, Apr 2, 2015 at 11:00 AM, Julian Foad
> wrote:
>> Pete Harlan wrote:
> ...
>>> If you have suggestions for how I could further help this issue along,
>>> please let me know. And thanks again very much for your time.
>> It would help to catalogue t
On Thu, Apr 2, 2015 at 11:00 AM, Julian Foad wrote:
> Pete Harlan wrote:
...
>> If you have suggestions for how I could further help this issue along,
>> please let me know. And thanks again very much for your time.
>
> It would help to catalogue the various cases. Maybe start with an
> premise t
Pete Harlan wrote:
> Julian Foad wrote:
[...]
>> On 2015-03-16, Pete Harlan wrote:
>>> On 2015-03-14, Pete Harlan wrote:
My expectation as a naive user is: I initiated a merge from the root
of a branch (or trunk), I told svn to merge the root of another branch
(or trunk), and I resol
On Tue, Mar 31, 2015 at 8:05 AM, Julian Foad wrote:
> Hello.
>
> Firstly I'd like to say thank you, Pete, for bringing up this issue
> and discussing it so clearly.
>
> I had a think about this the other day and chatted with the others on IRC [1].
>
> I picked this old email from this thread to re
Hello.
Firstly I'd like to say thank you, Pete, for bringing up this issue
and discussing it so clearly.
I had a think about this the other day and chatted with the others on IRC [1].
I picked this old email from this thread to reply to, as it's got me
in the CC and is as good a one as any to re
Pete Harlan wrote on Mon, Mar 30, 2015 at 08:40:46 -0700:
> On Sun, Mar 29, 2015 at 12:00 AM, Daniel Shahaf
> wrote:
> > Pete Harlan wrote on Fri, Mar 27, 2015 at 15:22:16 -0700:
> >> On Fri, Mar 27, 2015 at 2:27 PM, Johan Corveleyn wrote:
> >> > On Fri, Mar 27, 2015 at 9:01 PM, Pete Harlan
>
On Sun, Mar 29, 2015 at 12:00 AM, Daniel Shahaf wrote:
> Pete Harlan wrote on Fri, Mar 27, 2015 at 15:22:16 -0700:
>> On Fri, Mar 27, 2015 at 2:27 PM, Johan Corveleyn wrote:
>> > On Fri, Mar 27, 2015 at 9:01 PM, Pete Harlan wrote:
>> >> On Tue, Mar 24, 2015 at 11:24 AM, Pete Harlan
>> >> wrote
Pete Harlan wrote on Fri, Mar 27, 2015 at 15:22:16 -0700:
> On Fri, Mar 27, 2015 at 2:27 PM, Johan Corveleyn wrote:
> > On Fri, Mar 27, 2015 at 9:01 PM, Pete Harlan wrote:
> >> On Tue, Mar 24, 2015 at 11:24 AM, Pete Harlan
> >> wrote:
> >>> Is it accurate then to say that Subversion may generat
On Fri, Mar 27, 2015 at 2:27 PM, Johan Corveleyn wrote:
> On Fri, Mar 27, 2015 at 9:01 PM, Pete Harlan wrote:
>> On Tue, Mar 24, 2015 at 11:24 AM, Pete Harlan wrote:
>>> Is it accurate then to say that Subversion may generate explicit
>>> mergeinfo whenever it decides that there is something use
On Fri, Mar 27, 2015 at 9:01 PM, Pete Harlan wrote:
> On Tue, Mar 24, 2015 at 11:24 AM, Pete Harlan wrote:
>> Is it accurate then to say that Subversion may generate explicit
>> mergeinfo whenever it decides that there is something useful to record
>> about the set of revisions that contributed t
On Tue, Mar 24, 2015 at 11:24 AM, Pete Harlan wrote:
> Is it accurate then to say that Subversion may generate explicit
> mergeinfo whenever it decides that there is something useful to record
> about the set of revisions that contributed to a given node, and that
> svn:mergeinfo properties may ap
Is it accurate then to say that Subversion may generate explicit
mergeinfo whenever it decides that there is something useful to record
about the set of revisions that contributed to a given node, and that
svn:mergeinfo properties may appear in subnodes as part of normal
Subversion merging bookkeep
On Mon, Mar 16, 2015 at 6:08 PM, Branko Čibej wrote:
>>> In an ideal world, you colleague's argument would be wrong: the merge
>>> should record what was actually merged, not what the merge command
>>> intended. So, in cases as the one that started this discussion — when
>>> part of the tree canno
On 16.03.2015 22:15, Pete Harlan wrote:
> On Mon, Mar 16, 2015 at 12:31 PM, Branko Čibej wrote:
>>> A colleague argued that creating the mergeinfo for a subtree in this
>>> case (root->root merge) is a simple bug because mergeinfo says what
>>> inputs were considered to come up with the result, no
On Mon, Mar 16, 2015 at 12:31 PM, Branko Čibej wrote:
>> A colleague argued that creating the mergeinfo for a subtree in this
>> case (root->root merge) is a simple bug because mergeinfo says what
>> inputs were considered to come up with the result, not just those that
>> were used.
>>
>> 1. If t
On 16.03.2015 19:02, Pete Harlan wrote:
> On Sat, Mar 14, 2015 at 4:05 PM, Pete Harlan wrote:
>> As you pointed out, my original report erroneously focused on
>> svn:mergeinfo appearing, when the real issue is that the new
>> svn:mergeinfo doesn't disappear (still) when the user marks the
>> confl
On Sat, Mar 14, 2015 at 4:05 PM, Pete Harlan wrote:
> As you pointed out, my original report erroneously focused on
> svn:mergeinfo appearing, when the real issue is that the new
> svn:mergeinfo doesn't disappear (still) when the user marks the
> conflict resolved. (And I haven't found a way to r
On Sat, Mar 14, 2015 at 7:45 AM, Bert Huijben wrote:
> Looking further (after turning your test in a regression test), I think this
> shows another problem. The conflict is on 'dir', not really on file.
>
> But (for legacy reasons) we somehow think that conflicting directory adds are
> something
> -Original Message-
> From: Bert Huijben [mailto:b...@qqmail.nl]
> Sent: zaterdag 14 maart 2015 13:06
> To: 'Pete Harlan'
> Cc: 'subversion'; pbu...@collab.net; 'Julian Foad'
> Subject: RE: 1.8 bug(?): svn:mergeinfo set for tree-conflicted
n stored to do this
operation for you (See 'svn info' on your conflicted file)... We just haven't
any resolver strategies on merge implemented yet.
> Or am I misunderstanding something about the svn:mergeinfo property or
> conflict resolution that would explain the need to
---
>> From: Pete Harlan [mailto:pchpubli...@gmail.com]
>> Sent: vrijdag 13 maart 2015 23:18
>> To: Bert Huijben
>> Cc: subversion
>> Subject: Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in
>> subdirs
>>
>> Hi,
>>
>> I narrowed do
> -Original Message-
> From: Pete Harlan [mailto:pchpubli...@gmail.com]
> Sent: vrijdag 13 maart 2015 23:18
> To: Bert Huijben
> Cc: subversion
> Subject: Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in
> subdirs
>
> Hi,
>
> I narrowed d
Hi,
I narrowed down the change to this commit, in version 1.8.0-dev:
r1441043 | rhuijben | 2013-01-31 08:20:25 -0800 (Thu, 31 Jan 2013) |
30 lines
Following up on r1440966, also handle file obstruction handling in the merge
I verified that this test also fails the same way on the latest
subversion trunk (1.10.0-dev).
Pass: 1.6.11
Pass: 1.7.17
Fail: 1.8.11
Fail: 1.10.0-dev
Is there a reason not to open a bug report?
Thanks,
--Pete
On Wed, Mar 11, 2015 at 4:54 PM, Pete Harlan wrote:
> Thank you for your reply.
>
Thank you for your reply.
> the mergeinfo tells that it didn't merge to that node.
Once I've resolved the tree conflict, is there a sense in which it
didn't merge everything in /trunk into /branches/branch? Marking the
tree conflict resolved doesn't remove the svn:mergeinfo property from
dir/fil
I don’t know whether it is a bug or a feature. Storing this value will make a
future merge handle the partial merge that was skipped at first: the mergeinfo
tells that it didn't merge to that node.
There are two ways to remember that: record ‘non inheritable’ info on the
direct parent, and the
Hi,
Subversion 1.8.11 behaves differently than 1.7.17 and 1.6.11, in that
it sets empty svn:mergeinfo properties for files within a
tree-conflicted directory during a merge. The effect is this:
Layout:
/trunk
/branches/branch
Add empty dir/file.txt to trunk and independently to branch.
Merge t
32 matches
Mail list logo
