Indeed I do! Using SVN 1.7.5 on Mac OS X, I get the same results when I resolve via the command line. foo.txt and foo.txt.edited remain.
> Thanks for the recipe.
>
> Do you have SVN 1.7 command line handy? If so, can you run step 12
> using the command line?
>
> $ svn resolve --accept=working foo.txt
>
> I want to see if the command line removes the file. If it does not,
> then we should report it to SVN or get clarification as to why it does
> not.
>
> Anyway, I will probably try to do the same.
>
>
>
> On Tue, Nov 6, 2012 at 2:43 PM, Matthew Hall <ioeth dot trocolar at gmail dot com> wrote:
> > I've recently upgraded to using Eclipse 4.2 and Subclipse 1.8, which is a fantastic combination as ever, but has presented me with one small problem. After resolving merge conflicts, Subclipse is leaving files with the extension ".edited" around in developers' workspaces, which are erroneously making it into the SVN repository.
> >
> > I'd really like to either prevent these .edited files from being generated or allow them to be automatically deleted after resolving the merge conflict, but have been unsuccessful in doing so.
> >
> > Below are steps that can be followed to reproduce the problem. Please note that even though the example uses an Update to HEAD operation to force a merge conflict, regular merge operations present me with the same results.
> >
> > 1. Ensure that the Update to HEAD function of Subclipse is configured to "Mark conflicts, let me resolve them later" for Text files. This can be configured under Eclipse Preferences > Team > SVN > Update to HEAD.
> > 2. Create a new project in Eclipse.
> > 3. Add a new file named "foo.txt" in the project root with the following contents:
> > This is a test.
> > What I'm trying to do is to generate a merge conflict.
> > Hopefully this will do it.
> > 4. Share the project via Subclipse, making sure to add foo.txt.
> > 5. Outside of Eclipse, modify foo.txt so that it reads:
> > This is a test.
> > I'm trying to generate a merge conflict.
> > Hopefully this will do it.
> > 6. Commit the changes to foo.txt outside of Eclipse.
> > 7. Open foo.txt in Eclipse without performing an SVN update.
> > 8. Modify foo.txt in Eclipse so that it reads:
> > This is a test.
> > Hopefully this will do it.
> > 9. Save foo.txt and perform an SVN Update (right-click Team > Update to HEAD) in Eclipse.
> > 10. At this point, foo.txt should be marked as conflicted and the following files should have been generated:
> > foo.txt.edited
> > foo.txt.mine
> > foo.txt.r2
> > foo.txt.r3
> > 11. Edit the conflicts on foo.txt (right-click Team > Edit Conflicts...) and save without making any changes.
> > 12. Mark the conflict on foo.txt resolved (right-click Team > Mark Resolved...) and select "Conflicts have been resolved in the file".
> > 13. At this point, foo.txt.mine, foo.txt.r2, and foo.txt.r3 are removed but foo.txt.edited remains in an unversioned state.
> >
> > Thanks for the help!
> >
> > ------------------------------------------------------
> > http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1047&dsMessageId=3026409
> >
> > To unsubscribe from this discussion, e-mail: [users-unsubscribe at subclipse dot tigris dot org].
>
>
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1047&dsMessageId=3026411
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subclipse.tigris.org].
Received on 2012-11-06 20:52:55 CET