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

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

From: Stephen Colebourne <scolebourne_at_joda.org>
Date: Wed, 27 May 2009 10:45:26 -0700 (PDT)

> > Here is an example that shows the eligible revs from the Subclipse
> > trunk that can be merged to the Subclipse 1.4.x branch.
> >
> > $ svn mergeinfo --show-revs=eligible
> > http://subclipse.tigris.org/svn/subclipse/trunk/subclipse@HEAD
> > http://subclipse.tigris.org/svn/subclipse/branches/1.4.x/subclipse@HEAD

OK. So, if I run from the command line:

svn mergeinfo --show-revs=eligible http://repo/svn/base/trunk/eclipseprojecta@HEAD http://repo/svn/base/branches/1.0/eclipseprojecta@HEAD

I get an accurate set of results near instantly.

However, if I run from the command line:

svn mergeinfo --show-revs=eligible http://repo/svn/base/trunk@HEAD http://repo/svn/base/branches/1.0/eclipseprojecta@HEAD

(note the missing eclipseprojecta) then I get a slow response consisting of every revision in the repository. (Which is of course the result we'd expect for this 'wrong' command')

The response time isn't as slow as a multi-project merge in the Collabnet merge client, but if this wrong command were run once for each eclipse project, then the total time would be about right.

Further info: If the Collabnet merge client is used to merge one project, then the results are the 'correct' set.

If the Collabnet merge client is use to merge two (or more) eclipse projects, lets say a and b, then the offered revisions are not in any way filtered to projects a and b. In other words, they include revisions that only affect projects c, d and e.

As a result, I can pick a revision that only affected c, and the merge client will attempt to apply that revision via a merge to a and b, which obviously has no effect.

I can't really see anything special in my Eclipse setup. Each eclipse project points to part of a full checkout from /branches/1.0, so there is no issue with the working copy that I can see.

Thus far, the only way to reproduce the issue I have at the command line is by issuing the wrong command that compares the shared base folder with the specific eclipse project sub-folder. Unfortunately, Collabnet/Subclipse doesn't log the svn mergeinfo command, so I can't prove that the command being sent from Subclipse is wrong. But I can't find any other explanation.




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