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

Re: RFC: Quick question on how --reintegrate merges should behave

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Tue, 18 Nov 2008 17:50:34 +0000

On Tue, 2008-11-18 at 09:18 -0800, David Glasser wrote:
> On Tue, Nov 18, 2008 at 7:57 AM, Mark Phippard <markphip_at_gmail.com> wrote:
> > On Tue, Nov 18, 2008 at 10:49 AM, Paul Burba <ptburba_at_gmail.com> wrote:
> >> B) Merge the diff between 'trunk' and 'branch's youngest common
> >> ancestor and 'branch_at_r4', i.e. TRUNK_URL_at_1 BRANCH_URL_at_4 to 'trunk'.
> >>
> >> The current behavior is 'B'. Note that there is the possibility of a
> >> conflict between r3 and r4.
[...]
> > I agree with you that the current behavior is right.
>
> What he said.

FYI, I'll mention one of the reasons for allowing a reintegrate when the
branch isn't completely up to date. In a fast-moving project, if each
merge takes a finite amount of time (heh) and then you have to test the
result, you could be stuck with always being out of date by the time
you're ready to reintegrate. Our "commit" policy allows non-overlapping
parts of the tree to be out of date, which helps to solve this problem,
and it would be strangely inconsistent if our "merge [--reintegrate]"
did not.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-18 18:50:59 CET

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

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