SVN - Come faccio a intercettare e modificare o aggiungere file sul pre-commit?

Question

Prima di tutto io non sono sicuro che questo è anche possibile, però ho bisogno di sapere come si può fare e se non perché no?

Voglio creare un'applicazione C # che viene eseguito al momento opportuno durante il processo di commit di un repository subversion (pre-commit credo) che saranno poi aggiungere un altro file ad essere impegnati.

Per esempio, apportare modifiche alle Program.cs, e Main.cs, ma non AssemblyInfo.cs. Voglio essere in grado di forzare un cambiamento di AssemblyInfo.cs o qualsiasi file per quella materia.

Ho scritto un'applicazione console utilizzando SharpSVN che ha attivato il post-commit, che poi ha sostituito un file, ma questo ha causato un incremento nel numero di revisione. Ovviamente questo non è l'ideale.

Poi ho trovato SvnLookClient all'interno SharpSVN che gira su pre-commit e hanno iniziato a scrivere qualcosa, ma ha colpito un vicolo cieco quando ho capito CopyFromPath non voleva dire quello che mi aspettavo:

    using (SvnLookClient client = new SvnLookClient())
    {
        SvnLookOrigin o = new SvnLookOrigin(@"\\server\repository");
        SvnChangedArgs changedArgs = new SvnChangedArgs();
        Collection<SvnChangedEventArgs> changeList;
        client.GetChanged(o, changedArgs, out changeList);
    }

In alternativa, mi accontenterò di fare questo al di fuori di C #, ma idealmente mi piacerebbe farlo in un C # applicazione console in modo che posso anche dire al mio server di repository per eseguire altre attività come la corsa in script di database, ecc

Answer 1

Non è necessario modificare la transazione durante un gancio-script. Si può respingere la impegnarsi con un messaggio ( stderr verrà inviato al cliente ), o farlo in un separato impegnarsi nel post-commit.

[modifica] Ci tengo a precisare perché modifica transazioni è una cattiva idea (svn-tecnicamente):

Il client non sa nulla.

Ad eccezione di "OK", "Failed" e l'uscita stderr non si può tornare canali dal server al client durante un commit.

Quando il cliente si impegna suoi cambiamenti, ed è segnalato per avere successo il commesso, che segna il suo status di file e cartella locale per essere in sincronia con la versione del repository [xyz]. Quando in seguito cambiare qualcosa, per esempio, aggiungere il file in locale, che vuole a commettere quei cambiamenti, ma poi ... Beh, si può provare a sapere cosa succede, mi aspetto qualcosa del "checksum error" o "il file già aggiunto" . A seconda del tipo di cambiamenti si sarebbe probabilmente non hanno più possibilità di ottenere un WC di lavoro che eliminando la cartella e fare un checkout fresco della parte danneggiata.

Questa è stata la parte tecnica. Ora lo sviluppatore-side: In primo luogo, i cambiamenti di fissaggio automaticamente sembra correttamente intelligente, ma non riuscirà, a causa del semplice fatto che se la sorgente sarebbe stato pre-calcolabile, non avremmo dovuto lasciarlo scrivere da parte degli sviluppatori. Volete che i vostri sviluppatori di fare la cosa giusta.

Questo funziona meglio attraverso l'educazione: devono so quello che la cosa giusta è. Buone misure per farli sapere qualcosa è, ulteriore al buon vecchio formazione di qualsiasi tipo, dando loro un feedback.

Un errore-messaggio dal server svn, un messaggio di posta automatizzata dopo rotto costruisce o unità di test, i risultati di uno strumento di analisi del codice sorgente statica, ecc, può anche servire come un buon strumento educativo.

Ti consiglio di utilizzare integrazione continua, e convalidare la fonte-albero lì. Questo ha il vantaggio che uno sviluppatore non sarà bloccato per commettere i suoi cambiamenti dopo una lunga giornata di lavoro, ma è ancora sa che lo stato della fonte-albero.

E, ora solo indovinare ciò che si vuole cercare di raggiungere: La fonte-albero sul lato server deve essere sempre "funzionale". Allora il problema è che anche con il file-fissaggio automatico, pre-commit unit test, stile controllo e tutto ciò, è, infine, devono ancora verificare se il programma funziona in realtà, da vecchio stile sistema di test. Quindi, in pratica, non si ha realmente guadagnare nulla.

La tecnologia può supportare i processi, ben strumenti di pensiero-out lo supportano così bene che dopo i processi effettivamente aiuta gli sviluppatori di risparmiare tempo e rendere il flusso di lavoro più semplice. Ma la tecnologia di solito non può sostituire i processi, e non può sostituire l'intelligenza umana (almeno, per ora). [/ Modifica]