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
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. Some questions a design for this
should answer would be, for example:
- Why this is better to have built-in rather than in an ad-hoc script?
- What does it do if deletion doesn't work?
- Does it rename or really delete files, or either?
- How does it make sure that it is only deleting unversioned files?
* What does it do with ignored files?
* What does it do with symlinks pointing to or inside unversioned items?
* What does it do with unversioned items in directory externals?
- What does the user interface for this feature look like?
- What does the interface do to prevent accidental data loss as much
as possible?
Or maybe a --remove-added-files-from-disk flag to svn revert,
or an interactive prompt ("Delete foo.c from disk? (yes/no) "),
would help?
> And if you don't
> notice the skipped message, svn lets you commit the bad merge, and
> then it's *really* annoying to recover from.
Not quite as annoying as recovering from losing a file entirely
because it only existed locally and Subversion has deleted it.
That's why svn revert does keep added items on disk.
That's why it is causing obstructions.
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?
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.
And you *are* watching the screen while working, right?
At least when the command has completed? :)
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.
What we do need to try is producing less obstructions where possible:
http://subversion.tigris.org/issues/show_bug.cgi?id=3101
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2390896
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-04 03:13:04 CEST