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

Re: Merge-revert-merge bug?

From: James Y Knight <foom_at_fuhm.net>
Date: Fri, 4 Sep 2009 09:49:32 -0400

On Sep 3, 2009, at 9:10 PM, Stefan Sperling wrote:

> On Thu, Sep 03, 2009 at 06:59:51PM -0400, James Y Knight wrote:
>> There's no easy way to recover except to revert the whole
>> merge, remove the files in the way, and try again.
> It's not that hard to write a small script that cleans obstructions
> from your working copy automatically. The most naive approach would
> be svn status | grep ^\? | awk '{print $2}' | xargs rm

Yes, this is basically what I do to remove the files in the way. It's
a bit annoying, because I do need to make sure I don't have any
important unversioned files in my working-copy first. Whereas, if
subversion simply renamed them out of the way automatically of an
incoming merge or raised a tree-conflict for me to deal with, I
wouldn't have to do any of this, and wouldn't have to worry about
accidentally deleting some important file.

> Of course, Subversion could be enhanced to make it easier to prune
> unversioned files from the working copy. I think such a feature could
> be useful if it was well designed.

I wouldn't really find that useful, if the merge skipping behavior was

> And why are you merging into a working copy that contains
> obstructions in the first place even though you know Subversion
> can't handle this? Even if the alternative of cleaning unversioned
> files first is a pain, isn't the botched merge a much bigger pain?

I don't do it on purpose! Mistakes happen, and it seems that this one
is particularly easy to make. It ususally goes something like this:

Merge. "Oops I meant to merge more/less revisions". Revert. Merge
again. Overlook the "Skipped n files" at the end of the output.
Compile the software, run all the tests -- they all pass, yay! Commit.
D'oh, notice that a bunch of files weren't going to be committed.

> Also, the 1.6 command line client prints a conflict summary at the
> end up an update or merge, and will also report the number of paths
> which were skipped during the operation. This prevents such vital
> information from being overlooked in all the output.

Yes, this is certainly an improvement. Before 1.6, it was almost
*guaranteed* I wouldn't notice, because the "Skipped" messages were
lost in a sea of output. In 1.6, it's at least printed at the end
where it's possible I'll not overlook it. :)

> As explained in the thread you linked to, even though there was a
> small period of time were the code did flag obstructions as tree
> conflicts, we later (before release) deliberately decided not to flag
> obstructions as tree conflicts because they are *unversioned* files
> lying around which Subversion has no information about in its meta
> data
> and has no business making any decisions about apart from leaving them
> alone.
> So that's alright.

Well, it's not really alright -- I'm going to go out on a limb and
state that failing to commit a file with a merge just because a same-
named file existed in the working copy of the person doing the merge
is *never* the desired result.

I'd say this is my number one problem with the UI in svn 1.6. (Now
that the rest of the issues with merging are basically solved, hooray!)

> What we do need to try is producing less obstructions where possible:
> http://subversion.tigris.org/issues/show_bug.cgi?id=3101

Yes, that would be wonderful to do, too. But I don't think that's a
substitute for solving the "skipped" issue -- just a way to make it
happen less often.



To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-04 15:50:35 CEST

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

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