Uno sviluppatore dovrebbe poter utilizzare VSS se preferisce?

would it be better to just allow him to continue using vss if thats what he prefers

No. Non ha senso eseguire due diversi sistemi di gestione delle sorgenti in parallelo. Ciò sfida l'idea che tutti gli sviluppatori siano connessi allo stesso repository e ne traggano tutti i vantaggi.

Un singolo sviluppatore che utilizza un sistema diverso da solo si isola efficacemente dal team. Anche se i progetti non si incrociano, è ancora una brutta cosa da fare.

Gli sforzi di manutenzione raddoppiati per entrambi i sistemi sono un altro argomento qui.

Penso che dovresti usare la tua autorità o inoltrare il problema alla gestione per migrare rapidamente il contenuto da VSS a Mercurial e quindi chiudere VSS in basso.

P.S. Parlando di VSS, è noto per aver perso check-in o codice altrimenti dannoso quando meno te lo aspetti. Funziona ma va regolarmente sui nervi. Se hai un'alternativa migliore, evita VSS.

In nessun modo potrei mai considerare di permettere a uno sviluppatore malvagio di usare un sistema di controllo del codice sorgente diverso dal resto del gruppo.

Il controllo del codice sorgente non è solo così posso trovare le versioni precedenti di quello che ho fatto, ma così gli altri possono trovarle (e anche la versione attuale). Questo non è negoziabile. Cosa succede quando parte o viene investito da un autobus e nessun altro ha accesso al suo codice (che potrebbe persino essere sovrascritto dagli amministratori di rete quando puliscono la sua macchina, non sapendo che ha il proprio controllo sorgente lì?

Faccio presupporre che il suo codice di controllo sorgente possa essere solo sulla sua macchina dato che nessun altro sta usando VSS.) Uno sviluppatore che suggerirebbe anche una cosa del genere non è professionale e mi farebbe sospettare di tutto il suo lavoro . Cosa non vuole che veda il resto di voi?

Anche VSS è notoriamente bacato. Il suo codice non è nemmeno al sicuro lì.

Nessuno dovrebbe mai usare VSS per cominciare.

Chiedi al tuo sviluppatore di ottenere un plug-in Mercurial per Visual Studio.

Tutti dovrebbero essere sullo stesso sistema di gestione delle fonti. Inoltre, il tuo obiettivo finale è quello di portare tutti nello stesso sistema di tracciamento dei bug. Hai già fatto la cosa giusta per trovare già una soluzione strettamente integrata.

Se hai difficoltà a farle passare, prova ad affrontarlo dal punto di vista della carriera. Se lavorano altrove, il potenziale datore di lavoro vorrà probabilmente vedere un po 'di esperienza nel lavorare con una configurazione integrata di bug / gestione delle sorgenti.

Andando a eco ciò che gli altri hanno detto, in quanto è male permettergli di usare VSS e non Mercurial. Comunque, lasciami giocare a Devil's Advocate e dì che puoi lasciarlo andare se, e solo se, si impegna ancora a Mercurial in modo che altri possano accedere al suo lavoro se necessario. C'è IMO che non ha nulla a che fare con l'utilizzo dei tuoi strumenti preferiti finché non impedisci ad altri di accedere al lavoro di cui potrebbero aver bisogno. Certo, VSS è spazzatura quindi non dovrebbe essere usato, non importa cosa:)

Per esempio, lavoro in un'azienda che usa SVN ma non ha il repository impostato correttamente (nessun ramo / tag / tronco, tutto è gettato solo sotto un repository) e questo causa alcuni problemi che nessuno sa come risolvere. Non vedrei un problema nel mio caso se usassi, diciamo, Git localmente, ma continuassi a usare git-svn per spingere le mie cose in SVN così il resto del team ce l'ha. Ha senso?

Non è bello avere uno sviluppatore che utilizza un diverso strumento di controllo del codice sorgente. Uno degli scopi dell'utilizzo del controllo del codice sorgente è migliorare il lavoro di squadra. E sta infrangendo questa regola e potrebbe causare molti problemi in seguito, anche se di recente lavori in maniera abbastanza indipendente. Chiedigli perché preferisce VSS e digli gli svantaggi di lavorare in questo modo.