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

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

From: Mark Phippard <markphip_at_gmail.com>
Date: Sat, 23 May 2009 09:16:34 -0400

On Sat, May 23, 2009 at 6:22 AM, Stephen Colebourne
<scolebourne_at_joda.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.tigris.org/branch_tag.html

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1047&dsMessageId=2353163
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subclipse.tigris.org].
Received on 2009-05-23 15:16:46 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.