Login | Register
My pages Projects Community openCollabNet

Discussions > users > [Subclipse-users] Branch merge issues

subclipse
Discussion topic

Hide all messages in topic

All messages in topic

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

Author markphip
Full name Mark Phippard
Date 2009-06-11 12:15:58 PDT
Message On Tue, Jun 2, 2009 at 1:58 PM, Mark Phippard<markphip​@gmail.com> wrote:
> I have posted release 1.9.0 of the CollabNet Desktop to the
> "dev-builds" update site.  Here are the URL's:
>
> Eclipse 3.3: http://downloads.ope​n.collab.net/eclipse​/dev-builds/e3.3
> Eclipse 3.4: http://downloads.ope​n.collab.net/eclipse​/dev-builds/e3.4
>
> The 3.4 site should work for Eclipse 3.5
>
> Please give it a try and see if it improves the performance of the
> multi-project merge.  It'd be great if you could post comments here:
>
> http://desktop-eclip​se.open.collab.net/d​s/viewForumSummary.d​o?dsForumId=779

Stephen,

Have not heard from you, have you had a chance to try this? We have
posted a few new builds since then where additional enhancements have
been made to the multi-project support.

--
Thanks

Mark Phippard
http://markphip.blogspot.com/

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

Author markphip
Full name Mark Phippard
Date 2009-06-02 10:58:38 PDT
Message I have posted release 1.9.0 of the CollabNet Desktop to the
"dev-builds" update site. Here are the URL's:

Eclipse 3.3: http://downloads.ope​n.collab.net/eclipse​/dev-builds/e3.3
Eclipse 3.4: http://downloads.ope​n.collab.net/eclipse​/dev-builds/e3.4

The 3.4 site should work for Eclipse 3.5

Please give it a try and see if it improves the performance of the
multi-project merge. It'd be great if you could post comments here:

http://desktop-eclip​se.open.collab.net/d​s/viewForumSummary.d​o?dsForumId=779

Mark


On Tue, Jun 2, 2009 at 10:44 AM, Mark Phippard<markphip​@gmail.com> wrote:
> Just an fyi ... we have made some fixes here that should speed this up
> for you.  I'll be posting a new build later for you to try.  I'll post
> again when it is available.
>
> Mark
>
>
>
> On Thu, May 28, 2009 at 3:49 AM, Stephen Colebourne<scoleb​ourne at joda dot org> wrote:
>>> The command I'd be looking for here is:
>>>
>>> svn mergeinfo --show-revs=eligible http://repo/svn/base/trunk@HEAD
>>> http://repo/svn/base
>>>  /branches/1.0@HEAD
>>>
>>> Note how eclipseprojecta was removed from both.  This is the command
>>> we'd execute to get the eligible revisions to merge for all projects.
>>
>> Here are the results for the svn mergeinfo on the command line:
>>
>> /trunk to /branches/branch1 - quick, correct info for all projects
>>
>> /trunk/project to /branches/branch1/project - quick, correct info for one project
>>
>> /trunk/project to /branches/branch1 - slower, wrong as expected (all revisions since branch created)
>>
>> /trunk to /branches/branch1/project - quick, very slow (~2 minutes), wrong as expected (all revisions from rv1)
>>
>> Based on this, I really believe that the evidence points to Subclipse issuing the wrong command (the fourth one above). But why for me and not for you? Perhaps you could create a build with extra logging?
>>
>> Also I don't see why you wouldn't issue the svn mergeinfo at the level of each of the projects, and union the set of returned revision numbers, as doing it at the base level returns rv numbers that don't affect the selected projects.
>>
>> Stephen
>>
>> --------------------​--------------------​--------------
>> http://subclipse.tig​ris.org/ds/viewMessa​ge.do?dsForumId=1047​&dsMessageId=235​6065
>>
>> To unsubscribe from this discussion, e-mail: [users-unsubscribe@s​ubclipse.tigris.org]​.
>>
>
>
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
>



--
Thanks

Mark Phippard
http://markphip.blogspot.com/

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

Author markphip
Full name Mark Phippard
Date 2009-06-02 07:44:53 PDT
Message Just an fyi ... we have made some fixes here that should speed this up
for you. I'll be posting a new build later for you to try. I'll post
again when it is available.

Mark



On Thu, May 28, 2009 at 3:49 AM, Stephen Colebourne<scoleb​ourne at joda dot org> wrote:
>> The command I'd be looking for here is:
>>
>> svn mergeinfo --show-revs=eligible http://repo/svn/base/trunk@HEAD
>> http://repo/svn/base
>>  /branches/1.0@HEAD
>>
>> Note how eclipseprojecta was removed from both.  This is the command
>> we'd execute to get the eligible revisions to merge for all projects.
>
> Here are the results for the svn mergeinfo on the command line:
>
> /trunk to /branches/branch1 - quick, correct info for all projects
>
> /trunk/project to /branches/branch1/project - quick, correct info for one project
>
> /trunk/project to /branches/branch1 - slower, wrong as expected (all revisions since branch created)
>
> /trunk to /branches/branch1/project - quick, very slow (~2 minutes), wrong as expected (all revisions from rv1)
>
> Based on this, I really believe that the evidence points to Subclipse issuing the wrong command (the fourth one above). But why for me and not for you? Perhaps you could create a build with extra logging?
>
> Also I don't see why you wouldn't issue the svn mergeinfo at the level of each of the projects, and union the set of returned revision numbers, as doing it at the base level returns rv numbers that don't affect the selected projects.
>
> Stephen
>
> --------------------​--------------------​--------------
> http://subclipse.tig​ris.org/ds/viewMessa​ge.do?dsForumId=1047​&dsMessageId=235​6065
>
> To unsubscribe from this discussion, e-mail: [users-unsubscribe@s​ubclipse.tigris.org]​.
>



--
Thanks

Mark Phippard
http://markphip.blogspot.com/

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

Author scolebourne
Full name Stephen Colebourne
Date 2009-05-28 00:50:59 PDT
Message Obvious cut and paste...

> /trunk to /branches/branch1/project - quick, very slow (~2 minutes), wrong as expected (all revisions from rv1)

should be:

/trunk to /branches/branch1/project - very slow (~2 minutes), wrong as expected (all revisions from rv1)

Stephen

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

Author scolebourne
Full name Stephen Colebourne
Date 2009-05-28 00:49:30 PDT
Message > The command I'd be looking for here is:
>
> svn mergeinfo --show-revs=eligible http://repo/svn/base/trunk@HEAD
> http://repo/svn/base
> /branches/1.0@HEAD
>
> Note how eclipseprojecta was removed from both. This is the command
> we'd execute to get the eligible revisions to merge for all projects.

Here are the results for the svn mergeinfo on the command line:

/trunk to /branches/branch1 - quick, correct info for all projects

/trunk/project to /branches/branch1/project - quick, correct info for one project

/trunk/project to /branches/branch1 - slower, wrong as expected (all revisions since branch created)

/trunk to /branches/branch1/project - quick, very slow (~2 minutes), wrong as expected (all revisions from rv1)

Based on this, I really believe that the evidence points to Subclipse issuing the wrong command (the fourth one above). But why for me and not for you? Perhaps you could create a build with extra logging?

Also I don't see why you wouldn't issue the svn mergeinfo at the level of each of the projects, and union the set of returned revision numbers, as doing it at the base level returns rv numbers that don't affect the selected projects.

Stephen

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

Author markphip
Full name Mark Phippard
Date 2009-05-27 10:51:19 PDT
Message On Wed, May 27, 2009 at 1:45 PM, Stephen Colebourne
<scolebourne at joda dot org> wrote:
>> > 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.tig​ris.org/svn/subclips​e/trunk/subclipse@HE​AD
>> > http://subclipse.tig​ris.org/svn/subclips​e/branches/1.4.x/sub​clipse@HEAD
>
> OK. So, if I run from the command line:
>
> svn mergeinfo --show-revs=eligible http://repo/svn/base​/trunk/eclipseprojec​ta@HEAD http://repo/svn/base​/branches/1.0/eclips​eprojecta@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/eclips​eprojecta@HEAD

The command I'd be looking for here is:

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

Note how eclipseprojecta was removed from both. This is the command
we'd execute to get the eligible revisions to merge for all projects.

--
Thanks

Mark Phippard
http://markphip.blogspot.com/

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

Author scolebourne
Full name Stephen Colebourne
Date 2009-05-27 10:45:26 PDT
Message > > 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.tig​ris.org/svn/subclips​e/trunk/subclipse@HE​AD
> > http://subclipse.tig​ris.org/svn/subclips​e/branches/1.4.x/sub​clipse@HEAD

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

svn mergeinfo --show-revs=eligible http://repo/svn/base​/trunk/eclipseprojec​ta@HEAD http://repo/svn/base​/branches/1.0/eclips​eprojecta@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/eclips​eprojecta@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.

Suggestions?

Stephen

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

Author markphip
Full name Mark Phippard
Date 2009-05-27 10:31:26 PDT
Message On Wed, May 27, 2009 at 8:34 AM, Stephen Colebourne
<scolebourne at joda dot org> wrote:
>> 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.tig​ris.org/svn/subclips​e/trunk/subclipse@HE​AD
>> http://subclipse.tig​ris.org/svn/subclips​e/branches/1.4.x/sub​clipse@HEAD
>
> I ran this (from the directory of the working copy of the branch, although I doubt that matters). I > got back the correctly filtered list of revisions after the revision I indicated was merged.

The example I gave above lists the parent folder of the projects I'd
merge into. When merging multiple projects, it'd look at the parent
folder to see what was eligible to merge. It'd be worth trying that
folder in the command.

>> > 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/b​ranches/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.
>
> Yes, those were basically the commands I ran (where MAXREV was the revision just after cvs
> migration). I don't understand why you say they would need to be fully syched before doing this.
> According to the svn 1.5 online manual, all this does is block these revisions from being
> considered. (ie. I'm happy to not have any svn merge features for versions before my MAXREV).

I just meant in order for merge tracking to be accurate. As long as
you are OK with it excluding previous revisions, it should be OK.


>> Finally, keep in mind that SVN automatically knows the "natural
>> history" for a branch.  So if it was created by coping trunk@1000, it
>> already knows that the branch contains r1-1000 from trunk.
>
> Does that mean that the svn:mergeinfo needs to start at rv1000 in your example?

The mergeinfo created by SVN would start after 1000. It would not
create mergeinfo for the "natural history".

> What would be useful info for you to find out what the issue is here?

Not sure.

--
Thanks

Mark Phippard
http://markphip.blogspot.com/

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

Author scolebourne
Full name Stephen Colebourne
Date 2009-05-27 05:34:45 PDT
Message > 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.tig​ris.org/svn/subclips​e/trunk/subclipse@HE​AD
> http://subclipse.tig​ris.org/svn/subclips​e/branches/1.4.x/sub​clipse@HEAD

I ran this (from the directory of the working copy of the branch, although I doubt that matters). I got back the correctly filtered list of revisions after the revision I indicated was merged.


> > 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/b​ranches/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.

Yes, those were basically the commands I ran (where MAXREV was the revision just after cvs migration). I don't understand why you say they would need to be fully syched before doing this. According to the svn 1.5 online manual, all this does is block these revisions from being considered. (ie. I'm happy to not have any svn merge features for versions before my MAXREV).

> Finally, keep in mind that SVN automatically knows the "natural
> history" for a branch. So if it was created by coping trunk@1000, it
> already knows that the branch contains r1-1000 from trunk.

Does that mean that the svn:mergeinfo needs to start at rv1000 in your example?

What would be useful info for you to find out what the issue is here?

Stephen

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

Author markphip
Full name Mark Phippard
Date 2009-05-26 09:04:45 PDT
Message On Tue, May 26, 2009 at 11:40 AM, Stephen Colebourne
<scolebourne at joda dot org> wrote:
>> 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
http://subclipse.tig​ris.org/svn/subclips​e/trunk/subclipse@HE​AD
http://subclipse.tig​ris.org/svn/subclips​e/branches/1.4.x/sub​clipse@HEAD

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/b​ranches/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@1000, it
already knows that the branch contains r1-1000 from trunk.

--
Thanks

Mark Phippard
http://markphip.blogspot.com/

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

Author scolebourne
Full name Stephen Colebourne
Date 2009-05-26 08:40:19 PDT
Message > 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?

> 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.

Stephen

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

Author markphip
Full name Mark Phippard
Date 2009-05-26 07:26:03 PDT
Message On Tue, May 26, 2009 at 10:11 AM, jcompagner <jcompagner at gmail dot com> wrote:
>>
>>
>> > 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 agree with stephen on this one.
>
> We also have this:
>
> trunk/project1
> trunk/project2
>
> and the same 2:
>
> branch/v21/project1
> branch/v21/project2
>
> now i do a commit that spans over the 2 in the branch and i do want to merge
> that (i use the collab merge client)
> then that is 2 actions (and the merge client still have some usability
> issues to be really speedy..)

You are not providing any details as to why selecting the projects and
doing merge does not work for you. It does for me.

> I guess what i need to do is check out the /trunk and the branch/v21 folder
> and then import the projects from the folders as eclipse projects
>
> This didnt work quite well sometime ago but i think that is fixed
> But the other question is if i do that. And i merge on the folder above the
> projects
> and i commit there the i do also commit the svn properties to that dir. What
> happens then if another one does it on the project level?
> Then he doesnt see those properties i guess?

You will have properties at both levels, but SVN handles this in terms
of applying it with merge tracking. It will go to the repository and
find the parent mergeinfo.

> Same for the branches/tags configuration. If i would commit that only on the
> projects parent dir. Would i still see the branch/tag in the history view?

I do not believe this feature looks beyond the project.

> In other works does it go up the tree far enough to look for that kind of
> information or does it stop at the project level (what is a project in
> eclipse)
> (I could say exactly the same for example on the bug traq svn properties.
> Can i commit that on 1 top level dir what is not direct THE project in
> eclipse where i work on?)

This feature also does not look beyond the project. But this feature
is also set once, and by a user. So you can just set it on any
folders where you need it.

--
Thanks

Mark Phippard
http://markphip.blogspot.com/

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

Author markphip
Full name Mark Phippard
Date 2009-05-26 07:25:53 PDT
Message On Tue, May 26, 2009 at 10:11 AM, jcompagner <jcompagner at gmail dot com> wrote:
>>
>>
>> > 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 agree with stephen on this one.
>
> We also have this:
>
> trunk/project1
> trunk/project2
>
> and the same 2:
>
> branch/v21/project1
> branch/v21/project2
>
> now i do a commit that spans over the 2 in the branch and i do want to merge
> that (i use the collab merge client)
> then that is 2 actions (and the merge client still have some usability
> issues to be really speedy..)

You are not providing any details as to why selecting the projects and
doing merge does not work for you. It does for me.

> I guess what i need to do is check out the /trunk and the branch/v21 folder
> and then import the projects from the folders as eclipse projects
>
> This didnt work quite well sometime ago but i think that is fixed
> But the other question is if i do that. And i merge on the folder above the
> projects
> and i commit there the i do also commit the svn properties to that dir. What
> happens then if another one does it on the project level?
> Then he doesnt see those properties i guess?

You will have properties at both levels, but SVN handles this in terms
of applying it with merge tracking. It will go to the repository and
find the parent mergeinfo.

> Same for the branches/tags configuration. If i would commit that only on the
> projects parent dir. Would i still see the branch/tag in the history view?

I do not believe this feature looks beyond the project.

> In other works does it go up the tree far enough to look for that kind of
> information or does it stop at the project level (what is a project in
> eclipse)
> (I could say exactly the same for example on the bug traq svn properties.
> Can i commit that on 1 top level dir what is not direct THE project in
> eclipse where i work on?)

This feature also does not look beyond the project. But this feature
is also set once, and by a user. So you can just set it on any
folders where you need it.

--
Thanks

Mark Phippard
http://markphip.blogspot.com/

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

Author jcompagner
Full name jcompagner
Date 2009-05-26 07:11:57 PDT
Message >
>
>
> > 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 agree with stephen on this one.

We also have this:

trunk/project1
trunk/project2

and the same 2:

 branch/v21/project1
branch/v21/project2

now i do a commit that spans over the 2 in the branch and i do want to merge
that (i use the collab merge client)
then that is 2 actions (and the merge client still have some usability
issues to be really speedy..)

I guess what i need to do is check out the /trunk and the branch/v21 folder
and then import the projects from the folders as eclipse projects

This didnt work quite well sometime ago but i think that is fixed
But the other question is if i do that. And i merge on the folder above the
projects
and i commit there the i do also commit the svn properties to that dir. What
happens then if another one does it on the project level?
Then he doesnt see those properties i guess?

Same for the branches/tags configuration. If i would commit that only on the
projects parent dir. Would i still see the branch/tag in the history view?
In other works does it go up the tree far enough to look for that kind of
information or does it stop at the project level (what is a project in
eclipse)
(I could say exactly the same for example on the bug traq svn properties.
Can i commit that on 1 top level dir what is not direct THE project in
eclipse where i work on?)

johan
Attachments

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

Author markphip
Full name Mark Phippard
Date 2009-05-26 06:40:42 PDT
Message On Tue, May 26, 2009 at 9:26 AM, Stephen Colebourne
<scolebourne at joda dot 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/

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

Author scolebourne
Full name Stephen Colebourne
Date 2009-05-26 06:26:32 PDT
Message > There is a new merge client that replaces Subclipse merge that you can get from CollabNet:
> http://desktop-eclip​​se.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:

/trunk/eclipseprojecta
/trunk/eclipseprojectb
/trunk/eclipseprojectc
/branches/branch1/ec​lipseprojecta
/branches/branch1/ec​lipseprojectb
/branches/branch1/ec​lipseprojectc

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?

Stephen

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

Author markphip
Full name Mark Phippard
Date 2009-05-23 06:16:35 PDT
Message On Sat, May 23, 2009 at 6:22 AM, Stephen Colebourne
<scolebourne at joda dot org> wrote:
>> > My second issue is that the merge is immediate. With CVS, performing a merge will provide a dialog that allows the user to pick and choose which files to merge back.
>> That is how the svn merge command works and there are no plans to change that.
>
> Hmm. Subversion really does lack some basic features. For the use cases I deal with, this makes merge unusable.
>
> At present it seems that the only way to work is to manually generate patch files for every checkin I make, store them on the filing system, and apply them to the branch if needs be later. Thats crazy. Selective merging from trunk to branch should be a basic graphical scm operation.

I appreciate that you and some others feel that way, but I do not
agree, even a little. Not only do I not think it is a basic SCM
feature, it is a recipe for disaster. Instead of letting the tool do
what it was designed to do, you want to let an error-prone user make
all the decisions. Not only does it lead to problems, it is not
scalable. What happens when you are merging thousands of files?


> 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.


>> > My fifth issue is with attempting to use the alternative Compare With option to bring files from TRUNK to the Branch.
>
>> No real comment about the UI. My recollection was that the UI comes entirely from the Eclipse compare plugin and we just provide the data model. Anyway, I could not recommend using an option like this to
> perform "merges" regardless.
>
> Well, CVS manages to show folder differences in the compare with view such that you can select them and copy the folders and files from left to right and vice versa. Given that the merge is unusable, maybe you might consider revisiting the Compare With view?

If someone wants to enhance these features it'd be great. I have no objection.


>> Subversion is not CVS. Get over it or go back to CVS. There is no such thing as "trunk" in Subversion. There might be a folder with that name, but there is no
> guarantee.
>
> I would return to cvs if I could, but svn is now a corporate mandated 'choice'. (I've used svn on open source projects privately for years, but never needed to deal with branches there.)
>
> I've heard this argument about 'trunk' is just another folder many times by svn experts. While this might have once been the case, I don't believe it is a valid representation of how most users use svn.
>
> The problem is that svn started as a tool for developers, mostly in open source, who love typing long command line strings. However, svn is now a mainstream corporate tool used by point and click developers in very standard patterns. What I'm arguing for is for the svn toolset (as a whole) to recognise that shift. I believe that the UI for Eclipse is the most logical place for that to start.
>
> One aspect of the shift is that in most cases there truly is a trunk, used as a trunk, with the name trunk. And that there are branches, used as branches under the folder named branches. This standard setup should be optimised for in the toolset, via dedicated menu options and default.
>
> Thus, there should be a Compare With Trunk dedicated menu item. And the merge tool should default to appropriate values (like comparing the current branch to trunk and selecting the head revision checkbox.
>
> Finally, I'd suggest providing a general URL to name mapping for users. Then users could pick from the names in every location where a URL is currently used. Perhaps it would take the form of storing in each Eclipse project what the defined trunk URL is and the root for branches. Most users would set these. Weird svn users (who use a different scheme without trunk/branch concepts) wouldn't and would just continue to type long URLs.

I've been working with SVN since before 1.0 came out, I've been
working with Subclipse since 0.9.3 release. I have seen a lot of
users, and I can tell you that there is no pattern of usage at all.
This is probably more true in the corporate world you speak of than
anywhere. Often because they had to migrate from another tool. Most
people have a folder named trunk, but it is not always used like a
trunk and the structure varies wildly and in unpredictable ways.

In my experience, the people that have the "classic" setup, the one's
that would be the easiest to support, need this feature the least.
The "classic" setup exists to make the URL's easy to manage and tools
like TortoiseSVN and Subclipse that remember your URL's make it even
easier. The people that need this stuff the most are the hardest to
support.

Finally, Subclipse does have a feature like you asked. It has had it
for years. See:

http://subclipse.tig​ris.org/branch_tag.h​tml

--
Thanks

Mark Phippard
http://markphip.blogspot.com/

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

Author scolebourne
Full name Stephen Colebourne
Date 2009-05-23 03:22:14 PDT
Message > > My second issue is that the merge is immediate. With CVS, performing a merge will provide a dialog that allows the user to pick and choose which files to merge back.
> That is how the svn merge command works and there are no plans to change that.

Hmm. Subversion really does lack some basic features. For the use cases I deal with, this makes merge unusable.

At present it seems that the only way to work is to manually generate patch files for every checkin I make, store them on the filing system, and apply them to the branch if needs be later. Thats crazy. Selective merging from trunk to branch should be a basic graphical scm operation.

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.

> > My fifth issue is with attempting to use the alternative Compare With option to bring files from TRUNK to the Branch.

> No real comment about the UI. My recollection was that the UI comes entirely from the Eclipse compare plugin and we just provide the data model. Anyway, I could not recommend using an option like this to
perform "merges" regardless.

Well, CVS manages to show folder differences in the compare with view such that you can select them and copy the folders and files from left to right and vice versa. Given that the merge is unusable, maybe you might consider revisiting the Compare With view?

> Subversion is not CVS. Get over it or go back to CVS. There is no such thing as "trunk" in Subversion. There might be a folder with that name, but there is no
guarantee.

I would return to cvs if I could, but svn is now a corporate mandated 'choice'. (I've used svn on open source projects privately for years, but never needed to deal with branches there.)

I've heard this argument about 'trunk' is just another folder many times by svn experts. While this might have once been the case, I don't believe it is a valid representation of how most users use svn.

The problem is that svn started as a tool for developers, mostly in open source, who love typing long command line strings. However, svn is now a mainstream corporate tool used by point and click developers in very standard patterns. What I'm arguing for is for the svn toolset (as a whole) to recognise that shift. I believe that the UI for Eclipse is the most logical place for that to start.

One aspect of the shift is that in most cases there truly is a trunk, used as a trunk, with the name trunk. And that there are branches, used as branches under the folder named branches. This standard setup should be optimised for in the toolset, via dedicated menu options and default.

Thus, there should be a Compare With Trunk dedicated menu item. And the merge tool should default to appropriate values (like comparing the current branch to trunk and selecting the head revision checkbox.

Finally, I'd suggest providing a general URL to name mapping for users. Then users could pick from the names in every location where a URL is currently used. Perhaps it would take the form of storing in each Eclipse project what the defined trunk URL is and the root for branches. Most users would set these. Weird svn users (who use a different scheme without trunk/branch concepts) wouldn't and would just continue to type long URLs.

Re: [Subclipse-users] Branch merge issues

Author markphip
Full name Mark Phippard
Date 2009-05-22 10:44:40 PDT
Message On Fri, May 22, 2009 at 12:51 PM, Stephen Colebourne
<scolebourne at joda dot org> wrote:

> My first issue is the complexity of the dialog box. Subclipse makes no effort to understand that the head of TRUNK and the head of the branch are the elements that are important. Instead, each time I go to the dialog I have to select the TRUNK URI at the top, then select the head revision, then unselect the From checkbox, then select the branch URI, and then select the head of the branch. This is a very slow UI, and doesn't map to the meaningful operations in a business scenario.

The dialog could use some TLC if someone wants to take it on. It
reflected pretty much all you could do in the SVN 1.4 timeframe and
was the same as the TortoiseSVN dialog at same time. There is a new
merge client that replaces Subclipse merge that you can get from
CollabNet:

http://desktop-eclip​se.open.collab.net/


> My second issue is that the merge is immediate. With CVS, performing a merge will provide a dialog that allows the user to pick and choose which files to merge back. I can find no equivalent to this in Subclipse.

That is how the svn merge command works and there are no plans to
change that. Subclipse uses Subversion API to do the merge and its
merge tracking feature requires it does the merge. The CollabNet
merge client offers some post-merge UI to help work with the results.


> My third issue is that the merge completes with lots of .prej files, one for every file that has two different revisions (one revision on TRUNK and one on the branch). This is because the repository was just converted from CVS, and the cvs-rev svn property is different between TRUNK and the Branch. I can find no way to ignore this property during the merge process, and it effectively makes merging useless.

Sorry, nothing we can do about this. I recall the cvs2svn docs warn
that it might not be a good idea to use that feature. All I can
suggest is you get rid of those properties. I might even suggest you
write some kind of script to remove them from a dump of your
repository and then reload it.


> My fourth issue is that I have NPE from the completed merge when I attempt to synchronize and then double click to compare the changes. This originally occurred on every attempt to view the file in the compare view, now it doesn't. I don't know what has changed.

If you can come up with a reproduction recipe, let us know. I see
references to a cache, maybe it became corrupt in some way and then
rebuilt itself. Just guessing.

> My fifth issue is with attempting to use the alternative Compare With option to bring files from TRUNK to the Branch. That seems to work fine so long as there are no new folders. However, my change includes new folders, and although this shows up in the compare view, it cannot be actioned, so there is no way to use that view to pull the changes across (as there is in CVS).

No real comment about the UI. My recollection was that the UI comes
entirely from the Eclipse compare plugin and we just provide the data
model. Anyway, I could not recommend using an option like this to
perform "merges" regardless.

> Furthermore, there is no simple, one-click, menu item to compare with the head of TRUNK as there is in CVS. The lack of such basic business led operations as this leads me to question how the authors are managing to use the tool.

I'm managing just fine, thanks for asking. Subversion is not CVS.
Get over it or go back to CVS. There is no such thing as "trunk" in
Subversion. There might be a folder with that name, but there is no
guarantee. And it is possible that you are not treating it like a
trunk. The UI cannot make any assumptions. We remember previous
URL's you've used and provide them in a drop-down dialog. Subversion
itself does not provide an API to a diff of your working copy and a
repository URL, so I'd avoid doing that kind of operation until they
do. You can compare the URL of your working copy with another URL and
get an efficient diff though.

--
Thanks

Mark Phippard
http://markphip.blogspot.com/

[Subclipse-users] Branch merge issues

Author scolebourne
Full name Stephen Colebourne
Date 2009-05-22 09:51:08 PDT
Message Hi,
I've been trying to use Subclipse to merge files and folders without success for a few hours now. I thought I'd write and discuss my difficulties - Subclipse 1.6.2, Java HL 1.6.2 (rv37639), svn repository 1.5.

My basic goal is to merge changes from TRUNK to a branch. I am in the branch workspace, and do a team/merge.

My first issue is the complexity of the dialog box. Subclipse makes no effort to understand that the head of TRUNK and the head of the branch are the elements that are important. Instead, each time I go to the dialog I have to select the TRUNK URI at the top, then select the head revision, then unselect the From checkbox, then select the branch URI, and then select the head of the branch. This is a very slow UI, and doesn't map to the meaningful operations in a business scenario.

My second issue is that the merge is immediate. With CVS, performing a merge will provide a dialog that allows the user to pick and choose which files to merge back. I can find no equivalent to this in Subclipse.

My third issue is that the merge completes with lots of .prej files, one for every file that has two different revisions (one revision on TRUNK and one on the branch). This is because the repository was just converted from CVS, and the cvs-rev svn property is different between TRUNK and the Branch. I can find no way to ignore this property during the merge process, and it effectively makes merging useless.

My fourth issue is that I have NPE from the completed merge when I attempt to synchronize and then double click to compare the changes. This originally occurred on every attempt to view the file in the compare view, now it doesn't. I don't know what has changed.

ENTRY org.eclipse.jface 4 2 2009-05-22 16:41:32.075
!MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.jface".
!STACK 0
java.lang.NullPointerException
    at org.tigris.subversio​n.subclipse.core.res​ources.RemoteResourc​e.equals(RemoteResou​rce.java:154)
    at org.tigris.subversio​n.subclipse.core.res​ources.RemoteFile.eq​uals(RemoteFile.java​:155)
    at org.eclipse.team.cor​e.synchronize.SyncIn​fo.equalObjects(Sync​Info.java:327)
    at org.eclipse.team.cor​e.synchronize.SyncIn​fo.equalNodes(SyncIn​fo.java:319)
    at org.eclipse.team.cor​e.synchronize.SyncIn​fo.equals(SyncInfo.j​ava:277)
    at org.eclipse.team.ui.​synchronize.SyncInfo​CompareInput.equals(​SyncInfoCompareInput​.java:208)
    at org.eclipse.ui.inter​nal.EditorHistoryIte​m.matches(EditorHist​oryItem.java:114)
    at org.eclipse.ui.inter​nal.EditorHistory.re​move(EditorHistory.j​ava:118)
    at org.eclipse.ui.inter​nal.EditorHistory.ad​d(EditorHistory.java​:61)
    at org.eclipse.ui.inter​nal.EditorHistory.ad​d(EditorHistory.java​:51)
    at org.eclipse.ui.inter​nal.EditorManager.op​enEditorFromDescript​or(EditorManager.jav​a:682)
    at org.eclipse.ui.inter​nal.EditorManager.op​enEditor(EditorManag​er.java:639)
    at org.eclipse.ui.inter​nal.WorkbenchPage.bu​syOpenEditorBatched(​WorkbenchPage.java:2​817)
    at org.eclipse.ui.inter​nal.WorkbenchPage.bu​syOpenEditor(Workben​chPage.java:2729)
    at org.eclipse.ui.inter​nal.WorkbenchPage.ac​cess$11(WorkbenchPa​ge.java:2721)
    at org.eclipse.ui.inter​nal.WorkbenchPage$1​0.run(WorkbenchPage.​java:2673)
    at org.eclipse.swt.cust​om.BusyIndicator.sho​wWhile(BusyIndicator​.java:70)
    at org.eclipse.ui.inter​nal.WorkbenchPage.op​enEditor(WorkbenchPa​ge.java:2668)
    at org.eclipse.ui.inter​nal.WorkbenchPage.op​enEditor(WorkbenchPa​ge.java:2652)
    at org.eclipse.ui.inter​nal.WorkbenchPage.op​enEditor(WorkbenchPa​ge.java:2635)
    at org.eclipse.compare.​internal.CompareUIPl​ugin$1.run(CompareU​IPlugin.java:454)
    at org.eclipse.compare.​internal.CompareUIPl​ugin.syncExec(Compar​eUIPlugin.java:1171)​
    at org.eclipse.compare.​internal.CompareUIPl​ugin.internalOpenEdi​tor(CompareUIPlugin.​java:465)
    at org.eclipse.compare.​internal.CompareUIPl​ugin.openEditorInBac​kground(CompareUIPlu​gin.java:436)
    at org.eclipse.compare.​internal.CompareUIPl​ugin.openCompareEdit​or(CompareUIPlugin.j​ava:426)
    at org.eclipse.compare.​CompareUI.openCompar​eEditorOnPage(Compar​eUI.java:135)
    at org.eclipse.team.int​ernal.ui.synchronize​.actions.OpenInCompa​reAction.openCompare​Editor(OpenInCompare​Action.java:210)
    at org.eclipse.team.int​ernal.ui.synchronize​.actions.OpenInCompa​reAction.openCompare​Editor(OpenInCompare​Action.java:169)
    at org.eclipse.team.int​ernal.ui.synchronize​.actions.OpenInCompa​reAction.openCompare​EditorOnSyncInfo(Ope​nInCompareAction.jav​a:149)
    at org.eclipse.team.int​ernal.ui.synchronize​.actions.OpenInCompa​reAction.run(OpenInC​ompareAction.java:62​)
    at org.eclipse.team.int​ernal.ui.synchronize​.actions.OpenWithAct​ionGroup.openInCompa​reEditor(OpenWithAct​ionGroup.java:142)
    at org.eclipse.team.int​ernal.ui.synchronize​.actions.DefaultSync​hronizePageActions$​1.run(DefaultSynchro​nizePageActions.java​:47)
    at org.eclipse.team.int​ernal.ui.synchronize​.StructuredViewerAdv​isor.handleOpen(Stru​cturedViewerAdvisor.​java:171)
    at org.eclipse.team.int​ernal.ui.synchronize​.StructuredViewerAdv​isor.access$0(Struc​turedViewerAdvisor.j​ava:167)
    at org.eclipse.team.int​ernal.ui.synchronize​.StructuredViewerAdv​isor$3.open(Structu​redViewerAdvisor.jav​a:131)
    at org.eclipse.jface.vi​ewers.StructuredView​er$2.run(Structured​Viewer.java:820)
    at org.eclipse.core.run​time.SafeRunner.run(​SafeRunner.java:37)
    at org.eclipse.core.run​time.Platform.run(Pl​atform.java:880)
    at org.eclipse.ui.inter​nal.JFaceUtil$1.run​(JFaceUtil.java:48)
    at org.eclipse.jface.ut​il.SafeRunnable.run(​SafeRunnable.java:17​5)
    at org.eclipse.jface.vi​ewers.StructuredView​er.fireOpen(Structur​edViewer.java:818)
    at org.eclipse.jface.vi​ewers.StructuredView​er.handleOpen(Struct​uredViewer.java:1079​)
    at org.eclipse.jface.vi​ewers.StructuredView​er$6.handleOpen(Str​ucturedViewer.java:1​183)
    at org.eclipse.jface.ut​il.OpenStrategy.fire​OpenEvent(OpenStrate​gy.java:263)
    at org.eclipse.jface.ut​il.OpenStrategy.acce​ss$2(OpenStrategy.j​ava:257)
    at org.eclipse.jface.ut​il.OpenStrategy$1.h​andleEvent(OpenStrat​egy.java:297)
    at org.eclipse.swt.widg​ets.EventTable.sendE​vent(EventTable.java​:84)
    at org.eclipse.swt.widg​ets.Widget.sendEvent​(Widget.java:1003)
    at org.eclipse.swt.widg​ets.Display.runDefer​redEvents(Display.ja​va:3823)
    at org.eclipse.swt.widg​ets.Display.readAndD​ispatch(Display.java​:3422)
    at org.eclipse.ui.inter​nal.Workbench.runEve​ntLoop(Workbench.jav​a:2384)
    at org.eclipse.ui.inter​nal.Workbench.runUI(​Workbench.java:2348)​
    at org.eclipse.ui.inter​nal.Workbench.access​$4(Workbench.java:2​200)
    at org.eclipse.ui.inter​nal.Workbench$5.run​(Workbench.java:495)​
    at org.eclipse.core.dat​abinding.observable.​Realm.runWithDefault​(Realm.java:288)
    at org.eclipse.ui.inter​nal.Workbench.create​AndRunWorkbench(Work​bench.java:490)
    at org.eclipse.ui.Platf​ormUI.createAndRunWo​rkbench(PlatformUI.j​ava:149)
    at org.eclipse.ui.inter​nal.ide.application.​IDEApplication.start​(IDEApplication.java​:113)
    at org.eclipse.equinox.​internal.app.Eclipse​AppHandle.run(Eclips​eAppHandle.java:193)​
    at org.eclipse.core.run​time.internal.adapto​r.EclipseAppLauncher​.runApplication(Ecli​pseAppLauncher.java:​110)
    at org.eclipse.core.run​time.internal.adapto​r.EclipseAppLauncher​.start(EclipseAppLau​ncher.java:79)
    at org.eclipse.core.run​time.adaptor.Eclipse​Starter.run(EclipseS​tarter.java:386)
    at org.eclipse.core.run​time.adaptor.Eclipse​Starter.run(EclipseS​tarter.java:179)
    at sun.reflect.NativeMe​thodAccessorImpl.inv​oke0(Native Method)
    at sun.reflect.NativeMe​thodAccessorImpl.inv​oke(Unknown Source)
    at sun.reflect.Delegati​ngMethodAccessorImpl​.invoke(Unknown Source)
    at java.lang.reflect.Me​thod.invoke(Unknown Source)
    at org.eclipse.equinox.​launcher.Main.invoke​Framework(Main.java:​549)
    at org.eclipse.equinox.​launcher.Main.basicR​un(Main.java:504)
    at org.eclipse.equinox.​launcher.Main.run(Ma​in.java:1236)

!ENTRY org.eclipse.core.jobs 4 2 2009-05-22 16:41:32.416
!MESSAGE An internal error occurred during: "Initializing Compare Editor".
!STACK 0
java.lang.NullPointerException
    at org.tigris.subversio​n.subclipse.core.res​ources.RemoteResourc​e.getCachePath(Remot​eResource.java:228)
    at org.eclipse.team.cor​e.variants.CachedRes​ourceVariant.isHandl​eCached(CachedResour​ceVariant.java:189)
    at org.eclipse.team.cor​e.variants.CachedRes​ourceVariant.isConte​ntsCached(CachedReso​urceVariant.java:156​)
    at org.eclipse.team.cor​e.variants.CachedRes​ourceVariant.ensureC​ontentsCached(Cached​ResourceVariant.java​:110)
    at org.eclipse.team.cor​e.variants.CachedRes​ourceVariant.getStor​age(CachedResourceVa​riant.java:101)
    at org.eclipse.team.int​ernal.ui.synchronize​.RemoteResourceTyped​Element.fetchContent​s(RemoteResourceType​dElement.java:63)
    at org.eclipse.team.int​ernal.ui.StorageType​dElement.cacheConten​ts(StorageTypedEleme​nt.java:53)
    at org.eclipse.team.int​ernal.ui.synchronize​.SyncInfoModelElemen​t.cacheContents(Sync​InfoModelElement.jav​a:185)
    at org.eclipse.team.ui.​synchronize.Abstract​SynchronizeParticipa​nt.prepareCompareInp​ut(AbstractSynchroni​zeParticipant.java:3​26)
    at org.eclipse.team.ui.​synchronize.SyncInfo​CompareInput.prepare​CompareInput(SyncInf​oCompareInput.java:1​75)
    at org.eclipse.team.ui.​synchronize.Saveable​CompareEditorInput.p​repareInput(Saveable​CompareEditorInput.j​ava:239)
    at org.eclipse.compare.​CompareEditorInput.r​un(CompareEditorInpu​t.java:448)
    at org.eclipse.compare.​internal.CompareUIPl​ugin.prepareInput(Co​mpareUIPlugin.java:4​84)
    at org.eclipse.compare.​internal.CompareEdit​or$2.run(CompareEdi​tor.java:314)
    at org.eclipse.core.int​ernal.jobs.Worker.ru​n(Worker.java:55)

My fifth issue is with attempting to use the alternative Compare With option to bring files from TRUNK to the Branch. That seems to work fine so long as there are no new folders. However, my change includes new folders, and although this shows up in the compare view, it cannot be actioned, so there is no way to use that view to pull the changes across (as there is in CVS).

Furthermore, there is no simple, one-click, menu item to compare with the head of TRUNK as there is in CVS. The lack of such basic business led operations as this leads me to question how the authors are managing to use the tool.

Any suggestions to allow me to perform this simple task (merge selected files from TRUNK to branch) are welcome, although I'm not holding out much hope of ever being able to use subversion from Eclipse in a meaningful way right now.
Messages per page: