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.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1047&dsMessageId=2353796
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subclipse.tigris.org].
Received on 2009-05-26 15:40:56 CEST