it-swarm.com.de

Wie benutzt man SVN, Branch? Etikett? Kofferraum?

Ich habe ein bisschen gegoogelt und konnte keine gute Anleitung für "Anfänger" für SVN finden, nicht im Sinne von "Wie verwende ich die Befehle?" " lieber; Wie kontrolliere ich meinen Quellcode?

Was ich aufklären möchte, sind die folgenden Themen:

  • Wie oft legen Sie fest? So oft man drücken würde Ctrl + s?
  • Was ist ein Branch und was ist ein Tag und wie steuern Sie sie?
  • Was geht in die SVN? Nur Quellcode oder teilen Sie hier auch andere Dateien? (Nicht als versionierte Dateien angesehen.)

Ich habe keine Ahnung, was Zweig und Tag sind, daher kenne ich den Zweck nicht, aber ich vermute, dass Sie Sachen in den Kofferraum hochladen und wenn Sie einen größeren Build erstellen, verschieben Sie sie in den Zweig? Was wird in diesem Fall als wichtiger Build angesehen?

163
Filip Ekberg

Das Subversion-Buch ist eine hervorragende Informationsquelle für Strategien zum Anordnen Ihres Repositorys, zum Verzweigen und zum Markieren.

Siehe auch:

Entwickeln Sie sich in einer Filiale oder im Stamm weiter

Verzweigungsstrategien

60
Ken

Ich habe mir die gleichen Fragen gestellt, als wir Subversion hier implementierten - ungefähr 20 Entwickler, verteilt auf 4 - 6 Projekte. Ich habe keine gute Quelle mit der Antwort gefunden. Hier sind einige Teile davon, wie sich unsere Antwort in den letzten 3 Jahren entwickelt hat:

- so oft festsetzen, wie es sinnvoll ist; Unsere Faustregel lautet: Festschreiben, wann immer Sie genügend Arbeit geleistet haben, so dass es ein Problem wäre, dies erneut zu tun, wenn die Änderungen verloren gingen. manchmal gebe ich alle 15 Minuten oder so ein, manchmal sind es Tage (ja, manchmal brauche ich einen Tag, um eine Codezeile zu schreiben)

- Wir verwenden Zweige, wie eine Ihrer früheren Antworten vorgeschlagen hat, für verschiedene Entwicklungspfade. Derzeit haben wir für eines unserer Programme drei aktive Zweige: einen für die Hauptentwicklung, einen für die noch nicht abgeschlossenen Bemühungen, das Programm zu parallelisieren, und einen für die Bemühungen, es zu überarbeiten, um XML-Eingabe- und Ausgabedateien zu verwenden.

- Wir verwenden kaum Tags, obwohl wir der Meinung sind, dass wir sie verwenden sollten, um Veröffentlichungen für die Produktion zu identifizieren.

Denken Sie an die Entwicklung auf einem einzigen Weg. Irgendwann oder nach dem Stand des Entwicklungsmarketings beschließen Sie, die erste Version des Produkts freizugeben, sodass Sie eine Flagge in den Pfad mit der Bezeichnung "1" (oder "1.0" oder was haben Sie?) Setzen. Zu einem anderen Zeitpunkt beschließt ein schlauerspark, das Programm zu parallelisieren, entscheidet jedoch, dass dies Wochen dauern wird und dass die Leute in der Zwischenzeit den Hauptweg weitergehen wollen. Du baust also eine Weggabelung und verschiedene Leute wandern über die verschiedenen Gabeln.

Die Flaggen in der Straße werden als "Tags" bezeichnet, und die Gabeln in der Straße sind dort, wo sich "Zweige" teilen. Gelegentlich kommen auch Zweige wieder zusammen.

- Wir legen das gesamte Material, das zum Erstellen einer ausführbaren Datei (oder eines Systems) erforderlich ist, im Repository ab. Das bedeutet mindestens Quellcode und Make-Datei (oder Projektdateien für Visual Studio). Aber wenn wir Icons und Konfigurationsdateien und all das andere Zeug haben, geht das in das Repository. Einige Dokumentationen finden Eingang in das Repo. Natürlich ist jede Dokumentation, wie z. B. Hilfedateien, die ein wesentlicher Bestandteil des Programms sind, hilfreich, um Entwicklerdokumentationen zu speichern.

Wir haben sogar ausführbare Windows-Dateien für unsere Produktionsversionen dort abgelegt, um einen einzigen Speicherort für Benutzer bereitzustellen, die nach Software suchen. Unsere Linux-Versionen werden auf einem Server gespeichert, sodass sie nicht gespeichert werden müssen.

- Wir fordern nicht, dass das Repository jederzeit in der Lage ist, eine aktuelle Version zu liefern, die erstellt und ausgeführt wird. Einige Projekte funktionieren so, andere nicht. Die Entscheidung liegt beim Projektmanager und hängt von vielen Faktoren ab, aber ich denke, sie schlägt fehl, wenn größere Änderungen an einem Programm vorgenommen werden.

86
* How often do you commit? As often as one would press ctrl + s?

So oft es geht. Code existiert nur, wenn er sich in der Quellcodeverwaltung befindet :)

Häufige Festschreibungen (danach kleinere Änderungssätze) ermöglichen es Ihnen, Ihre Änderungen einfach zu integrieren und die Wahrscheinlichkeit zu erhöhen, dass etwas nicht kaputt geht.

Andere Leute sagten, dass Sie ein Commit durchführen sollten, wenn Sie einen funktionalen Code haben. Ich finde es jedoch nützlich, dass Sie etwas häufiger ein Commit durchführen. Einige Male habe ich bemerkt, dass ich die Quellcodeverwaltung als schnellen Mechanismus zum Rückgängigmachen/Wiederherstellen verwende.

Wenn ich in meiner eigenen Niederlassung arbeite, bevorzuge ich es, so viel wie möglich zu verpflichten (buchstäblich so oft ich Strg + s drücke).

* What is a Branch and what is a Tag and how do you control them?

Lesen Sie SVN-Buch - hier sollten Sie anfangen, wenn Sie SVN lernen:

* What goes into the SVN?

Dokumentation, kleine Binärdateien, die für Builds benötigt werden, und andere Dinge, die einen gewissen Wert haben, gehen in die Quellcodeverwaltung.

18
aku

Im Folgenden finden Sie einige Ressourcen zu Commit-Häufigkeit, Commit-Meldungen, Projektstruktur, Versionskontrolle und anderen allgemeinen Richtlinien:

Diese Fragen zum Stapelüberlauf enthalten auch einige nützliche Informationen, die von Interesse sein können:

Bezüglich der grundlegenden Subversion-Konzepte wie Verzweigen und Markieren denke ich, dass dies in dem Subversion-Buch sehr gut erklärt ist.

Wie Sie vielleicht feststellen, sind die Meinungen der Menschen zu den besten Praktiken in diesem Bereich oft unterschiedlich und manchmal widersprüchlich. Ich denke, die beste Option für Sie ist es, zu lesen, was andere Leute tun, und die Richtlinien und Praktiken auszuwählen, die für Sie am sinnvollsten sind.

Ich halte es nicht für eine gute Idee, eine Praxis anzuwenden, wenn Sie den Zweck nicht verstehen oder der dahinter stehenden Begründung nicht zustimmen. Befolgen Sie also keine Ratschläge blind, sondern überlegen Sie sich selbst, was Ihrer Meinung nach am besten für Sie funktioniert. Das Experimentieren mit verschiedenen Methoden ist auch eine gute Möglichkeit, um herauszufinden, wie Sie am liebsten arbeiten. Ein gutes Beispiel dafür ist die Strukturierung des Repositorys. Es gibt keinen richtigen oder falschen Weg, und es ist oft schwer zu wissen, welchen Weg Sie bevorzugen, bis Sie sie tatsächlich in der Praxis ausprobiert haben.

11
Anders Sandvig

Die Häufigkeit des Commits hängt von Ihrer Art des Projektmanagements ab. Viele Leute sehen davon ab, sich zu verpflichten, wenn der Build (oder die Funktionalität) beschädigt wird.

Zweige können in der Regel auf zwei Arten verwendet werden: 1) Ein aktiver Zweig für die Entwicklung (und der Stamm bleibt stabil) oder 2) Zweige für alternative Entwicklerpfade.

Tags werden im Allgemeinen zur Identifizierung von Releases verwendet, damit sie nicht im Mix verloren gehen. Die Definition von 'Release' liegt bei Ihnen.

8
Cody Brocious

Ich denke, das Hauptproblem ist, dass das mentale Bild der Quellcodeverwaltung verwirrt ist. Wir haben normalerweise Trunk und Branches, aber dann bekommen wir Ideen, die nichts mit Tags/Releases zu tun haben, oder ähnliches.

Wenn Sie die Idee eines Baumes vollständiger nutzen, wird es klarer, zumindest für mich ist es das.

Wir bekommen den Kofferraum -> bilden Äste -> produzieren Früchte (Tags/Releases).

Die Idee ist, dass Sie das Projekt aus einem Stamm aufbauen, der dann Zweige erstellt, wenn der Stamm stabil genug ist, um den Zweig zu halten. Wenn der Zweig eine Frucht hervorgebracht hat, pflücken Sie ihn aus dem Zweig und geben ihn als Etikett frei.

Tags sind im Wesentlichen Liefergegenstände. Während Stamm und Äste sie produzieren.

6
Pete

Wie andere gesagt haben, ist das SVN-Buch der beste Ausgangspunkt und eine gute Referenz, wenn Sie Ihre Seebeine haben. Nun zu deinen Fragen ...

Wie oft legen Sie fest? So oft man Strg + S drückt?

Oft, aber nicht so oft, wie Sie Strg + s drücken. Es ist eine Frage des persönlichen Geschmacks und/oder der Teampolitik. Persönlich würde ich Commit sagen, wenn Sie einen funktionalen Code vervollständigen, egal wie klein er ist.

Was ist ein Branch und was ist ein Tag und wie steuern Sie sie?

Erstens ist Kofferraum der Ort, an dem Sie Ihre aktive Entwicklung durchführen. Es ist die Hauptzeile Ihres Codes. Ein Ast ist eine Abweichung von der Hauptlinie. Es könnte eine große Abweichung sein, wie in einer früheren Version, oder nur eine kleine Änderung, die Sie ausprobieren möchten. Ein Tag ist eine Momentaufnahme Ihres Codes. Auf diese Weise können Sie einer bestimmten Revision ein Etikett oder ein Lesezeichen hinzufügen.

Erwähnenswert ist auch, dass in Subversion Trunk, Branches und Tags nur Konventionen sind. Nichts hindert Sie daran, in Tags zu arbeiten oder Zweige zu haben, die Ihre Hauptlinie sind, oder das Tag-Zweig-Trunk-Schema insgesamt zu ignorieren. Aber es sei denn, Sie haben einen sehr guten Grund, ist es am besten, sich an die Konvention zu halten.

Was geht in die SVN? Nur Quellcode oder teilen Sie hier auch andere Dateien?

Auch eine persönliche oder Teamwahl. Ich bevorzuge es, alles, was mit dem Build zu tun hat, in meinem Repository zu behalten. Dazu gehören Konfigurationsdateien, Erstellungsskripte, zugehörige Mediendateien, Dokumente usw. Sie sollten nicht Dateien einchecken, die auf dem Computer jedes Entwicklers unterschiedlich sein müssen. Sie müssen auch keine Nebenprodukte Ihres Codes einchecken. Ich denke hauptsächlich an Build-Ordner, Objektdateien und dergleichen.

4
Gordon Wilson

Eric Sink, der im Januar 2009 auf SO podcast # 36 erschien, schrieb eine exzellente Artikelserie unter dem Titel Source Control How-to .

(Eric ist der Gründer von SourceGear , der eine Plug-kompatible Version von SourceSafe vermarktet, aber ohne die Schrecklichkeit.)

4
Mike Woodhouse

Nur um weitere Antworten hinzuzufügen:

  • Ich lege fest, wann immer ich ein Stück Arbeit beende. Manchmal ist es ein kleiner Bugfix, der nur eine Zeile geändert hat und für den ich 2 Minuten gebraucht habe. ein andermal ist es zwei Wochen Schweiß wert. Als Faustregel gilt auch, dass Sie nichts festlegen, das den Build bricht. Wenn Sie also lange Zeit gebraucht haben, nehmen Sie vor dem Festschreiben die neueste Version und prüfen Sie, ob Ihre Änderungen den Build beschädigen. Natürlich ist es mir unangenehm, wenn ich längere Zeit nicht festlege, weil ich diese Arbeit nicht verlieren möchte. In TFS verwende ich dieses nette Ding als "Regale" dafür. In SVN müssen Sie auf andere Weise umgehen. Erstellen Sie möglicherweise Ihren eigenen Zweig oder sichern Sie diese Dateien manuell auf einem anderen Computer.
  • Zweige sind Kopien Ihres gesamten Projekts. Die beste Illustration für ihre Verwendung ist möglicherweise die Versionierung von Produkten. Stellen Sie sich vor, Sie arbeiten an einem großen Projekt (etwa dem Linux-Kernel). Nach Monaten des Schweißes sind Sie endlich bei Version 1.0 angekommen, die Sie der Öffentlichkeit zugänglich machen. Danach fangen Sie an, an der Version 2.0 Ihres Produkts zu arbeiten, die viel besser sein wird. Mittlerweile gibt es aber auch viele Leute, die Version 1.0 verwenden. Und diese Leute finden Fehler, die Sie beheben müssen. Jetzt können Sie den Fehler in der kommenden Version 2.0 nicht beheben und an die Kunden senden - es ist überhaupt nicht bereit. Stattdessen müssen Sie eine alte Kopie der 1.0-Quelle herausnehmen, den Fehler dort beheben und diese an die Leute versenden. Dafür sind Branchen da. Als Sie die Version 1.0 veröffentlicht haben, haben Sie eine Verzweigung in SVN erstellt, die zu diesem Zeitpunkt eine Kopie des Quellcodes erstellt hat. Dieser Zweig wurde "1.0" genannt. Sie haben dann die Arbeit an der nächsten Version in Ihrer Hauptquellkopie fortgesetzt, aber die 1.0-Kopie blieb dort wie zum Zeitpunkt der Veröffentlichung. Und Sie können dort weiterhin Fehler beheben. Tags sind lediglich Namen, die zur Vereinfachung der Verwendung an bestimmte Revisionen angehängt sind. Sie könnten "Revision 2342 des Quellcodes" sagen, aber es ist einfacher, ihn als "Erste stabile Revision" zu bezeichnen. :)
  • Normalerweise lege ich alles in die Quellcodeverwaltung, was sich direkt auf die Programmierung bezieht. Da ich zum Beispiel Webseiten erstelle, lege ich auch Bilder und CSS-Dateien in die Quellcodeverwaltung, ganz zu schweigen von Konfigurationsdateien usw. Die Projektdokumentation ist dort nicht enthalten, aber das ist eigentlich nur eine Frage der Präferenz.
4
Vilx-

Andere haben angegeben, dass es von Ihrem Stil abhängt.

Die große Frage für Sie ist, wie oft Sie Ihre Software "integrieren". Testgetriebene Entwicklung, Agile und Scrum (und viele andere) setzen auf kleine Änderungen und kontinuierliche Integration. Sie predigen, dass kleine Änderungen vorgenommen werden, jeder die Pausen findet und sie die ganze Zeit repariert.

Bei einem größeren Projekt (Regierung, Verteidigung, 100.000 + LOK) können Sie jedoch keine kontinuierliche Integration verwenden, da dies nicht möglich ist. In diesen Situationen ist es möglicherweise besser, mithilfe der Verzweigung viele kleine Commits auszuführen, aber NUR das, was funktioniert und bereit ist, in den Build integriert zu werden, wieder in den Kofferraum zu bringen.

Eine Einschränkung bei der Verzweigung ist jedoch, dass es ein Albtraum in Ihrem Repository sein kann, Arbeit in den Kofferraum zu befördern, da sich jeder von verschiedenen Stellen im Kofferraum aus entwickelt (was im Übrigen eines der größten Argumente dafür ist) kontinuierliche Integration).

Es gibt keine endgültige Antwort auf diese Frage. Am besten arbeiten Sie mit Ihrem Team zusammen, um die beste Kompromisslösung zu finden.

3
Spence

Versionskontrolle mit Subversion ist der Leitfaden für Anfänger und alte Hasen gleichermaßen.

Ich glaube nicht, dass Sie Subversion effektiv einsetzen können, ohne zumindest die ersten Kapitel zu lesen.

2
slim

Für das Festschreiben verwende ich die folgenden Strategien:

  • so oft wie möglich begehen.

  • Jede Funktionsänderung/Bugfix sollte ein eigenes Commit erhalten (nicht viele Dateien auf einmal festschreiben, da dies den Verlauf für diese Datei unübersichtlich macht - z. B. wenn ich ein Protokollierungsmodul und ein GUI-Modul unabhängig voneinander ändere und beide gleichzeitig festschreibe, Beide Änderungen sind in beiden Dateiversionen sichtbar, was das Lesen einer Dateiversion erschwert.

  • unterbrechen Sie nicht den Build für ein Commit - es sollte möglich sein, eine beliebige Version des Repository abzurufen und zu erstellen.

Alle Dateien, die zum Erstellen und Ausführen der App erforderlich sind, sollten sich in SVN befinden. Testdateien und dergleichen sollten nicht verwendet werden, es sei denn, sie sind Teil der Komponententests.

1
Lennaert

Die Richtlinien bei unserer Arbeit lauten wie folgt (Team aus mehreren Entwicklern, die an einem objektorientierten Framework arbeiten):

  • Aktualisieren Sie SVN jeden Tag, um die Änderungen des vorherigen Tages zu erhalten

  • Legen Sie täglich fest, damit bei Krankheit oder Abwesenheit am nächsten Tag leicht jemand anderes die Stelle übernehmen kann, an der Sie aufgehört haben.

  • Schreiben Sie keinen Code ein, der irgendetwas kaputt macht, da dies Auswirkungen auf die anderen Entwickler hat.

  • Arbeiten Sie an kleinen Stücken und legen Sie täglich MIT BEDEUTENDEN KOMMENTAR fest!

  • Als Team: Behalten Sie eine Entwicklungsniederlassung bei, und verschieben Sie dann den Vorabversionscode (für die Qualitätssicherung) in eine Produktionsniederlassung. Dieser Zweig sollte immer nur voll funktionsfähigen Code haben.

1
LilGames

Viele gute Kommentare hier, aber etwas, das nicht erwähnt wurde, sind Commit-Nachrichten. Diese sollten verbindlich und aussagekräftig sein. Besonders beim Verzweigen/Zusammenführen. Auf diese Weise können Sie verfolgen, welche Änderungen für welche Fehlerfunktionen relevant sind.

zum Beispiel svn commit . -m 'bug #201 fixed y2k bug in code' wird jedem, der sich die Geschichte ansieht, mitteilen, wofür diese Überarbeitung gedacht war.

Einige Bug-Tracking-Systeme (z. B. Trac) können nach diesen Nachrichten im Repository suchen und sie mit den Tickets verknüpfen. Das macht es sehr einfach herauszufinden, welche Änderungen mit jedem Ticket verbunden sind.

1
Jeremy French

Das TortoiseSVN TSVN-Handbuch basiert auf Subversion-Buch , ist jedoch in viel mehr Sprachen verfügbar.

0
Xn0vv3r

Ich denke, es gibt zwei Möglichkeiten, die Frequenz festzulegen:

  1. Festschreiben Sie sehr oft für jede implementierte Methode, einen kleinen Teil des Codes usw.
  2. Übertragen Sie nur fertige Codeteile wie Module usw.

Ich bevorzuge das erste - weil die Verwendung des Versionsverwaltungssystems nicht nur für Projekte oder Unternehmen sehr nützlich ist, sondern vor allem für den Entwickler. Für mich ist das beste Feature, den gesamten Code zurückzusetzen, während die am besten zugewiesene Aufgabenimplementierung durchsucht wird.

0
abatishchev