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

Re: Re: Re: [Subclipse-users] Branch merge issues

From: Mark Phippard <markphip_at_gmail.com>
Date: Tue, 26 May 2009 09:40:39 -0400

On Tue, May 26, 2009 at 9:26 AM, Stephen Colebourne
<scolebourne_at_joda.org> wrote:

> Trying to backport changes from trunk to branch. About 30 eclipse projects. svn rv ~50,000.
> I have used the svn merge --record-only option to block the old changes prior to the cvs to svn migration.
> That has helped, as now when I do a Collabnet eclipse merge on a single project, I only get a small number of differences (in the select revisions to merge). Of course, the list of differences is going to grow quickly over time as more is checked into trunk  which isn't ideal (only a few items from trunk are ported back to the branch).
> However, when I select multiple Eclipse projects and use Collabnet eclipse merge to choose the selected revisions, what seems like a bug occurs. Instead of showing only those differences still to be applied (as defined in the shared svnmerge property defined on /branches/branch1), the dialog fetches and displays every revision that affects any file in those projects originally clicked on, starting from rv1. (ie. the svnmerge property is ignored when multiple projects are selected)
> This process of finding all the revisions takes about 5-10 minutes just for 2 eclipse projects, and I'm guessing it will take hours for all 30 projects.
> So, what I don't understand is why you believe that merge across projects is working great. Right now, I would need to right click on each of 30 eclipse projects and navigate the dialog to merge back my change in a reasonable timescale (or write down on a piece of paper as to which projects are affected).
> Am I doing something wrong, or is this a bug?

I am not working in repositories that came from CVS, but I do use some
that pre-dated the merge tracking feature. However, I've mostly
worked with branches that I created post merge tracking. I just
select all the projects in my workspace, right click and choose the
merge option when I do it.

The merge client does not have a bug in the revisions it shows, as it
does not make the decisions. It calls a Subversion API that provides
the revisions (equivalent to the svn mergeinfo command). The number
of projects selected should not slow it down, because the API is only
called once, not once per project. The actual merge is done once per
project, but not the UI of the wizard.

Even if SVN is showing the revisions, if the svn:mergeinfo property is
set on the project it will not try to re-merge those revisions. I am
not sure why it is showing them all, but it may be due to the
svn:mergeinfo being set on the projects, as opposed to /trunk or
/branches/branch1. Again, when the merge runs, it would self exclude
the revisions.

Mark Phippard
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subclipse.tigris.org].
Received on 2009-05-26 15:40:56 CEST

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

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