[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.

Thanks,
Justin
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.