risoluzione dei conflitti binari svn

Question

Uso svn per un progetto su cui sto lavorando con un paio di altri sviluppatori. Svn funziona bene per il controllo del codice sorgente, tuttavia siamo tutti in grado di ottenere conflitti quando commettiamo le DLL.

Quando lo faccio risolvo il conflitto (che elimina le mie dll perché il programma diff non può gestire i file binari) quindi devo ricostruire per impegnarmi. Come intendi risolvere conflitti come questo?

Modifica:

Le DLL sono in una cartella svn separata poiché il progetto è una mod di gioco e non programmatori hanno bisogno di accedere alle ultime build.

Answer 1

Come menzionato in altre risposte qui: non dovresti prima eseguire la versione delle tue DLL generate. Ma se davvero hai la versione, allora puoi risolvere un conflitto senza usare uno strumento diff che rimuove i tuoi file dll:

Per ogni file in conflitto, Subversion inserisce tre file extra non controllati nella tua copia di lavoro:

filename.mine

Questo è il tuo file così com'era nella tua copia di lavoro prima di aver aggiornato la tua copia di lavoro & # 8212; cioè, senza contrassegni di conflitto. Questo file contiene solo le ultime modifiche. (Se Subversion considera il file immergibile, il file .mine non viene creato, poiché sarebbe identico al file di lavoro.)

filename.rOLDREV

Questo è il file che era la revisione BASE prima di aggiornare la copia di lavoro. Cioè, il file che hai estratto prima di aver apportato le ultime modifiche.

filename.rNEWREV

Questo è il file che il tuo client Subversion ha appena ricevuto dal server quando hai aggiornato la tua copia di lavoro. Questo file corrisponde alla revisione HEAD del repository.

Qui OLDREV è il numero di revisione del file nella directory .svn e NEWREV è il numero di revisione del repository HEAD.

Ora, per risolvere un simile conflitto, rimuovere i file aggiuntivi che non si desidera:

• se si desidera mantenere la propria dll, eliminare i file nomefile.rOLDREV, nomefile.rNEWREV
• se si desidera mantenere la dll dal repository, eliminare i file nomefile.rOLDREV e nomefile.mine, quindi copiare nomefile.rNEWREV in nome file

dopo, esegui

svn resolved filename

per dire a Subversion che hai risolto tu stesso il conflitto.

Answer 2

Se è una DLL che STAI COSTRUIRE (piuttosto che una esterna per la quale non hai un sorgente), allora la fonte dovrebbe essere nel controllo del codice sorgente, non in quello binario.

Se non si desidera includerlo in quel particolare repository, è possibile includerlo come svn: external.

Answer 3

Generalmente, non dovresti archiviare le tue DLL compilate nel controllo del codice sorgente. Hai un motivo specifico per cui devi farlo?

Ho impostato i miei ambienti di sviluppo in modo che chiunque possa costruire qualsiasi componente del mio progetto indipendentemente da chiunque altro. In questo modo, l'unica cosa presente nel mio sistema di controllo del codice sorgente è il mio codice sorgente . Ciò ha una serie di vantaggi:

• Evita conflitti di file binari quando si tenta di archiviare DLL o EXE
• Il volume di dati tracciati dal sistema di controllo del codice sorgente è molto più piccolo, rendendolo più veloce
• Quando gli sviluppatori creano sempre le proprie DLL, possono essere ragionevolmente sicuri che il codice sorgente che hanno corrisponda al file compilato. Se stai usando qualcosa che qualcun altro ha costruito, non puoi mai esserne sicuro.

Come menzionato nei commenti, può essere perfettamente ragionevole archiviare DLL di terze parti nel sistema di controllo del codice sorgente, in particolare se non si dispone effettivamente del codice sorgente per esse. Ho anche lavorato su progetti in cui abbiamo archiviato file di distribuzione ( .tar.gz ecc.) Per varie librerie open source nel controllo del codice sorgente, quindi ho avuto un intero sistema di Makefile che ha creato quelle librerie come parte di un target build-everything.

Answer 4

Per i file binari, la maggior parte delle volte, si desidera accettare entrambe le versioni. Ad esempio, se il file in questione è uno strumento eseguibile, in genere una versione potrebbe essere più recente dell'altra e potrebbe essere quella che si desidera utilizzare.

Per accettare la versione che si trova nel ramo da cui si sta unendo, utilizzare:

svn resolve --accept=theirs-full path/to/filename

Per accettare la versione precedentemente presente nel ramo corrente, utilizzare:

svn resolve --accept=mine-full path/to/filename

A volte, SVN rifiuta di usare loro pieno con un avvertimento:

svn: avviso: W195024: opzione di risoluzione del conflitto non applicabile fornita per il percorso in conflitto

perché SVN è un pezzo di merda quando si tratta di unire. In tal caso, devi copiare i file manualmente come nella risposta accettata https://stackoverflow.com/a/410767/2279059, anziché utilizzare le opzioni della riga di comando destinate a ciò che si sta tentando di fare. Se sai che entrambi i file sono identici (ma SVN li sta ancora contrassegnando come conflitto per motivi già indicati), puoi anche utilizzare

svn resolve --accept=working path/to/filename

Sebbene questo, nel caso di file identici, sia effettivamente lo stesso di tutti gli altri comandi, SVN non rifiuterà codardamente di eseguirlo. ha senso? No, non lo fa. Affrontalo.

Answer 5

È ragionevole avere anche binari nel controllo versione:

• Evita il fastidio della ricostruzione per le persone che usano solo il binario.

• Il binario viene inchiodato quando si rilascia.

Per far funzionare tutto ciò, il binario deve sempre corrispondere alle fonti. Quindi, se hai unito le fonti devi ricostruire il binario da esse, scegliere uno dei binari dalle versioni unite non lo farà.

Answer 6

Assicurati che le tue dll abbiano la proprietà svn: mime-type impostata su application / octet-stream o su qualche altro tipo non testuale.

svn propget *.dll
svn propset svn:mime-type application/octet-stream *.dll

Dovrai comunque risolvere i conflitti quando si verificano.

E controlla Tipo di contenuto del file capitolo della documentazione.

Answer 7

Quindi se hai * .dlls in una cartella separata è molto più facile fare come segue:

1. Direttamente prima di compilare la modifica, aggiorna meglio la tua cartella * .dll, se ritieni affidabile, che i tuoi colleghi commettano solo codice sorgente compilabile. (in caso di conflitto (quale sarebbe la tua colpa a quel punto, poiché hai cambiato qualcosa prima di aggiornare all'ultima revisione))
2. Crea la tua build.
3. Impegna direttamente il risultato.

In alternativa:

non compilare il percorso nella directory, costruire da qualche parte all'esterno, finché non si è soddisfatti di qualunque sia il risultato.

Quindi procedere come segue:

1. Aggiorna la tua copia di lavoro della cartella dlls (se c'è qualche conflitto è colpa tua e risolvi il conflitto di " mantieni il loro ")
2. Copia i tuoi dll di lavoro nella copia di lavoro
3. Informa i tuoi colleghi che farai una nuova revisione (puoi lasciare questo passo)
4. Commetti il ??tuo lavoro in caso di conflitto dovrebbe essere colpa loro.

Adesso hai due possibilità:

5 bis. Sei una persona molto detestabile e risolvi il problema mantenendo il mio.

5 ter. Lavori come dovresti lavorare ... Leggi il file di registro e scopri chi ha eseguito il commit anche nel breve periodo di tempo necessario per copiare il lavoro nella cartella e premuto commit. Parla con quel collega. Concordare un ulteriore corso di azione.