On Tue, May 26, 2009 at 11:40 AM, Stephen Colebourne
>> 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).
> So, how do we find out what is wrong? Can I simulate this on the command line and provide
> more info?
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
Subclipse runs the same API as this command and then has to follow it
up with a second API to get the details of those revisions. Basically
svn log -r HIGH:LOW
>> 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.
> I've tried it with the svn:mergeinfo only on /branch1, and on /branch1/eclipseprojecta and
> /branch1/eclipseprojectb. In both scenarios, a multiproject merge brings back every revision
> and takes a loong time.
When you ran the merge to set the mergeinfo, was it something like this?
$ svn co url://server/repos/branches/branch1
$ cd branch1
$ svn merge --record-only -r1:MAXREV ^/trunk
Where MAXREV is the max revision from trunk that you knew was merged
to the branch? You could really only use --record-only if you
typically fully-synch the trunk revisions to the branch and you knew
it had all of the trunk changes up to some revision.
Finally, keep in mind that SVN automatically knows the "natural
history" for a branch. So if it was created by coping trunk_at_1000, it
already knows that the branch contains r1-1000 from trunk.
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subclipse.tigris.org].
Received on 2009-05-26 18:04:56 CEST