Community
Participate
Working Groups
Build Identifier: M20110909-1335 If there are conflicts on properties (for instance: the remote latest revision has deleted a property, while your local copy has changed the value of the same property) Subversive marks the folder that owns that property as a conflict. However: - there is no "Edit properties conflict" option in the context menu - "Mark as merged" has no effect I had to use an external client (TortoiseSVN) to solve a conflict on a property. Reproducible: Always
Since there already exists "Edit Conflicts" action there is no need to create a separate one (see bug #370072 and bug #370071). "Mark As Merged" action in Team Menu now should be applicable not only to files, but to folders also.
Fixed.
Thank you Alexander! Will it be available on the early access update site?
Yes, I'll publish early access site after SVN 1.7 support is implemented (it is about 80% done now).
Sorry Alexander, I'm using Subversive 1.0.0.I20120803-1700 with SVNKit 1.7.5.v1 3.0.0.I20120818-1700 and still have problems here. I have a conflict on the properties of a folder. This conflict is correctly outlined by Subversive, but when I click on "Edit conflicts" I get a dialog that simply says "There are no differences between the selected inputs". It seems like it tries to open a conflict editor for *contents*, but the conflict is on *properties*. So, I see no progress here: I must use an external SVN client to resolve this kind of conflicts.
(In reply to comment #5) Hello, I did performed all the steps and everything worked fine. Is there some specific to the properties you've set or something else that could prevent me from reproducing the situation? P.S. What I did was the following: 1) Case A: - define property A on folder/file in workspace W1 with value B - define property A on folder/file in workspace W2 with value C - commit workspace W1 - update workspace W2, get conflict - call Edit Conflicts 2) Case B: - define property A on folder/file in workspace W1 with value B - commit workspace W1 - update workspace W2 - redefine property A on folder/file in workspace W1 with value D - redefine property A on folder/file in workspace W2 with value C - commit workspace W1 - update workspace W2, get conflict - call Edit Conflicts Did I miss something?
Your use cases seem valid to me. The difference in my case was that the conflict was generated by a merge operation. Something like this: - consider trunk and branch B, with B born from trunk - define property A on folder/file in workspace W1 (trunk) with value B - define property A on folder/file in workspace W2 (branch B) with value C - commit workspace W1 - commit workspace W2 - merge from the trunk on W2, get conflict - call Edit Conflicts The property on which the conflict occur was svn:ignore.
Thank you for suggesting me the correct test case. It is a bug that is caused by incorrect behaviour of the property conflict editor. Since this report was a feature one, I'll open a new report for the issue: bug #390168.
