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

Re: [Subclipse-users] Branch merge issues

From: Mark Phippard <markphip_at_gmail.com>
Date: Fri, 22 May 2009 14:51:26 -0400

On Fri, May 22, 2009 at 12:51 PM, Stephen Colebourne
<scolebourne_at_joda.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-eclipse.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/
------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1047&dsMessageId=2352968
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subclipse.tigris.org].
Received on 2009-05-22 20:51:43 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.