confusione tra SVN e backup del codice per mese / data / ora ogni volta che eseguo aggiornamenti importanti o importanti del codice

im advice not to commit the changes again and again but just a major change all at once

È un consiglio sbagliato .

project B where most im on the project (as of now) should it be SVN or folder backups

Dovresti usare il controllo della versione in qualsiasi progetto.

I backup e il controllo della versione non sono la stessa cosa, anche se un repository esterno (centralizzato o distribuito in un altro computer) è un backup in sé e backup (ad esempio cartelle datate o file zip) insieme a qualche strumento diff (ad esempio WinMerge ) potrebbe servire come strumento di controllo della versione molto rudimentale. Ma dal momento che i sistemi di controllo delle versioni eccellenti sono disponibili gratuitamente, non ci sono assolutamente scuse per non usarli.

Naturalmente, è necessario utilizzare i backup in aggiunta per utilizzare un sistema di controllo della versione.

The reason I do folder backups for the project B is that sometimes the build given to the client fails/buggy so instead of making them wait for it to fix I just go and open the project and compile the last working build and give the executable

Questo è precisamente il problema che il controllo del codice sorgente deve risolvere (usando rami / tag). Ti farei un favore a lungo termine passando a SVN. Ti renderai conto di quanto sia stato saggio un tale movimento (sarebbe stato) la prima volta che devi fornire un hotfix a un bug in una versione precedente mentre sei nel mezzo dello sviluppo di una nuova funzionalità nell'ultima versione, che non deve essere schierato ancora. Con SVN, la fusione tra diversi rami è molto più facile e più sicura rispetto alla diff e all'amplificazione manuale; unire tra diverse directory di backup.

È possibile passare a mercurial (controllo di versione distribuito). In questo modo puoi impegnarti tutte le volte che vuoi (su entrambi i progetti).

Nel progetto A una volta raggiunta una massa critica di commit accettabili, è possibile trasferirli tutti al repository di subversion (utilizzando HgSubversion *). Se il numero di commit è un problema, puoi utilizzare le code mercuriali (Tutorial ) o fai una piccola correzione fatta in casa riscrivendo tutti i tuoi commit in uno solo. Ad esempio, esportali tutti come patch, facilmente eseguibili con TortoiseHg, quindi importali nuovamente nel repository. Quindi commetti e hai tutte le tue modifiche in un unico commit.

* Per usare HgSubversion hai bisogno dei bind di Python SVN. In TortoiseHg (client mercurial di Windows) questi sono inclusi in modo da scaricare solo l'origine HgSubversion, includere il percorso nel file hgrc e sono pronti per andare.

• Utilizza un repository sorgente per tutti i tuoi progetti, come scritto da @JoonasPulakka e @ PéterTörök.
• Esegui il backup dell'intero repository di origine ogni giorno su un altro server / unità. La corruzione / perdita di repository di origine può accadere ed è l'unico modo per recuperare l'intera cronologia delle modifiche, non solo l'ultima versione. C'è una domanda su SO su qual è il modo migliore per fare il backup un repository SVN .
• Tag / Branch le tue modifiche minori / principali. Se una di queste build viene rilasciata al client e non riesce, dovresti essere in grado di correggere quel ramo e rilasciare una correzione e segnalare la modifica al ramo HEAD. A volte, tuttavia, potrebbero esserci validi motivi per non correggere una versione precedente (come già menzionato) e rilasciare l'ultima versione che ha già risolto il problema potrebbe essere la soluzione migliore. Comunque, questa è la tua scelta, e l'unico modo per essere in grado di correggere una versione precedente è di averlo nel repository, E di taggarlo in modo appropriato.

Modifica: a proposito di SVN, come ha scritto @ PéterTörök, unire le filiali è molto più semplice che con altri repository di sorgenti, hai già fatto una buona scelta lì.