[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: Stephen Colebourne <scolebourne_at_joda.org>
Date: Tue, 26 May 2009 06:26:32 -0700 (PDT)

> There is a new merge client that replaces Subclipse merge that you can get from CollabNet:
> http://desktop-eclip%e2%80%8bse.open.collab.net/

OK, I've tried this, and its a lot more usable than the standard merge. But why is it so hidden? Surely it should be part of the standard subclipse? I would never have found it without writing to this forum.

> > One further point on this is that the merge function in subclipse doesn't work across projects in eclipse (where the eclipse projects are all within one trunk/branch). Again, this makes merge pretty unusable.
> You just described the structure of every project I've ever worked on.
> Not only is merge not unusable, I think it works great. I've never
> had a problem doing this, even before merge tracking.

I do have a real issue with this now.

My setup is as follows:


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?



To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subclipse.tigris.org].
Received on 2009-05-26 15:26:45 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.