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
fixed.
> 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.
James
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2391020
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-04 15:50:35 CEST