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

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

------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1047&dsMessageId=2353135

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subclipse.tigris.org].
Received on 2009-05-23 12:22:26 CEST