\u00c8 stata pubblicata la versione 0.4 del progetto mergiraf, che sviluppa un driver per Git con l'implementazione della possibilit\u00e0 di fusione a tre vie. Mergiraf supporta la risoluzione di vari tipi di conflitti durante la fusione e pu\u00f2 essere utilizzato per vari linguaggi di programmazione e formati di file. \u00c8 possibile utilizzare mergiraf come chiamata separata per gestire i conflitti che si presentano durante l'uso di Git standard, oppure sostituire il gestore delle fusioni di Git per estendere le funzionalit\u00e0 di comandi come merge, revert, rebase e cherry-pick. Il codice \u00e8 distribuito sotto licenza GPLv3. La nuova versione include il supporto per i linguaggi Python, TOML, Scala e Typescript, oltre a ottimizzazioni delle prestazioni. <\/p>\n
Di seguito viene fornita una descrizione dettagliata dei problemi risolti con l'ausilio di mergiraf: <\/p>\n
Il software \u00e8 un esempio lampante di un sistema estremamente complesso. I sistemi complessi hanno una caratteristica comune: sono COMPLESSI e non ci si pu\u00f2 aspettare che il comportamento complesso desiderato emerga da solo, casualmente. Al contrario, questi sistemi evolvono nel tempo, passo dopo passo, e ogni mutazione viene attentamente verificata ad ogni fase. Per raggiungere questo obiettivo sono necessarie una struttura ben definita e strumenti appropriati. L'evoluzione di qualsiasi sistema complesso pu\u00f2 essere visualizzata come un albero orientato, dove la radice rappresenta un insieme vuoto di funzioni e ogni nodo, ad eccezione della radice, \u00e8 il risultato dell'applicazione di una mutazione al proprio genitore. <\/p>\n
Nel contesto dei prodotti, ogni nodo \u00e8 chiamato \"versione\", che rappresenta un insieme specifico di funzioni e anti-funzioni. Qualsiasi modifica di questo insieme \u00e8 considerata una mutazione, formando un arco nel nostro grafo orientato aciclico. Queste funzioni sono per loro natura astratte; non riflettono direttamente i modi di funzionamento dei sistemi fisici, ma dimostrano piuttosto come gli agenti razionali percepiscono l'utilit\u00e0 di questi sistemi. Per tradurre concetti in implementazioni reali, \u00e8 necessario rimboccarsi le maniche e immergersi nei dettagli *sufficientemente* a basso livello, in un linguaggio che consenta di esprimere e spiegare esattamente come funziona tutto. Nello sviluppo software, questi dettagli a basso livello sono solitamente rappresentati dal codice sorgente. <\/p>\n
Per riportare gradualmente il codice sorgente in uno stato che mostri il comportamento richiesto e documentare come ci sono arrivati, i programmatori rappresentano il loro lavoro in termini di snapshot e changeset. Uno snapshot rappresenta uno stato specifico del prodotto con tutti i dettagli a basso livello, mentre un changeset indica il passaggio tra gli snapshot. Di solito, gli snapshot sono generati da singoli changeset ai loro genitori, quindi questi snapshot sono quasi sempre contrassegnati da ci\u00f2 che fanno i changeset che li hanno creati, ed \u00e8 per questo che questi termini sono frequentemente usati in modo intercambiabile. <\/p>\n
A volte esistono snapshot ottenuti a seguito di pi\u00f9 passaggi \u2014 fusioni di commit. \u00c8 difficile lavorare con essi, quindi di solito vengono evitati. I moderni sistemi di controllo versione open source, come Git, offrono funzionalit\u00e0 piuttosto basilari per gestire i flussi di lavoro di sviluppo. Consentono agli sviluppatori di organizzare snapshot sotto forma di grafi aciclici orientati, di annotarli con commenti e di cambiarne l'ordine se necessario. <\/p>\n
Questa funzionalit\u00e0 consente agli sviluppatori di scrivere una storia del progetto semanticamente significativa, fondamentale per il debugging e per rispondere a domande come \u00abPerch\u00e9 \u00e8 stata introdotta questa sottile caratteristica (ad es., variabile)?\u00bb, \u00abQual \u00e8 stata approssimativamente la mia percentuale di contributo a questo progetto?\u00bb, \u00abChi \u00e8 stato compromesso dall'introduzione di un backdoor e quando?\u00bb, \u00abQuale modifica a basso livello ha rotto questa funzione (anche se non dovrebbe, abbiamo controllato tutto!?)\u00bb <\/p>\n
I sistemi di controllo versione integrano questo concetto di ramo \u2014 un concetto a basso livello che significa semplicemente un frammento continuo della storia a basso livello del progetto, semanticamente significativo per lo sviluppatore. I rami sono solitamente utilizzati per implementazioni specifiche di funzionalit\u00e0, e talvolta vengono creati pi\u00f9 rami per diversi candidati all'implementazione della stessa funzionalit\u00e0. Utilizzando flussi di lavoro con ramificazione (che sono in realt\u00e0 la norma e lo standard di sviluppo, usati ovunque e in qualsiasi luogo), ogni singolo sviluppatore pu\u00f2 gestire efficacemente molti rami in conflitto del progetto, ognuno dei quali differisce per grado di prontezza o qualit\u00e0. Questo consente agli sviluppatori di combinare i risultati dei propri sforzi e di quelli degli altri senza dover riscrivere tutto a mano ogni volta. <\/p>\n
Di solito si crea un ramo principale, che rappresenta il prodotto \u00abufficiale\u00bb, da cui si ramificano rami laterali per ogni funzionalit\u00e0, che vengono regolarmente (idealmente \u2014 dopo ogni commit) sincronizzati con il ramo principale, consentendo agli sviluppatori di lavorare con la versione pi\u00f9 aggiornata del prodotto e allo stesso tempo di implementare funzionalit\u00e0 su cui stanno attualmente lavorando, rilevando i problemi derivanti dalle azioni di altri sviluppatori il prima possibile. <\/p>\n
Quando si tenta di combinare le funzionalit\u00e0 di diversi snapshot (che \u00e8 semplicemente la ricerca di un antenato comune e l'applicazione sequenziale dei cambiamenti generati su un altro, questa operazione \u00e8 chiamata rebase, mentre la fusione \u00e8 quasi come un rebase, ma struttura il grafo dei commit in modo diverso, rendendolo cos\u00ec scomodo da manipolare; per questo motivo si tende ad evitare le fusioni a favore dei rebase), possono sorgere problemi. I moderni sistemi di controllo versione (VCS) utilizzano algoritmi interni per unire le modifiche, che semplicemente dividono i file in singole righe, trattando ogni riga come un simbolo, e i file come loro sequenze, quindi applicano algoritmi per unirli, originari della bioinformatica. <\/p>\n
Purtroppo, questa rappresentazione riga per riga del codice sorgente non ha niente a che fare con il suo contenuto. L'unico suo pregio \u00e8 che \u00e8 semplice e universale. L'incongruenza porta a conflitti, rappresentando una fonte costante di mal di testa per gli sviluppatori. Risolvere i conflitti richiede agli sviluppatori di esaminare attentamente entrambe le versioni del codice, non solo le sezioni contrassegnate dall'algoritmo di confronto riga per riga come 'modificate' o 'conflittuali', ma forse anche l'intero progetto. <\/p>\n
Lo sviluppatore deve comprendere le modifiche, scrivere manualmente il codice unito e risolvere eventuali incongruenze. I problemi aumentano notevolmente quando l strumenti a livello di riga identifica scorrettamente le modifiche, cosa che accade spesso con grandi cambiamenti, comprese le modifiche banali come il riformattamento del codice. Se le modifiche successive non possono essere applicate al codice unito manualmente, la situazione diventa un incubo totale. Nonostante i casi allarmanti, nella maggior parte dei casi l'algoritmo a livello di riga funziona, specialmente se gli sviluppatori si sforzano attivamente di non creargli problemi. Uno dei modi per minimizzare questi problemi \u00e8 l'obbligo di elaborare i sorgenti con strumenti di canonicalizzazione, come black. <\/p>\n
Naturalmente, la soluzione corretta per casi spaventosi (e non solo per quelli, l'algoritmo riga per riga \u2014 \u00e8 un'euristica, che pu\u00f2 portare in modo banale a codice non funzionante; ad esempio, un sviluppatore ha rinominato una variabile mentre un altro stava scrivendo un nuovo codice che utilizzava quella variabile, non ci sar\u00e0 conflitto di merge\/rebase, ma il risultato diventer\u00e0 non funzionante) \u2014 \u00e8 l'uso di un modello interno corretto. <\/p>\n
Sebbene la ricerca in questo campo sia in corso da circa 30 anni e abbia portato alla creazione di diversi prodotti commerciali proprietari, fino a poco tempo fa queste ricerche non erano state trasformate in prodotti pratici applicabili a codice aperto. La maggior parte delle soluzioni di software libero ha iniziato a svilupparsi all'inizio degli anni 2010, ed era focalizzata principalmente sul linguaggio Java. <\/p>\n
La realizzazione free pi\u00f9 notevole di quel periodo, GumTree, \u00e8 stata creata da un ricercatore con una formazione accademica, \u00e8 scritta in Java, ha una propria rappresentazione interna astratta, antecedente a treesitter, e ha backend sia basati su treesitter che su altri strumenti per il parsing del codice sorgente in rappresentazioni astratte. Questo sistema \u00e8 capace solo di generare (sotto forma di log di eventi testuali, esiste anche un'API che pu\u00f2 essere richiamata facilmente da qualsiasi linguaggio di programmazione che ha binding a Java) e di visualizzare modifiche. Tuttavia, per unire modifiche, cos\u00ec come per visualizzare i file diff generati, non \u00e8 applicabile out-of-the-box (s\u00ec, \u00e8 probabile che il caricamento dei diff possa essere implementato tramite l'API). <\/p>\n
La realizzazione pi\u00f9 giovane e pi\u00f9 praticabile di difftastic \u00e8 scritta in Rust, \u00e8 basata su treesitter e si concentra sulla generazione di diff evidenziati in console. Questo sistema \u00e8 anch'esso dedicato alla visualizzazione dei diff e non ha come obiettivo l'unione delle modifiche o l'applicazione di patch. <\/p>\n
Recentemente \u00e8 emerso e si sta sviluppando attivamente il progetto mergiraf. Questo strumento scritto in Rust (occupa 21 MiB!) si basa anche su treesitter, che \u00e8 diventato uno standard per i parser di grammatiche context-free negli strumenti di sviluppo, tanto quanto LLVM lo \u00e8 per l'ottimizzazione delle rappresentazioni a basso livello delle istruzioni. A differenza dei concorrenti, mergiraf fornisce funzionalit\u00e0 non per la generazione di diff, ma per la risoluzione automatica dei conflitti di merge. Nascosto, mergiraf utilizza per la generazione dei patch un'implementazione dell'algoritmo utilizzato in GumTree e per l'applicazione un'implementazione dell'algoritmo utilizzato in spork, adattati per le strutture treesitter. <\/p>\n
La serializzazione delle patch in file che possono essere applicati in seguito, purtroppo, non \u00e8 stata implementata (ma \u00e8 molto probabile che possa essere realizzata tramite il parsing dei log degli eventi generati da GumTree). Un altro modo promettente per applicare le differenze potrebbe essere il ricorso non a patch, ma alla funzionalit\u00e0 di refactoring dei server LSP, che pu\u00f2 aiutare nel rilevamento dei conflitti a livello di progetto. La visualizzazione \u00e8 supportata solo per i conflitti. <\/p>\n
Esempio di lavoro: l'antenato comune \u00abbase.py\u00bb (indentazione con tabulazioni, riga extra all'inizio) foo = 1 def main(): print(foo + 2 + 3) \u00aba.py\u00bb (indentazione ancora con tabulazioni, 2 righe extra all'inizio invece di una, per la stampa di debug \u00e8 stata utilizzata la libreria icecream, \u00e8 stata aggiunta la classe \u00abbaz\u00bb: from icecream import ic foo = 1 def main(): ic(foo + 2 + 3) class baz: def __init__(self): \u00ab...\u00bb \u00abb.py\u00bb (la variabile \u00abfoo\u00bb \u00e8 stata rinominata in \u00abbar\u00bb, elaborato con \u00abblack\u00bb dopo le modifiche, con il risultato che l'indentazione \u00e8 stata convertita in spazi e le righe extra sono state rimosse): bar = 1 def main(): print(bar + 2 + 3) La chiamata .\/mergiraf merge .\/base.py .\/a.py .\/b.py -x a.py -y b.py -s base.py -o .\/res.py porta al seguente risultato from icecream import ic bar = 1 def main(): ic(bar + 2 + 3) class baz: def __init__(self): \u00ab...\u00bb. (Per la stampa di debug \u00e8 stata utilizzata la libreria \u00abicecream\u00bb, la variabile \u00abfoo\u00bb \u00e8 stata rinominata in \u00abbar\u00bb, elaborato con \u00abblack\u00bb dopo le modifiche, di conseguenza l'indentazione \u00e8 stata convertita in spazi e le righe extra sono state rimosse, misto di tabulazioni e spazi per l'indentazione, ma in forma consentita). <\/p>\n