Systemy kontroli wersji mają to do siebie, że otwierają przed nami, programistami (nie tylko zresztą), piękne możliwości. Niestety niektóre z narzędzi zamiast życie ułatwiać – utrudniają. Fajnie podsumował to Linus Torvalds, twórca Gita, krzycząc do programistów SVN coś w stylu: “pewnie, w SVN łatwo jest zrobić nowy branch, ale po co skoro nie da się zrobić merge?”. To samo tyczy się zresztą TfuFSa (chociaż tam to jest już kompletna masakra).
Odkąd poznałem Gita myślałem, że ludzkość zakończyła rozwój w jednym z aspektów technologii, a mianowicie: mergowaniu zmian między dwoma plikami. W Gicie w większości przypadków jest to tak bezbolesne, że aż ciężko uwierzyć po przesiadce z jakiegokolwiek innego systemu (i nie wierzcie marketingowcom od TfuFS 2012 że “teraz merge w TFS jest tak dobry jak w Git”, bo… to nieprawda).
Czasami jednak nadal zdarza się sytuacja podczas łączenia moich zmian ze zmianami zespołu, podczas których włos sam siwieje, pięść się zaciska, a bluzgi lecą w stronę Bogu ducha winnego otoczenia. Nie jest to wina ani zespołu ani moja – po prostu niekiedy trzeba zakasać rękawy i ręcznie połączyć dwa pliki na tyle się między sobą różniące, że maszyna nie jest w stanie sobie z tym zadaniem poradzić.
No dobra, ale gdyby założyć, że nie musimy tego robić na poziomie TEKSTU a na poziomie KODU? Czyli że “coś” odwali za nas robotę należącą tak naprawdę do preprocesora, lexera, parsera i analizatora semantyki?
Od niedawna możemy sprawdzić własnymi rencami: poznajmy Semantic Merge! W praktyce jeszcze się tym nie bawiłem, ale doczekać się nie mogę. Jest to narzędzie do mergowania, które ROZUMIE kod (na razie C#, Java i C++, wkrótce dodane zostaną kolejne). How cool is that? Chyba TO jest finał scieżki ludzkości ku najlepszemu sposobowi rozwiązania odwiecznego problemu “WTF?” poprzedzonego przez “to merge or not to merge?”.
Polecam pochodzenie po www.semanticmerge.com i zapoznanie się z materiałami. Robi to-to wrażenie.
Wygląda zacnie ;))
Historia pokazuje, że wszelkie wieszczenia w stylu “No więcej w tym temacie już się nie da odkryć” są błędne. :)
Wracając do tematu, pokazane narzędzie zapowiada się świetnie, narobię sobie konfliktów co by przetestować.
Wednewsday: SemanticMerge – bo kod to coś więcej niż tekst… | Maciej Aniserowicz o programowaniu…
Dziękujemy za dodanie artykułu – Trackback z dotnetomaniak.pl…
A ja się bawiłem, ale tylko przykładami i robi wrażenie. Jednak faktycznie pod git-em konflikty mam tylko od wielkiego dzwonu. Tak też sobie myślę, że gdyby nie pliki *.csproj (i czasem *.resx), to praktycznie w ogóle bym ich nie miał. Jeśli trzymać się SRP to zostaje stosunkowo mała liczbą plików odpowiedzialnych za koordynację i w nich mogą się pojawiać.
Inna rzecz, że nie bardzo rozumiem po co są pliki projektów. Rozumiem definicje targetów i zależności, ale po co robić listę plików do kompilacji? Brać wszystko jak leci (jak to się dzieje przy kompilacji widoków). Dla tych – rzadkich – przypadków, które mają inne ustawienia np.: “Custom tool” lub “Build action” wystarczyłaby sensowna konwencja np. View.cshtml -> View.settings.xml (jak już jest designer.cs/generated.cs). Wtedy można by się łatwo bez VS obyć – może o to chodzi? ;)