Subversion Verwendungen [geschlossen]

Question

Ich bin gerade erst anfangen zu verwenden "Subversion" mit "Tortoise SVN-client" für eine meiner opensource-Projekt gehostet auf "Google-Code".Ich würde gerne einige best practices zu verwenden.Ich bin nach dem Standard-Ordner-Struktur(Stamm,Zweig,tag).Im folgenden sind die Fragen

1. Wann werden Sie die ersten checkin?Ist es nur, nach abgeschlossen eine Reihe von features oder vom ersten Tag der Entwicklung?
2. Zu dem Verzeichnis der initial checkin geht?Ist es in den "Stamm" oder Anreise zu "Zweig" und Zusammenführen, um den "Stamm" sobald eine Funktion abgeschlossen ist.In diesem Fall den "Stamm" bleibt leer, bis die Funktion fertig ist.
3. Immer wenn änderungen vorgenommen werden, werden Sie checkin "Stamm" direkt?Wenn Sie nicht Ihre Arbeitskopie wird immer mit "Niederlassung" - Verzeichnis, richtig?

Jede Hilfe würde geschätzt werden.

Answer 1

1. Ich empfehle Ihnen, check-in Ihren Dateien, bevor Sie beginnen, machen Sie eine schwere Veränderungen (einen früheren check-in, check-in oft).

2. Es hängt davon ab, wie einige Leute zu haben Kofferraum stabil, arbeiten in den Zweigen, und dann verschmelzen Sie die äste zurück zum Stamm, wenn die Funktionen einsatzbereit sind, aber Sie können sich auch verpflichten, direkt an den Stamm.

3. Es hängt auch davon ab, wie Sie arbeiten und was Sie gerne tun zu haben, im Kofferraum (die neueste stabile version oder den neuesten bleeding edge-version).

Answer 2

Ich schlage vor, Check-in früh und oft.

Es gibt viele Möglichkeiten, dies zu tun, aber die häufigsten habe ich erfolgreich gearbeitet wird, arbeiten aus einem Zweig und Zusammenführung der Stamm wenn Sie zu einem stabilen Punkt (minor version releases, Meilensteine, etc).

Wenn Sie nicht bereits haben, schauen Sie sich die red book, es ist eine großartige Ressource für svn Informationen.

Answer 3

Beim erstellen eines neuen Projekts von Grund habe ich meist so in einem Benutzerbereich in SVN-wie

/svn/users/me/project1

dies ist, weil die meisten Projekte beginnen als wegwerfen Prototypen und ich habe selten Verwendung der Zweige für diese.Sobald ein Projekt wird offiziell und nähert es der erste "Prototyp" - Version, die ich migrieren es über sein eigenes repository

/svn/project1/trunk

Die Verwendung von Zweigen erfordern ein wenig zusätzliche Arbeit, so dass wir Sie nicht verwenden, es sei denn, Sie sind notwendig.Was ist, wenn mehrere Leute am selben Projekt arbeiten und Kollisionen sind Häufig, oder ich arbeite an einer Funktion, die könnte ich entscheiden, zu der Sie zurückkehren und wegwerfen.Wenn man in einer Filiale kann ich einfach nicht Zusammenführen und löschen Sie es einfach.

Answer 4

Alle Antworten, die vorschlagen, dass Sie einen früheren check-in, check-in oft, ich konnte nicht mehr Zustimmen.So das ist alles, was ich sage über, dass.Aber ich lese die Zusammenfassung:Was für eine Art verwendet, kann Subversion passen?Also hier ist eine Antwort.

Ich habe gelesen, etwa Firmen, die mit Subversion Ihre Anwendung repository.Also, Sie sagen dem server, dass Sie möchten, installieren Sie die Version X von Y. AnwendungDann läuft der server ein update auf dem SVN-server.Und Sie auch eine gespeicherte Konfiguration Dateien auch drin.Und alle änderungen an der Konfiguration (über eine separate web-Schnittstelle für den end-Kunden) waren, dann verpflichtet sich der SVN config-repo.Das ist Brillant.'Natürlich sind diese Jungs wurden mit Hilfe von MS Power Shell auf Win2k3, aber immer noch die Technik angewandt werden kann anderswo.

Answer 5

Check-in ab SOFORT, nicht mehr früh.Auch wenn Sie nichts mehr zu verpflichten, als eine ad-hoc-text-Datei mit Geistesblitze und einige furchtbar kryptischen psuedo-code, verpflichten es.

Ich (wie so viele) Projekte finden, die genau wie deine ist dabei eine Art code-Suche, oder die Suche nach einem Programm, das tut, was ich will.Ich lese deine vordere Seite dann sofort durchsuchen Sie Ihre SVN trunk zu sehen, was du tust.

Wenn Sie die null-code im Kofferraum, ich werde wahrscheinlich vergessen, alles über Sie.Wenn Sie mindestens eine Datei zur Erklärung Ihrer gewünschten design, und einige Pseudo-code, ich werde wahrscheinlich senden Sie patches, die zeigen, dass meine Ideen.

Ein Projekt mit einem leeren repository schreit "Juckreiz, der wird niemals gekratzt werden" ..so schieben Sie etwas so schnell wie Sie können.

Nach diesem, Begehen oft.Ich mache gerne viele kleine, bestellt Verpflichtungen, so dass seine leicht zu verfolgen, Regressionen und roll-back/fix giftig Revisionen.

Answer 6

1. Check-in, sobald Sie erstellt haben Ihre leer baseline Projekt/Projektmappe Struktur.Leer, weil in diesem Zustand ist es tatsächlich kompilierbar wenn auch keine funktionierenden code.Das Prinzip ist, dass die gesamte Projekt - mindestens - in eine kompilierbare Zustand während der Entwicklung, als das team schrittweise und regelmäßig begeht kleine Veränderungen, so dass der Aufbau kaum kaputt.

2. Es gibt kein Gesetz, dass die ersten check-in müssen geschehen an den Stamm oder einen Zweig.Sie können starten Sie den Stamm mit einem leeren Projekt, so es ist stabil, von Anfang an, dann verzweigen sich die Durchführung der Entwicklung, und führen Sie Sie zurück in den Stamm einmal abgeschlossen.Sie können auch wählen, um den check-in das leere Projekt auf einen Zweig und entwickeln die ersten arbeiten oder Basis-feature vor dem Zusammenfügen etwas substanzielles in den Kofferraum.So oder so, basierend auf dem Punkt #1 der Stamm sollte stabil sein und hohe Qualität.Nur Zusammenführen qualitativ hochwertige Inhalte in den Kofferraum.

3. Wieder gibt es kein strenges Mandat auf diese Art von Praktiken.Einige teams branch out alles, auch einfache Umgestaltung von Variablen-Namen ändert.Einige teams nicht einmal wissen, verzweigen/Zusammenführen und zu entwickeln, alles in einem einzigen Zweig (der Stamm).Jedes team hat seine eigene Ebene des Gleichgewichts auf dieses Problem.Meine persönliche Leitlinie ist, wenn es neue Funktionen oder Fehlerkorrekturen oder re-design, Zweig es aus, um zu testen.Wenn es einen kleinen fix wie string Rechtschreibfehler oder die Anzeige von vier Dezimalstellen statt zwei in die web Seite, zur Festsetzung der Rumpf kopieren sollte ausreichen.Natürlich, Interpretationen von "major" und "minor" gehen, unterscheiden sich so der Entwicklung/team leads sollten, um Ihre standards.Entweder Weg, es muss sein, unit/integration tests begleitend zu den änderungen überprüfen Sie den Zweig oder Stamm arbeiten, wie beabsichtigt, als Mangel-frei wie möglich.Das Schlüsselwort ist daran zu erinnern, immer "hohe Qualität, getestet-code".