Názory k článku Nástroje pro porovnání obsahu tří různých verzí textových souborů

Meld jsem používal i na Windows, ale nezávisle na OS je bohužel velmi náročný na fyzické prostředky, zvlášť u větších diffů. Na druhou stranu ale umí i porovnání složek (též trojcestné) a podobné vychytávky.
Po přečtení článku (mmch velmi užitečného) se mi zamlouvá KDiff3. Asi jej zkusím, třeba nebude takový žrout paměti.

to nebudou zdrojaky ze? nejake JSON/XML exporty databaze? Ptam se proto, ze mame serializaci v XML a tam nevim, co pouzit na soubory o velikostech v radu jednotek a desitek MB.

hmm asi si to dokazu predstavit. Takovej ten typ projektu, kterej uz ani nikdo nechce refaktorovat, aby se neuspinil a chodi se okolo toho po spickach? Bohuzel jsem to taky zazil...

Na win dpoporucuju WinMerge jp https://github.com/sdottaka/winmerge-v2/. Je to fork Puvodniho WinMerge ktery zvlada mj i 3way merge.

Xxdiff je jinak super, bohužel ho zabíjí to, že nepodporuje unicode. Takže zbejvá vimdiff ;-) Obecně mi přijde klíčový mít při mergování čtyři okna, tj. zvlášť originál a výsledek merge.

to je pravda, ja si taky zpocatku rikal, proc mi Meld (jinak graficky nejpovedenejsi) pripadne pri praci "nebepecny" a bylo to tim, ze se vlastne menil puvodni soubor.

JetBrains mají ve svých IDE velmi dobrý diff/merge tool. Dá se i spouštět přímo z cmdline https://www.jetbrains.com/help/idea/running-intellij-idea-as-a-diff-or-merge-command-line-tool.html

Zatím nejlepší co jsem našel je p4merge. Stejně dobré výsledky jako placený Beyond Compare a o dost lepší než kdiff3.

Jo cekal sem ze bude v clanku i P4 Merge. Neni sice opensource, ale je to multiplatformni freeware tak co.

Nevadi, jen tak dal :-)

Nevíte, jak P4M přinutit, aby provnávalo i ZIP soubory, umělo UTF a správně porovnalo XML per TAG?

Podporované binární formáty jsou pouze obrázky a word dokumenty, zip neumí.
Utf-8 to má by default, teda aspoň u mne v macOS. Každopádně v menu si to umíš přepnout (File->Character Encoding).
Co se týče XML netuším co řešíš, prostě to porovnává textově, maximálně umí relaxnout whitespaces. Když přehodíš pořadí atributů v xml tagu u dvou souborů, tak jasně že ukáže rozdíl.

Díky, chápu. Ten ZIP právě BC umí, takže volba je jasná. To UTF je pravda, když dám systém default, tak to jede dobře, takže asi nemám všude UTF. To je fuk.
S tím XML jsem narážel na komparaci zarovnaných XML versus nezarovnaných. Třeba něco dělám blbě, ale v BC mi to (nejspíš) nejprve zarovná oba a pak comparuje, takže rozdíl je fakt jen při ADD/MOVE u tagu/hodnoty, teĎ mi to prostě střílí, že celej string je jiný od druhýho (ten první je nezarovnaný v jednom řádku...)
OK, jdu hledat další komparátory, než si BC koupím :-p

Meld jsem používal pro kontrolu, když jsem se snažil napsat vlastní 3-way merge (pro pochopení, jak funguje). Dostal jsem se do stavu, kdy můj primitivní na koleni za jedno odpoledne vyrobený nástroj dával výrazně menší konflikty (správné, srovnatelné s výsledky git merge) než právě meld - něco je v tom programu nejspíš špatně...

Tak hurá s tím seznámit lidi od meldu, pošli jim tvrdý data a zdrojáky... Jen jestli v tom nebude nějaký háček (jakože prakticky jistě bude).

OT Možná pouze obsahuje znak = , který má patentovaný nějaký nejmenovaný korporát. ;-)

Můžete někdo napsat zkušenosti, kdy je potřeba 3-diff, kromě notoricky známých případů? Notoricky známé případy jsou: 1. legacy projekt po někom, kdo není z nejbystřejších, 2. nezvládnutý management zdrojáků, 3. levá ruka neví, co dělá pravá.

Zatím jsem díky bohu 3-diff moc nepotřeboval, i v případě kombinací bodů uvedených výše to byly soubory s malým počtem změn, takže to šlo i okometrickou metodou.

ty jsi nikdy neřešil merge conflict v nějakém VCS (dneska asi nejčastěji v GITu)? Tak asi děláš na projektu, na kterém se podílí málo vývojářů ne?

Taky backporting patchů vede na nutnost třícestného diff+merge. I když tady je potom zajímavá filozofická debata, co je vlastně považováno za předka - tady to je spíš nová verze bez aplikovaného patche.

to je pravda, staci si vyzkouset, kolik si sezere Atom (jinak fajn editor) za systemove prostredky pri otevreni jen trosku vetsiho AsciiDocu nebo DocBooku. Na zdrojaky ho nepouzivam, ale i 100kB dokument ho dost rozhodi (osmijadro i7, 4 GB RAM). Emacs mozna zral hodne kdyz jsem na linuchu zacinal (prvni Pentia, dobihaly i 486, 8 MB RAM byl luxus), dneska to je malickost.