TortoiseSVN und ID

[Thomas N.]

Hallo,

vielleicht kennt sich jemand von Euch damit aus. Ich habe jetzt Tortoise SVN installiert und möchte in den Kopf meiner Dateien die ID eintragen lassen.

Hierzu gibt es einen guten Artikel, in dem das erklärt wird.

Aber muss ich dazu tatsächlich JEDE Datei öffnen und diesen Text eintragen. Oder gibt es in TSVN die Möglichkeit, das zu automatisieren?

Oder gibt es ein Programm, dass über viele Dateien hinweg einen Zusatz eintragen kann?

Grüße

Tom

[Sven Rautenberg]

Moin!

Aber muss ich dazu tatsächlich JEDE Datei öffnen und diesen Text eintragen. Oder gibt es in TSVN die Möglichkeit, das zu automatisieren?

Ja, musst du manuell (oder mit Programmhilfe automatisiert) in jeder Datei eintragen, die diese Id aktualisiert bekommen soll. TortoiseSVN ist da der falsche Ansprechpartner, weil Tortoise das selbst gar nicht tut, sondern das ein Feature von SVN allgemein ist - aber nur die Ersetzung von $Id$ (bzw. der Langform) durch die aktuellen Werte (wobei: Es gibt noch ein paar andere Keywords, die auch ersetzt werden, beispielsweise $Author$ und $Revision$, aber eben auch nur, wenn man die als SVN-Eigenschaft explizit benennt).

SVN kann das aber nicht automatisch tun, denn diese $Id$ muss ja an einer Stelle im Quelltext stehen, wo sie nichts stört, oder gar ZERSTÖRT, üblicherweise steht sie deshalb in einem Kommentarbereich. Dort hinein kommt sie aber eben nur, wenn ein Mensch entscheidet, wo und in welcher Form diese Id in den Quelltext passt.

Oder gibt es ein Programm, dass über viele Dateien hinweg einen Zusatz eintragen kann?

Zahlreiche Texteditoren haben allesamt das Feature, dateiübergreifend Suchen/Ersetzen zu betreiben.

- Sven Rautenberg

[Thomas N.]

• Sven Rautenberg

Hallo Sven,

recht herzlichen Dank für Deine Ausführungen.
Die haben mir geholfen.

Tschüss, Tom

[Thomas N.]

Hallo,

ich habe ein gutes Tutorial für den Umgang mit Tortoise SVN gefunden und gelesen, aber ich verstehe darin etwas nicht.

Vielleicht kann mir das jemand, der etwas erfahrener in Versionskontrollen ist, ja erklären. Deshalb frage ich das mal.

Szenario:

Er hat 3 Ordner: trunk, tags und branches. Nun ist der aktuelle Haupt-Quellcode im trunk und er hat einen Tag 1.0 erzeugt. Diese beiden Codes sind identisch.
Um nun entwickeln zu können, kopiert er genau diesen Quellcode in branches. Und fängt an zu entwickeln.
Jetzt entdeckt er einen Bug im Tag 1.0.
Also checkt er eine Arbeitskopie vom trunk aus und fixt den Bug. Und er erzeugt einen Tag namens 1.0.1
Damit ist bis hierher alles klar. Aber der aktuelle Entwicklungsversion im branch hat ja noch den Bug. Also merged er nun und genau hier verstehe ich den merge nicht.

Warum wird vom branch in den trunk gemerged?

Ich hätte nun gedacht, umngekehrt würde ein Schuh daraus. Im trunk steht doch der fix des Bugs drinne?

Kann mir das jemand erklären?

Tschüss, Tom

[Sven Rautenberg]

Moin!

Warum wird vom branch in den trunk gemerged?

Ich hätte nun gedacht, umngekehrt würde ein Schuh daraus. Im trunk steht doch der fix des Bugs drinne?

Kann mir das jemand erklären?

Ich möchte mal voraus schicken: Auch mit Subversion ist das Mergen eine Quelle ständigen ekligen Arbeitsaufwands. Grundsätzlich ist die Theorie, welche Änderungen wann von wo nach wohin übertragen werden müssen, natürlich klar. Das Problem mit Subversion ist, dass es extrem schwierig ist festzustellen, was denn schon alles geändert übertragen wurde, und was bislang noch fehlt.

Tatsächlich hört man auch allen möglichen Entwicklerkreisen, dass zwar das Branchen tatsächlich relativ gut funktioniert, aber das Mergen wird nur genau EINMAL vernünftig funktionieren, nämlich wenn man einen Branch wieder zurück in den Trunk führen will. Danach sollte man, um Probleme zu vermeiden, diesen Branch sterben lassen, und bei Bedarf einen neuen Branch anlegen.

Alternativ darf man, ausgestattet mit dem entsprechenden Expertenwissen, eine nicht ganz unaufwendige Planung veranstalten und entsprechende Hilfs-Tags anlegen, damit das sauber funktioniert. Alternativ: Bugfixes, die in mehr als einem Zweig (egal ob ein branch oder trunk) hinzugefügt werden müssen, werden manuell mehrfach appliziert.

Meine persönliche Konsequenz daraus: Ich nutze keine Branches, wenns vermeidbar ist - und dankenswerterweise ist das beim Entwickeln von internen Webapplikationen sehr simpel vermeidbar, weil man keine Produktpflege für mehrere Versionen betreiben muss, sondern alles immer im Trunk lassen könnte. Allerdings geht sowas nicht immer.

Die freundlichere Alternative ist ein verteiltes Versionskontrollsystem wie Git, Mercurial oder Bazaar. Bei diesen Systemen ist das Branchen und Mergen alltäglich, und es funktioniert dort extrem gut. Wenn du daher erst einsteigst in Versionskontrolle, solltest du Subversion direkt überspringen und die vernünftigen Tools verwenden.

- Sven Rautenberg

[Thomas N.]

Hi Sven,

Die freundlichere Alternative ist ein verteiltes Versionskontrollsystem wie Git

Käme mir insofern auch entgegen, weil ich auf 3 verschiedenen Rechnern entwickeln muss bzw. will.
Und er hier mient das auch.

Wenn du daher erst einsteigst in Versionskontrolle, solltest du Subversion direkt überspringen und die vernünftigen Tools verwenden.

Ja, ich steige grad erst ein. Bin auch durchaus zu einem Wechsel bereit. Leider findet man für GIT sehr viel weniger Einsteigertutorials. Wenn Du hierfür einen guten Link hast, wäre ich dankbar.

Und eine Frage noch: Gibt es auch für GIT einen Windows-Client oder gehen dort alle Befehle über die Kommandozeile?

Tschüss, Tom

[Sven Rautenberg]

Moin!

Die freundlichere Alternative ist ein verteiltes Versionskontrollsystem wie Git

Käme mir insofern auch entgegen, weil ich auf 3 verschiedenen Rechnern entwickeln muss bzw. will.
Und er hier mient das auch.

Wenn du daher erst einsteigst in Versionskontrolle, solltest du Subversion direkt überspringen und die vernünftigen Tools verwenden.

Ja, ich steige grad erst ein. Bin auch durchaus zu einem Wechsel bereit. Leider findet man für GIT sehr viel weniger Einsteigertutorials. Wenn Du hierfür einen guten Link hast, wäre ich dankbar.

Und eine Frage noch: Gibt es auch für GIT einen Windows-Client oder gehen dort alle Befehle über die Kommandozeile?

Es gibt TortoiseGIT, das zu installieren erfordert aber noch ein zweites GIT-Tool, das die Kommandozeile im Hintergrund realisiert - im Endeffekt ist dann aber alles schön in die Kontextmenüs von Windows integriert. Siehe Installationsanleitung.

Außerdem gibt es z.B. für Eclipse das Modul EGit, mit dem man die ganze Kiste auch dort ansteuern kann, ohne z.B. TortoiseGIT zu installieren.

- Sven Rautenberg

[Thomas N.]

Hallo Sven,

Es gibt TortoiseGIT,

ja, habe ich schon gesehen, aber vielerorts liest man auch, dass das noch nicht wirklich ausgereift sein soll.

Was hältst Du denn von Bazaar? Da scheint ja eine eigene GUI dabei zu sein. Und wie es scheint, legen die Bazaar-Entwickler besonderen Wert auf einen einfachen Einstieg in die Benutzung.

Also wenn GIT und Bazaar qualitativ gleichwertig sind, fände ich derzeit Bazaar sympathischer.

Bazaar empfehlenswert?

Zumindest besser als SVN??

Tschüss, Tom

[Rouven]

Hello,

Kann mir das jemand erklären?

ich behaupte dieser Thread hat dazu genau die richtige Kategorie - am Ende des Tages gibt es Best Practices zur Projektverwaltung, sprich was brancht man und wo entwickelt man.
Im Tutorial wird der Ansatz gewählt den Trunk oder Head (je nach Versionsverwaltung) als Master zu nehmen, in dem Bugs gefixed und quasi "approved" Features eingemerged werden, so dass alle Lieferungen NACH dem Merge vom Head erfolgen, die Branches als solche sind die Spielwiese oder Kinderstube für Fixes. Du würdest also auf dem Branch erstmal nur dein neues Feature entwickeln (vielleicht stört dich der Bug gar nicht, deine Entscheidung) und am Ende des fertige Feature in den Trunk einzubringen.
Bei uns im Projekt wird beispielsweise genau der gegenteilige Ansatz gewählt, die Spielwiese oder Kinderstube ist der Trunk bzw. Head weil klar ist, dass sowieso alle Entwicklungsarbeiten in das nächste Release reinMÜSSEN. Bei uns existiert ein Tag quasi als Basis eines Branches, gewissermaßen ein Wartungsbranch, den wir nur benutzen um gemeldete Fehler zu versorgen und dann in den Trunk/Head zurückzumergen.

Wie gesagt, ich halte es für eine organisatorische Frage, ich bin nicht vertraut genug mit Subversion oder nicht-projektgetriebener Organisation um zu sagen ob das Tutorial die Best-Practice darstellt.

MfG
Rouven

[dedlfix]

Hi Rouven!

'tschuldigung, Thomas N., wenn ich den Thread hier mal kapere, aber weil ich dich, Rouven, hier grad sehe: Hast du was dagegen, wenn dein Datenbank-Join-Artikel SELFHTML-Wiki-fiziert wird? (Vinzenz hatte mit der Fortsetzung ja schonmal angefangen.) Neben den Joins kommt ja bei Fragen hier als Antwort auch immer wieder "korrelierte Unterabfragen" als die bessere Alternative. Das würde sich als Ergänzung noch gut machen. Natürlich darfst du den Artikel auch gern selbst "rübertragen" (und ergänzen), ich wollte hier erstmal nur deine Meinung zu einem OK oder Veto erfragen.

Lo!

[Rouven]

Hello,

"rübertragen" (und ergänzen), ich wollte hier erstmal nur deine Meinung zu einem OK oder Veto erfragen.

sorry für die Verzögerung, da kriegst du sofort ein OK von mir. Würde gerne selbe, aber mein Privatleben sowie mein Berufsleben sorgen gerade beide dafür, dass ich hier kaum noch zum lesen und schon gar nicht mehr zum was schreiben komme :-(

MfG
Rouven

[dedlfix]

Hi!

sorry für die Verzögerung, da kriegst du sofort ein OK von mir.

Kein Problem und danke.

Lo!

[Thomas N.]

Hi Rouven,

Kann mir das jemand erklären?
ich behaupte dieser Thread hat dazu genau die richtige Kategorie

Nehm ich als Kompliment, danke.

Im Tutorial wird der Ansatz gewählt ...  Du würdest also auf dem Branch erstmal nur dein neues Feature entwickeln (vielleicht stört dich der Bug gar nicht, deine Entscheidung) und am Ende des fertige Feature in den Trunk einzubringen.

So habe ich das auch verstanden.

Bei uns im Projekt wird beispielsweise genau der gegenteilige Ansatz gewählt, die Spielwiese oder Kinderstube ist der Trunk bzw. Head weil klar ist, dass sowieso alle Entwicklungsarbeiten in das nächste Release reinMÜSSEN.
Bei uns existiert ein Tag quasi als Basis eines Branches, gewissermaßen ein Wartungsbranch, den wir nur benutzen um gemeldete Fehler zu versorgen und dann in den Trunk/Head zurückzumergen.

Verstehe ich Dich richtig, dass Ihr im Trunk arbeitet, nachdem ich den zuvor in einen branch gecloned habt. Und bei Bugfixen macht Ihr die im Branch und merged den zurück in den Trunk?

Worin seht Ihr den Vorteil dieser Vorgehensweise?

Ich dachte, gerade die Verwundung von branches als Spielwiesen gäbe mir die Freiheit, auch mal wirklich ein bißchen innerhalb der Entwicklung spielen zu können und es mal übernehmen und mal wieder verwerfen zu können?

Tschüss, Tom

[Rouven]

Hello,

Worin seht Ihr den Vorteil dieser Vorgehensweise?

in unserem Versionsverwaltungssystem, wobei das eher der Grund für die Vorgehensweise ist. Zwar unterstützt das System (IBM Rational ClearCase) auch sowas wie Tags, aber ein Tag fasst zunächst mal nur einen Softwarestand zusammen, einen Tag kann man nicht weiterentwickeln, man kann nur sagen "gib mir den Code für das Tag 1.0". Wenn ich an den Code dran will brauch ich einen Branch, der auf diesem Tag basiert.
Szenario: Projekt, das in mehreren Iterationen entwickelt. Erste Iteration ist entwicklungstechnisch (Implementierung, Unit Test) abgeschlossen und geht nun in Integrations- oder Fachtest. Parallel dazu startet die nächste Iteration. Nun meldet der Test einen Fehler. Was definitiv NICHT geht, ist dass ich jetzt den Trunk ausliefere, da ist ja schon andere Funktionalität drin. Also fixe ich auf dem Branch, liefere dem Test den Branch aus und merge den Fix in meinen weiterentwickelten Code auf dem Trunk.
Klar, ich kann es genau umdrehen und die Weiterentwicklung auf dem Branch machen, bei uns wurde mal entschieden, dass es leichter ist Defects aus einem Branch in den Trunk zu mergen als Funktionalität aus einem Branch in eine bug-gefixte Version zu mergen, was vielleicht sogar kein Merge sondern ein Replace wäre. Schätzungsrationale vielleicht sowas wie "ich fixe 100 Defects, entwickele aber 300 Funktionen neu, was will ich jetzt lieber mergen"?

MfG
Rouven