On Mon, Sep 14, 2015 at 3:03 AM, Bert Huijben wrote:
>> On 9/14/2015 7:56 AM, Daniel Becroft wrote:
>> > Hi guys,
>> >
>> >
>> > I've just upgraded to SVN 1.9. One of the first things I noticed is
>> > that when a binary file conflict is raised during an SVN update, I can
>> > no longer use the 'm
Hi,
If you're using Subversion 1.8, you may find this thread relevant:
http://thread.gmane.org/gmane.comp.version-control.subversion.user/118260
It describes specific instances in which Subversion 1.8 (and later)
add mergeinfo to nodes. The mergeinfo there may be safely removed.
--Pete
On Thu
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.
...
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
>>> a
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 a
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 st
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 reply to.
>
> Much of this has been said already, but here's my 'take' on the problem.
>
>
> On 2015-03-16, Pete Harlan wrote:
>> On 2015-03-14, Pete Harlan w
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,
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 deci
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 pr
bookkeeping, and this doesn't imply lack of a full
root->root merge or other user shenanigans?
I appreciate your time on this.
Thanks,
--Pete
On Tue, Mar 17, 2015 at 8:58 AM, Pete Harlan wrote:
> On Mon, Mar 16, 2015 at 6:08 PM, Branko Čibej wrote:
>>>> In an ideal world, y
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 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 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
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
isunderstanding something about the svn:mergeinfo property or
conflict resolution that would explain the need to track dir/file.txt
specially on an ongoing basis?
Thank you for your time.
Pete
On Fri, Mar 13, 2015 at 5:10 PM, Bert Huijben wrote:
>
>
>> -Original Message--
Pete
On Thu, Mar 12, 2015 at 3:50 PM, Pete Harlan wrote:
> 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 rep
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 re
merges faster.
>
> In 1.6 we could in general not change the node affected by a tree conflict,
> so we always had to choose the slow option. With the central metadata
> storage we can do things more efficient… and this allowed fixing a lot of
> known issues of previous versions.
>
>
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
20 matches
Mail list logo
