2010-11-23 20 views
3

Ich habe kürzlich einen neuen Job gestartet, und das Unternehmen verwendet Visual SourceSafe für die Quellcodeverwaltung. Bei meinem vorherigen Job haben wir Subversion benutzt. Eine der "Regeln" der neuen Firma ist, dass Sie Ihren Code nur dann festschreiben, wenn Sie froh sind, dass er funktioniert und dass Builds nicht beschädigt werden. Die andere Regel lautet 'No Branching'.Subversion und SourceSafe gleichzeitig verwenden?

Das verkrampft meinen Stil ein bisschen, weil ich es genieße, einen Zweig zu erstellen, an diesem Zweig zu arbeiten, wann immer ich es wünsche (was mir den Vorteil bringt, wenn ich etwas mache) blöd - das kommt recht oft vor) und fusioniere dann meinen Zweig wieder in den Kofferraum wenn ich glücklich bin funktioniert alles wie es soll.

Also, die Frage ist ... Kann ich Dateien zu meinem eigenen lokalen Subversion-Repository hinzufügen, und nicht SourceSafe stören? Ich kann mich dann zu meinem lokalen Subversion-Repo verpflichten, wann immer ich es wünsche, und wenn ich mit allem zufrieden bin, was ich in SourceSafe begehe? Ist es sicher? Werde ich SourceSafe brechen?

Dank

+3

SourceSafe? Lass das schon fallen. [Visual SourceSafe: Microsofts Source Destruction System] (http://www.highprogrammer.com/alan/windev/sourcesafe.html), [Visual SourceSafe Versionskontrolle: Unsicher bei jeder Geschwindigkeit?] (Http: //www.developsense. com/testing/VSSDefects.html) –

+0

Ich bezweifle, dass ich in der Sache ein Mitspracherecht haben ... – tardomatic

+0

@Mehrdad Während ich völlig mit dem Gefühl übereinstimmen, dass SourceSafe eine schlechte Sache ist, war ich in dieser exakten Situation und es ist nicht immer einfach SourceSafe einfach "fallen lassen", wenn Sie eine funktionierende Organisation sind ... –

Antwort

2

Sie werden nicht Source brechen. Dies ist eine hervorragende Möglichkeit, in Ihrer Situation zu arbeiten

Update: Ignorieren Sie eine Datei, die nicht von direktem Interesse für Sie ist, z. B. SCC-Dateien. Ihr Repository muss nicht das gesamte Projekt neu erstellen, sondern nur die Dinge im Auge behalten, die Sie ändern.

Ich mache das gleiche mit Mercurial und CVS. Das Unternehmen verwendet CVS, und ich benutze ein lokales Mercurial-Repository, das ich einchecke, wann immer ich möchte, und checke bei CVS ein, wenn ich glücklich bin.

[beiseite]

Ändern Quellensteuersystemen auf individueller Ebene ist in Ordnung, aber für ein Team kann oft problematisch sein. Die Leute gewöhnen sich daran, wie die Quellcodeverwaltung funktioniert, und nutzen dies zu ihrem Vorteil. Ändern Sie das System ohne Total Buy-In und es kann lange dauern, bis sie spüren, dass die Vorteile die Funktionen überwiegen, die sie verloren haben. Während sie sich an das neue System gewöhnen, machen sie Fehler, verlieren Arbeit und können ein wenig nachlässig sein, wenn sie Ihnen danken, dass sie ein System geändert haben, von dem sie glaubten, dass es perfekt funktionierte.

+1

Cool ... Ich bin mir nicht sicher, ob Sie mit SourceSafe gearbeitet haben, aber würden Sie die .scc und andere verwandte SourceSafe-Dateien ignorieren, wenn Sie Dateien zum Subversion/Mercurial-Repository hinzufügen? – tardomatic

+1

Dies wäre das einzige Problem gewesen, das ich vorhersehen konnte, und umgekehrt mit den '.svn.-Ordnern in VSS. Es ist eine Weile her, seit ich VSS benutzt habe, aber ich bin mir nicht sicher, ob es einfach ist, ganze Ordner zu ignorieren. Jemand? –

+0

@MarkB Es ist wichtig, dass die Verwendung von Subversion, wie ich es mir vorstelle, keinen Einfluss auf SourceSafe hat. Vorzugsweise möchte ich Ordner in SourceSafe usw. nicht ignorieren müssen. Ich bin kein quelloffener Administrator, und ich bin sehr skeptisch wäre daran interessiert Tausende von .svn-Ordnern zu ignorieren (Code ist> 1Gb) – tardomatic

2

Das scheint eine gute Idee, obwohl ich glaube nicht, dass Sie Ihre Repository, aber eine exportierte Version des Codes zu einem bestimmten Zeitpunkt festhalten sollte. Sie möchten sicherstellen, dass Sie keine .svn Ordner usw. zu SS hinzufügen. Überprüfen Sie in Ihrem Gebietsschema-Repository, was sich in SS ändern könnte.

Beachten Sie jedoch, dass SS erfordert, dass Sie Dateien explizit "checken", bevor Sie sie festschreiben ("checken") können. Das spielt schlecht mit SVNs Art, gleichzeitig an den gleichen Dateien zu arbeiten. Sie können etwas wie eine "vendor branch" benötigen, um Ihre Arbeit mit einem frisch ausgecheckten Arbeiten von SS zu erledigen, bevor Sie Ihre Sachen einchecken.

+1

Ich stelle mir vor, Subversion und SS haben den gleichen "Arbeitsordner", also werde ich immer noch den ganzen SS-Checkout machen, Arbeit an der Datei, Commit, wenn ich fertig bin . Subversion würde es mir erlauben, die Dateien, die ich bearbeitet habe, jederzeit in diesem Zyklus zu überprüfen. – tardomatic

+0

@tardomatic: Das Problem, auf das ich mich bezog, ist, dass SS jede Datei, die Sie auschecken, gegen Änderungen von anderen sperrt. Dies macht es unerwünscht, eine Datei für lange Zeiten ausgecheckt zu haben. Eine Möglichkeit, dies zu bewerkstelligen, besteht darin, alle Änderungen in einem SVN-Zweig vorzunehmen, die von SS geänderten Dateien in die Arbeitskopie des Stammes des SVN auszugeben, den Zweig in die Arbeitskopie des Stammes einzubinden und diese wieder an SS zu übergeben. Scheint wie eine große PITA, egal wie man es betrachtet. – sbi

Verwandte Themen