You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by ogge dask <mt...@yahoo.se> on 2009/09/01 05:58:02 UTC
Merge-revert-merge bug?
I have found a potential bug, in any case it doesn't behave as expected:
Steps to reproduce:
1. Merge a branch that adds new files.
2. Revert the working copy, now the added files remain but are not marked as added any more.
3. Merge same branch again. Now the files that are already there from the first merge, are skipped and not added.
Is that the desireable effect? In my scenario it isn't since I missed some files in the commit.
/Calle
Version info (on Vista x64):
TortoiseSVN 1.6.5, Build 16974 - 64 Bit , 2009/08/20 08:13:46
Subversion 1.6.5,
apr 1.3.8
apr-utils 1.3.9
neon 0.28.6
OpenSSL 0.9.8k 25 Mar 2009
zlib 1.2.3
__________________________________________________________
Låna pengar utan säkerhet. Jämför vilkor online hos Kelkoo.
http://www.kelkoo.se/c-100390123-lan-utan-sakerhet.html?partnerId=96915014
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2389657
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Merge-revert-merge bug?
Posted by Mark Phippard <ma...@gmail.com>.
On Fri, Sep 4, 2009 at 9:20 AM, Bob Archer<bo...@amsi.com> wrote:
>> 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:
>
> FYI: TortoiseSVN has this feature. You just shift-right-click on the folder, then select TSVN -> Delete
> Unversioned Items... it brings up a dialog with all the unversioned items with all selected by default. You
> can click OK or you can unselect some first. Works very well.
The CollabNet Merge client we wrote for Eclipse also has this. There
is an "Undo Merge" option that runs a recursive revert and then shows
you any unversioned folders/files and will delete them for you.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2391015
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Merge-revert-merge bug?
Posted by Bob Archer <bo...@amsi.com>.
> 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:
FYI: TortoiseSVN has this feature. You just shift-right-click on the folder, then select TSVN -> Delete Unversioned Items... it brings up a dialog with all the unversioned items with all selected by default. You can click OK or you can unselect some first. Works very well.
BOb
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2391013
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Merge-revert-merge bug?
Posted by James Y Knight <fo...@fuhm.net>.
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@subversion.tigris.org].
Re: Merge-revert-merge bug?
Posted by Stefan Sperling <st...@elego.de>.
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@subversion.tigris.org].
Re: Merge-revert-merge bug?
Posted by James Y Knight <fo...@fuhm.net>.
On Sep 1, 2009, at 10:51 AM, Tyler Roscoe wrote:
> On Tue, Sep 01, 2009 at 05:58:02AM +0000, ogge dask wrote:
>> Steps to reproduce:
>> 1. Merge a branch that adds new files.
>> 2. Revert the working copy, now the added files remain but are not
>> marked as added any more.
>
> Right here, you are no longer merging into a clean working copy. "svn
> status" will show this.
>> 3. Merge same branch again. Now the files that are already there
>> from the first merge, are skipped and not added.
>>
>> Is that the desireable effect? In my scenario it isn't since I
>> missed some files in the commit.
See also thread:
http://svn.haxx.se/users/archive-2009-02/0450.shtml
> Imagine a scenario where you added files to your working copy (you
> haven't svn add'ed them yet, but that doesn't matter) and then a merge
> wants to add files with the same names. Do you want Subversion to
> clobber your existing files with new files from the merge? Or do you
> want it to warn you and not delete files from your working copy?
>
> I want the second behavior because I don't like losing stuff. And
> that's
> what svn does!
Unfortunately, svn's current behavior *does* cause you to lose stuff:
you lose files from the merge. I'd much prefer if svn would either:
1) mark the files as conflicted so I can't commit, and let me use "svn
resolve" to choose the new ones.
2) rename the existing files out of the way to whatever.svn-backup.1
or so.
I can't count the number of times I've screwed up a merge commit due
to this bug. There's no easy way to recover except to revert the whole
merge, remove the files in the way, and try again. 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.
James
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2390849
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Merge-revert-merge bug?
Posted by Tyler Roscoe <ty...@cryptio.net>.
On Tue, Sep 01, 2009 at 05:58:02AM +0000, ogge dask wrote:
> Steps to reproduce:
> 1. Merge a branch that adds new files.
> 2. Revert the working copy, now the added files remain but are not marked as added any more.
Right here, you are no longer merging into a clean working copy. "svn
status" will show this.
> 3. Merge same branch again. Now the files that are already there from the first merge, are skipped and not added.
>
> Is that the desireable effect? In my scenario it isn't since I missed some files in the commit.
Imagine a scenario where you added files to your working copy (you
haven't svn add'ed them yet, but that doesn't matter) and then a merge
wants to add files with the same names. Do you want Subversion to
clobber your existing files with new files from the merge? Or do you
want it to warn you and not delete files from your working copy?
I want the second behavior because I don't like losing stuff. And that's
what svn does!
tyler
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2389780
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].