Sto cercando un'alternativa per le utilità combinate di SVN, sia come strumento di sviluppo sia come strumento di gestione della configurazione. Invece, vorrei studiare l'approccio di avere uno strumento di Configuration Management (CM) dedicato e uno strumento di sviluppo separato.
La ragione è che lavoro in un'azienda in cui molti non programmatori usano SVN per CM, e penso che diventi confuso quando i programmatori usano SVN per lo sviluppo insieme a CM. Inoltre si sentono frustrati dalla sovrapposizione di capacità e non gradiscono la prospettiva di tornare alle versioni non funzionanti. La separazione di queste funzionalità in due strumenti separati può fornire la facilità d'uso per i non programmatori, che usano SVN solo come strumento CM.
Quindi quale approccio suggeriresti per raggiungere questo obiettivo? Se hai esperienza con questo, quali utilità ti sono state utili e quali sono stati i tuoi risultati in merito alla chiarezza dei processi e al flusso di lavoro generale?
Nota: IMO utilizzando SVN per entrambi è il migliore, ma dal momento che i programmatori rappresentano solo il 20% dell'utilizzo di SVN, produrre un processo più ampiamente accettato in tutti i gruppi può essere utile (o almeno vale la pena di essere esaminato, da qui inviare).
Grazie
Modifica - il tipico non programmatore impegna i propri carichi di lavoro nel repository SVN. Quindi, poiché il cliente ritiene che una versione risolva / non risolva il problema, le versioni vengono ripristinate o aggiornate. Non vogliono che i file che si traducono in eseguibili non lavorativi siano mai presenti in SVN. Quindi, i ripristini molto probabilmente verrebbero fatti una revisione alla volta ... non dalla revisione 142 all'89, per esempio. Quindi in sostanza vogliono un programma che abbia solo il tag / tag.