[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Merge tracking implementation issue.

From: Mark Phippard <markphip_at_gmail.com>
Date: Wed, 8 Apr 2009 12:48:31 -0400

On Wed, Apr 8, 2009 at 12:00 PM, Ruslan Sivak <russ_at_vshift.com> wrote:
> I second fixing this issues, although I'm not privy to the merits of
> fixing it the way Konstantin suggests.  I expected 1.6 to be better with
> merging, but it seems to have made things worse.

This is absolutely not true in any way. 1.6 has not made this worse.
Perhaps more people are just getting into the issue.

> I see a lot of emails about this on the list recently.  Will a developer
> take responsibility and fix this issue once and for all?  Is there
> something that we as a community can do to help speed things along?

A developer has:

http://svn.collab.net/repos/svn/branches/subtree-mergeinfo/

The current behavior is not a bug. It was intended to work the way it
does and people had to go out of their way to write the code to make
it happen. It is clear, in real world usage that the end result has
side effects that suck. So work is being done to understand what
negative results would happen if these properties were not updated and
then whether those things can be corrected.

Work went into 1.6 and was backported to 1.5.5 and 1.5.6 to reduce the
creation of subtree mergeinfo, which reduces the problem. Work went
into merge reintegrate to tolerate subtree mergeinfo, to reduce the
consequences of having it. Now work is going on to try to minimize
the cases where it needs to be updated.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1599117
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-04-08 18:49:33 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.