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

Re: Feature Request: merge by drag

From: Stefan Hett <stefan_at_egosoft.com>
Date: Thu, 14 Apr 2016 11:25:52 +0200

Hi,
> On 5/12/2015 01:05, Ilya Nenashev wrote:
>> Some times I'm working in a one branch in a one working copy and want merge commited changes into working copy of trunk or other branch.
>> I very happy when by drag'n'drop by right mouse button I have "SVN Copy and rename versioned item here" command etc, but I will more happy, if there are will be also "Merge versioned item's changes" for files and folders!
> That's not really a good idea.
>
> Merges in SVN are intended to operate on entire revisions, whereas by dragging files around you are implying that you want it to operate on only those files that are dragged.
>
> Even if this were possible, it would significantly mess up the revision-based merge tracking.
>
> It could almost make sense if the folder being dragged is the root of the working copy, but the problem with this is that there'd be no way to specify the range of revisions that should be merged, and things get even more confusing if multiple folders were dropped.
Personally I find this idea quite appealing, when thinking about it from
a "root-folder" point of view (aka: drag+drop one WC (which is a
checkout of proj/branches/branch_x) onto another WC (which would be a
checkout of proj/trunk) and be presented with the option to merge
everything from the other WC (branch) into the other one (trunk).
Basically a shortcut of what I currently do via the merge dialog.

I think it would make sense to restrict scope of the initial feature to
imply that drag+drop would result in merging all revisions up to the
revision of the checked-out branch-WC (rather than HEAD) and do not
attempt to "merge" non-checked-in files from the other WC.
Also for the first iteration it would already be beneficial, even if no
dialog pops up to provide a way to tweak the revisions to merge (which
certainly would be ideal - part of the work would have already been done
anyway since I assume that the existing merge dialog where you select
the revision ranges could be reused, no?).

While personally I doubt I would use the feature on a per
file/subdirectory (or better said: non-root-branch) level, I don't see
why this would technically have to be restricted. SVN supports merging
on a sub-path or even file basis, and if someone chooses to do so, why
should TSVN restrict that? The downsides should be obvious to the user,
but I don't know all the different use-cases/workprocesses of all TSVN
users. :-)

Please note that while what you state (aka: merging on a revision basis
rather than on a per file+revision basis) I also consider good practice
in SVN, SVN actually does support merging on a file+revision level.

-- 
Regards,
Stefan Hett
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3169129
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2016-04-14 11:26:05 CEST

This is an archived mail posted to the TortoiseSVN Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.