formato di file diff diffuso universalmente

Naviga le tue risposte
1

Ho sempre pensato che l'output di diff (tipicamente "unificato", indipendentemente dal fatto che sia o meno colorato) è universalmente compreso nella maggior parte se non in tutti i programmatori linguistici basati su testo. Indipendentemente dal fatto che sia stato utilizzato a causa del controllo della versione o semplicemente confrontando due singoli file, è sembrato piuttosto prolifico.

  • GitHub offre sia unificato che diviso (side-by-side), predefinito per ultimo usato (la prima volta è unificata, credo)
  • GitLab offre sia unificato sia diviso, ma il valore predefinito è unificato (nessun riferimento trovato nei documenti)
  • Mercurial ( hg diff ) lo usa ( link )
  • Subversion ( svn diff ) lo usa ( link )
  • Git lo usa (predefinito per unificato, altri formati disponibili) ( link )
  • (per citarne solo alcuni)

In una recente conversazione con un partner di progetto (che sta operando esclusivamente in TSQL), si sono lamentati del fatto che il testo unificato diff inviato li in un messaggio di posta elettronica (contenente letteralmente due righe modificate) era inutilizzabile / irriconoscibile per loro. Non sono turbato dal fatto che non abbiano familiarità con lo standard mio : sono sinceramente sorpreso che "non emettano diff output" .

Domande:

  1. Utilizzano Visual Studio e TFS. Alcune ricerche suggeriscono che TFS supporta /format:unified , ma non posso determinare se è predefinito. Qual è l'impostazione predefinita e TFS ha una forma di patch.exe per importare facilmente una modifica simile alla diff?

  2. Hanno diretto che invio ogni modifica come un intero file. Poiché entrambi apportiamo delle modifiche al codice, devono quindi trovare manualmente le mie modifiche e unirle (o meno). Capisco che questo dolore è ora il loro, ma se scelgono di non fondersi perché non vedono un cambiamento, sono direttamente interessato (e la risoluzione dei problemi è difficile). Esiste un modo migliore per inviare loro le modifiche in modo che possano sapere facilmente dove si trovano ancora tutte le modifiche e avere la comodità di ottenere l'intero file?

  3. Se non diff (o sdiff , vdiff o diff3 ), quali altri "standard di settore" ci sono? (forse limitato / focalizzato su MS / TFS)

Mi trovo abbastanza bene con git , GitHub e GitLab, quindi il mio pregiudizio è recentemente git -centric, sebbene abbia una cronologia con RCS, CVS e Subversion. Anche se non presumo che git e quindi diff sia l'end-all / be-all, il mio punto qui non riguarda le opinioni sui sistemi VC. Sto cercando di sdrammatizzare le mie ipotesi sbagliate e comunicare meglio.

NB: Non ho accesso al loro server TFS e non cercheranno di lavorare con il mio GitLab.

    
posta r2evans 08.07.2018 - 06:33
fonte

2 risposte

2

Non esiste uno standard di settore.

Il flusso di lavoro diff-and-patch ha origine a metà degli anni '80 nel contesto di open- sviluppo di Unix sorgente. È possibile inviare diffs via e-mail e quindi applicare tale patch al codice locale. Ciò è stato determinante nello sviluppo di sistemi di controllo delle versioni come Git.

Gli altri ecosistemi hanno convenzioni completamente diverse. Inoltre, altri ecosistemi tendono ad essere meno orientati al testo e alla riga di comando rispetto agli ecosistemi Unix / Linux / Open-Source. Quindi è una falsa pista per cercare di trovare l'interruttore della riga di comando che farà accettare TFS alla tua patch.

Quando lavori con altre persone, dovrai negoziare un flusso di lavoro comune. L'invio di file interi in giro è il minimo comune denominatore e non è necessariamente una cattiva idea: se tutti usano un qualche sistema di controllo della versione localmente, possono copiare il file nell'albero dei sorgenti e vedere rapidamente le modifiche. In Git puoi avviare una diramazione dall'ultimo stato comune, applicare le modifiche e quindi unirle nello stato comune per impedire che le modifiche in conflitto vengano sovrascritte in modo silente.

In un tale flusso di lavoro, il valore dell'invio di patch al posto di interi file è piuttosto ridotto: mentre le patch consentono di vedere immediatamente le modifiche e risparmiare larghezza di banda e spazio di archiviazione delle cassette postali tutto ciò non è di cruciale importanza (rispetto per dire, collaborando in modo produttivo).

Ti suggerisco ancora di spiegare ogni cambiamento in modo che l'altra parte non debba cercare da sé: un tipo se diff in linguaggio naturale o un riepilogo di commit molto dettagliato. Es .: "in foo.sql, ho cambiato il tipo della colonna product_category da varchar a enum perché $ requirements".

    
risposta data 08.07.2018 - 08:37
fonte
1

They've directed that I send every change as a whole file. Since we both make changes to the code, they then need to manually find my changes and merge them (or not). I understand that this pain is now theirs, but if they choose to not merge because they don't see a change, I am directly affected (and troubleshooting is difficult). Is there a better way I can send them changes so that they easily know where all changes exist yet have the convenience of getting the whole file?

Potresti inviare sia la vecchia che la nuova versione di un file. Tuttavia, se ancora dubiti che possano e voglia applicare correttamente il tuo cambiamento, probabilmente dovresti assicurarti di non essere responsabile se lo fanno male. Questo probabilmente includerà la negoziazione del formato delle modifiche in fase di invio e della procedura di richiesta in più dettagli.

    
risposta data 08.07.2018 - 08:59
fonte

Leggi altre domande sui tag

Wpf Struttura dell'applicazione? C # Pattern per lo stato di tracciamento nel codice Haskell ricorsivo