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

Re: Problem with merge tracking in 1.5.0

From: J J <eggsgloriouseggs_at_gmail.com>
Date: Fri, 18 Jul 2008 11:24:52 -0500

On Fri, Jul 18, 2008 at 11:13 AM, Mark Phippard <markphip_at_gmail.com> wrote:

> On Fri, Jul 18, 2008 at 12:07 PM, J J <eggsgloriouseggs_at_gmail.com> wrote:
> >> It is fine to merge on sub-directories or files. What is not fine, is
> >> to try to mix that with whole branch merges. The theory behind
> >> reintegrate was that users were likely to do one or the other. The
> >> big wrench stuck in the spokes of that idea was move/rename creating
> >> this information.
> >
> > Making subtree merges and whole branches merges mutually exclusive is a
> > pretty big assumption. Is that explicitly stated anywhere so users know
> > what they're getting into? As far as releasing incremental merge
> tracking
> > functionality it is definitely a step forward, but hopefully not the end
> > goal.
> I did not mean to imply they are mutually exclusive or intended to be
> that way. It really gets back to this one problem of reflective
> merges and the "solution" we put in place for 1.5. The reintegrate
> option is a purely whole branch solution. But for example something
> that works really well in 1.5 is to cherry pick a few files or
> revisions to a branch and then later go back and merge everything to
> that branch.

I agree. Cherry picking and full branch merging work great when reintegrate
is not involved. Reintegrate is needed by many teams though. I just wanted
to make sure it was clear to new users.

I'm getting a better handle on the issues so I'll put the appropriate
processes in place for our company to avoid them until they are fixed
(hopefully) in future releases.

Received on 2008-07-18 18:25:17 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.