Opened 4 years ago
Last modified 3 years ago
#20006 new defect
Merge layer: specific order of layers needed to find conflicts
Reported by: | skyper | Owned by: | team |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | Core | Version: | latest |
Keywords: | template_report merge layer revert conflict | Cc: |
Description (last modified by )
I found this in #8948, see my comment 3.
What steps will reproduce the problem?
- open attached file (Layer A)
- select all objects
- revert selection from changeset 16833418.
- duplicate layer A (-> Layer B)
- update data of layer A
- get 28 conflicts (13 ways, 15 nodes)
- download the area to new layer (Layer C)
- merge layer B on layer C
What is the expected result?
Conflicts after 3. or at least after 7..
What happens instead?
No conflicts and no object is modified after 7.. Changes of layer B are silently dropped.
Please provide any additional information below. Attach a screenshot if possible.
I only get conflicts with "update data" but there should be conflicts or is this a (new) feature. At least no changes and no conflicts after 7. seems strange.
Merging Layer C on Layer B creates the expected conflicts.
Reverter plugin used to create conflicts but I think it is a new feature if properly documented if it does not.
In my eyes, merging layers needs to create conflicts independent-less on the order as unlike conflicts with server data both layers can have contradicting changes and both are "my" versions.
I remember to have had similar issues when working offline with small overlapping extracts and then merging several modified extracts before upload.
Relative:URL: ^/trunk Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b Last:Changed Date: 2020-10-29 00:51:28 +0100 (Thu, 29 Oct 2020) Revision:17279 Build-Date:2020-10-29 02:30:54 URL:https://josm.openstreetmap.de/svn/trunk Plugins: + reverter (35579)
Attachments (0)
Change History (9)
comment:1 by , 4 years ago
Description: | modified (diff) |
---|
comment:3 by , 4 years ago
Description: | modified (diff) |
---|
comment:4 by , 4 years ago
target <-> my <-> choosable within merge layer dialog (will stay)
source <-> their <-> selected layer merge is executed from (will vanish with merge layer)
comment:5 by , 3 years ago
Priority: | normal → major |
---|
Damn, I totally forgot about this ticket and was wondering why I missed some changes while editing the last days. Instead it is JOSM silently dropping my changes.
My work flow is:
- working in layer A with changes
- find a modified relation with more problems
- Select relation and all members and merge these object to new layer B
- In layer B, download all members
- Revert only the relation to an older version
- Sort and fix members
- Select all modified objects in layer B and merge selected objects to layer A
- Get conflict aabout relation which at least misses some changes in tags (have to recheck what exactly)
follow-up: 9 comment:7 by , 3 years ago
Can you explain why you expect conflicts from step 3 in the original description? Do you think that reverter should verify if the server already has a newer version of anything that is possibly reverted?
comment:8 by , 3 years ago
Description: | modified (diff) |
---|
comment:9 by , 3 years ago
Replying to GerdP:
Can you explain why you expect conflicts from step 3 in the original description? Do you think that reverter should verify if the server already has a newer version of anything that is possibly reverted?
Replying to skyper:
Reverter plugin used to create conflicts but I think it is a new feature if properly documented if it does not.
I think this was the old behavior. I can understand that checking on the server and creating all the conflicts is not what we want here. At least with incomplete objects we get problems, though. The conflicts will come up sooner or later but I like to have them as late as possible as otherwise I will have to solve the identical/similar conflicts about the same object over and over again merging modified data.
I have to find some time to look into all these problems with merging objects or layers and conflicts, again.
When merging layers I always miss the ability to say something like "if in doubt, prefer this layer" or maybe "considers this layer as mine and the other as theirs". Maybe that's because I don't know how it works in other programs. For me, multiple layers edit layers just mean double trouble, so I try to avoid them. But my case is very special because I often use JOSM to analyse special cases where I have a layer with a huge amount of objects and try to extract the data that is needed to reproduce a problem in mkgmap or JOSM.
Edit: Just understood it. The dialog asks for a "target layer". The source in
DatasetMerger
uses "target" and "source" and when you download data from server it will be the source and the existing (possibly empty) layer will be the target.