Diversi sistemi di controllo della versione distribuita che lavorano insieme

Question

Il mio ufficio dispone di un'installazione centrale di Source Safe 2005 che utilizziamo per il controllo del codice sorgente.Non posso modificare ciò che l'ufficio utilizza sul server.

Sviluppo su un laptop e vorrei avere un repository di controllo del codice sorgente locale diverso che possa sincronizzarsi con il server centrale (se disponibile) indipendentemente da quale sia il provider centrale.Il motivo della richiesta è che così posso mantenere un branch/build stabile locale per le presentazioni dei clienti continuando a sviluppare senza dover fare i salti mortali.Inoltre, in qualità di consulente, i miei clienti potrebbero richiedermi di utilizzare il loro fornitore di controllo del codice sorgente e la flessibilità in questo caso renderebbe la vita più semplice.

Qualcuno dei client di controllo del codice sorgente distribuito esistenti può gestirlo?

Answer 1

BENE...KernelTrap ha qualcosa su questo.Sembra che tu possa usarlo vss2svn per convogliare il repository Source Safe in un repository Subversion, quindi utilizzare il bellissimo git-svn per inserirlo in un repository git locale.

Presumo che il commit su VSS non sarebbe un processo fluido e automatico utilizzando questo metodo.

Answer 2

Dovresti essere in grado di controllare la versione corrente del codice e quindi creare un repository git attorno ad esso.Aggiornarlo e trasferirlo nel repository git locale dovrebbe essere indolore.Come dovrebbe clonarlo.

L'unico problema è che è necessario che entrambi si ignorino a vicenda (ho fatto qualcosa di simile con SVN) modificando i file di ignoranza appropriati.Presumo che SourceSafe ti permetta di ignorare le cose.E dovrai eseguire determinate operazioni due volte (come dire a entrambi che stai eliminando un file).

Answer 3

Questo episodio di HanselMinutes copre esattamente ciò che speravo di sentire.Apparentemente Git può essere utilizzato localmente e quindi collegato a repository subversion/vss esterni secondo necessità.Ne parlano per 14 ~ 15 minuti.

Answer 4

un giorno lavoro in un'azienda che utilizza VSS (e in altre aziende che utilizzano altri meno sconosciuti SCM) ma preferisco usare SVN (un giorno proverò GIT) per lo sviluppo attivo, per me e il mio gruppo.

Prima di tutto, questa situazione è una buona idea solo se gli impegni per VSS sono pochi nel mese, perché lavorare con altri SCM (rispetto a VSS) ti dà maggiore flessibilità, ma l'impegno per VSS da SVN è costoso in termini di tempo.

La mia soluzione era:

VSS -> SVN:Ho uno script Linux (o uno script Ant o uno script XXX) che copia dal lavoro della directory di aggiornamento corrente di VSS all'SVN corrente, quindi aggiorna il client SVN e aggiorna/unisce/commit su SVN.In questo modo sei aggiornato sui cambiamenti del resto dell'azienda che utilizza VSS.

SVN -> VSS:In questo modo, è necessario eseguire il checkout di tutti i file di modifica su VSS, quindi è possibile utilizzare semplicemente lo script inverso per copiare dalla directory SVN di aggiornamento corrente (ignorare le directory .svn) e copiare nella directory VSS di aggiornamento corrente, aggiornare e confermare.

Ma ricorda, in alcuni casi vale la pena dedicare il tuo tempo a farlo.