You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(From the mailing list)
Hi,
currently, daisydiff only supports comparing one revision of a file with another
revision. One revision will be regarded as the "old" version, the other as the
"new" version. Content overwritten by the new version will be displayed in
red, strike-through, the new content is displayed in green.
This works well if the history of a file is linear and the file cannot be edited
concurrently by multiple persons. With revision control systems, you typically
have three versions to compare:
- the revision that was checked out (ancestor)
- the revision with the local changes
- the current remote revision in the revision control system
In this case, the changes to be displayed are always against the ancestor, so
there may be "old" and "new" changes created by the local revision, as well as
"old" and "new" changes created by the current remote revision. These together
can lead to "conflicting" changes.
Attached is an initial (working) patch for daisydiff to support this scenario.
3-way comparison is already supported by org.eclipse.compare, only daisdiff
needed some additional things. I implemented this against daisydiff 1.1, but
ported it to trunk.
Some constraints with the current version:
- 3-way comparison is currently only available by API (i.e. HTMLDiffer.diff() --
should probably also be added to the Differ interface at least)
- conflicting changes are reported as new and old changes, although most of the
code for conflict detection and formatting is already there
I'd appreciate any feedback.
Cheers,
Carsten
Original issue reported on code.google.com by kkape...@gmail.com on 16 Aug 2010 at 1:15
We're using the three-way diff internally for almost a year now and it works
pretty well.
It also doesn't affect the behavior of the two-wa diff, so I just committed it
to trunk.
Original comment by pfeif...@kde.org on 17 Jun 2011 at 3:10
Original issue reported on code.google.com by
kkape...@gmail.com
on 16 Aug 2010 at 1:15Attachments:
The text was updated successfully, but these errors were encountered: