Versionierung: Wie macht ihr das?

[GregorS]

Hallo zusammen!

Meine Frage steht ja schon im Betreff. Da ich in Programmierdingen Einzelkämpfer bin, bin ich bezügl. meiner Arbeitsweisen, Verfahren usw. vollkommen frei, was Vor- und Nachteile hat. Als Nachteil empfinde ich immer wieder das Fehlen fast jeglicher Möglichkeiten zum fachlichen Austausch. Deshalb wüsste ich gerne, wie Ihr das mit den Versionsnummern so handhabt.

Wie ich das mache: Wenn ich ein Programm beginne, bekommt es zunächst Versionsnummer 0.1. Diese wird so lange hochgezählt (wenn’s sein muss bis 0.99999z), bis ich der Meinung bin, dass es "fertig" ist. Das ist dann der Fall, wenn es alles kann, was ich mir zuerst vorgenommen bzw. vorgestellt habe. Gleichzeitig erhält die Versionsnummer eine dritte Stelle. Erste „echte“ Version ist also 1.0.0.
Dann geht’s so weiter: Wenn ich nur eine kleine Änderung mache, z.B. einen Tippfehler in einem Ausgabetext korrigiere, der keine Auswirkungen auf den Programmablauf oder die gehandhabten Daten hat, wird an der dritten Stelle hochgezählt. Implementiere ich ein neues Feature oder ändere etwas so ab, dass es sich auf den Programmablauf oder die gehandhabten Daten auswirkt, zähle ich die zweite Stelle hoch, die dritte wird dabei wieder auf Null zurückgesetzt. Analog läuft’s mit der ersten Stelle, die ich nur dann hochzähle, wenn ich meine, dass das neue Ergebnis meiner Änderung(en) etwas wirklich „Großes“ ist.

So, genug gesülzt. Jetzt seid Ihr dran. Ich freue mich übrigens auch über Hinweise zu thematisch relevantem Lesestoff.

Grüße

Gregor

[schorsch_76]

Hi GregorS,

ich hab das auch ne zeitlang so gemacht bin aber davon abgekommen da ich in der Firma keine Software entwickle die über bis bsp 8.5.9 kommt. Bei uns gibt es einen großen Entwicklungsschub bis die Software das Lasten/Pflichtenheft erfüllt. Danach gibt es meistens Bugfixes und kleinere Erweiterungen. Mittlerweile handhabe ich es so, dass ich eine "svninfo.cpp" automatisch generieren lasse und diese in einen About Dialog anzeigen lasse. Hier hab ich die Ausgaben von

Code: Alles auswählen

svnversion
svn status --verbose

So kann ich immer exakt nachvollziehen welche Version ich aus den svn ziehen muss falls es einen Bug gibt.

Gruß

schorsch

[michaels]

Hallo,

wir machen es ähnlich wie Gregor auch:

"major release"."minor release"."patch level"

Major ändert sich recht selten. Je nach Projekt geben wir auch Programme frei, die noch nicht ganz abgeschlossen sind, von dem aber schon Teilbereiche genutzt werden sollen. Minor wird bei Releases mit neuen Funktionen geändert, Patch bei Fehlerkorrekturen (natürlich äußerst selten ).

Die Idee mit der Subversion Revision finde ich aber auch ganz gut, könnte man ja auch noch hinter den Patch Level packen. Somit hat man eine Aussagekräftige (logische) Versionsnummer für den Nutzer und eine für den Entwickler:
"major release"."minor release"."patch level"-"svn revision"

Gruß

[GregorS]

Hallo,

danke schonmal für Eure Antworten. Dass man eine Versionsnummer benutzen sollte, ist für mich längst keine Frage mehr. Ich kann mich noch an ziemlich nervige und sinnfreie Suchereien erinnern, die hin und wieder darin gipfelten, dass man sich zwischen "neueste Version" und "allerneueste Version" entscheiden musste. *g*

In der letzten Firma, in der ich gearbeitet habe, war die Versionsnummer allerdings nicht nur dazu da, sich Suchereien sparen zu können, sondern auch, um gewisse Stadien zu unterscheiden. Dort gings allerdings weit überwiegend um Druckerzeugnisse (Kataloge, Broschüren u. dgl.) und eine Major Release-Nummer wurde immer dann vom Projektleiter vergeben, wenn etwas wieder mal zum Kunden ging, der entweder eine neue Korrekturversion veranlasste oder die Freigabe erteilte. Ich habe aus der Tatsache, dass bei den Dingen, die zu den Kunden gingen, hinter dem Punkt eine Null steht, irgendwann gefolgert, dass die Nullen zum Kunden gehen. Die meisten Kontakter fanden das ganz witzig.

Was mir vielleicht auch noch helfen würde: Wenn Ihr mir sagt, wie die Programme heißen, die Ihr für die Versionskontrolle nutzt. Dann kann ich mich mal auf die Suche machen. Ich arbeite übrigens *ausschließlich* mit Kisten, die irgendein GNU/Linux fahren.

Grüße

Gregor

[Colttt]

da kann ich dir auch als nicht programmierer helfen.. der Quasi-standard ist Subversion(svn) eine Versionkontrolle sollte eigentlich auch in jeden gängigen repositiy zu finden sein und anleitungen gibt es auch wie sand am mehr

[suno]

SVN ist ein zentralisiertes SCM System. Ich wuerde eher zu einem verteilen SCM wie mercurial oder GIT raten http://sunoano.name/ws/public_xhtml/scm.html#why_git

Ein Quickstart ist hier http://sunoano.name/ws/public_xhtml/scm ... e_workflow zu finden.

[Meillo]

Deshalb wüsste ich gerne, wie Ihr das mit den Versionsnummern so handhabt.

Ich hatte das früher auch mal so gemacht: major.minor.patch.

Beim suckless-Projekt wird dagegen ganz einfach hochgezählt: 0.1, 0.2, ... 0.9, 1.0, 1.1 ... Ganz unabhängig davon welcher Art die Änderungen sind. Nur falls beim Release etwas schief geht (Datei fehlt, falscher Pfad, Sicherheitsproblem), dann gibt's mal ein x.y.1. Ich bin von dieser Art der Versionsnummernvergabe sehr begeistert, weil es so unkompliziert ist.

Überhaupt finde ich, dass die Versionsnummernvergabe in erster Linie praktisch sein muss.

[schorsch_76]

...
Überhaupt finde ich, dass die Versionsnummernvergabe in erster Linie praktisch sein muss.

Da hast du absolut recht Meillo! Aus diesen Grund bin ich zur svn Versionsnummer übergegangen

@GregorS: Wenn du alleine arbeitest ist es meine persönliche Meinung dass ein zentrales SCM (wie subversion)die beste Lösung ist. Hier hast du sämtliche Versionen gesammelt auf deiner Platte liegen. Auch ein Backup auf den Server ist ganz unkompliziert und du bist sicher dass du alles gesichert hast.

Persönlich hab ich die Hierarchie im Subversion so aufgebaut
Projekt1
- trunk tags branches
Projekt2
- trunk tags branches

Alles in einem Repository. Insbesondere nutze ich auch "svn:externals" um meine "Util Bibliothek" einfach und auf dem aktuellsten Stand ins Projekt einzubinden. Finde ich so einen Bug in dieser Bibliothek ist er beim nächsten update in allen Projekten gefixt.

Nach dem automatischen erstellen des svninfo.cpp Files war dann der nächste Entwicklungsschritt die Erstellung eines "mkrelease.sh" Scriptes. Dieses macht ein neues Release tag und erstellt diese Version automatisch. Damit habe ich dann weniger Probleme, da ich insbesondere unter Stress dazu neige einen Schritt zu vergessen.

trunk ist mein Hauptentwicklungszweig. tags enthält Release Versionen. Bsp. "Release_Projekt_xxx_r123". branches enthält Entwicklungszweige welche a) Irgendwann wieder in den Hauptentwicklungszweig zurückkommen oder b) "Angepasste Versionen" des Hauptprojektes sind und sicher nicht mehr in den Hauptentwicklungszweig zurück kommen.

Gruß

schorsch

[Meillo]

@GregorS: Wenn du alleine arbeitest ist es meine persönliche Meinung dass ein zentrales SCM (wie subversion)die beste Lösung ist.

Das sehe ich nicht so. Ich finde überhaupt keinen Grund mehr, weshalb ein zentrales VCS von Vorteil ist. Dezentrale VCS können das alles auch, sind aber deutlich einfach zu handhaben und viel flexibler.

[GregorS]

Schon wieder dankschee!

Das mit dem „praktisch“ und „einfach“ und nur simples Hochzählen (meillo) kann ich nachvollziehen. Das ist m.E. aber nur dazu gut, verschiedene Zustände voneinander zu trennen. Wenn man mehr Informationen in der Versionsnummer speichern möchte, ist major.minor.patch nach meiner Erfahrung unschlagbar. Zwar muss man halt immer wieder überlegen und beurteilen, welche Nummer man denn nun hochzählen soll … beim zuerst genannten Simpel-Prinzip muss man allerdings ggf. eine zusätzliche Doku zu Rate ziehen um (detailliertere) Infos zu bekommen, die man möchte.

@meillo: ist suckless eine Versionsverwaltungssoftware oder war das nur ein beliebiger Beispielname?

Ansonsten werde ich mir mal die Programme angucken, die schon genannt wurden. Subversion scheint mir tauglich. Wie ist das da mit dem Ein- und Auschecken, Hochladen der Änderungen? Diese Tätigkeiten sind das, was mich bisher davon abhält, meine simple Ordner-Kopiererei/-Umbenennerei aufzugeben.

Grüße

Gregor

[Meillo]

@meillo: ist suckless eine Versionsverwaltungssoftware oder war das nur ein beliebiger Beispielname?

http://suckless.org

Es ist vieles: Eine Community, ein Projekt oder viele Projekte, ein Philosophie, ... (nähere Infos: http://marmaro.de/docs/cccs/suckless/ )

[schorsch_76]

...
Ansonsten werde ich mir mal die Programme angucken, die schon genannt wurden. Subversion scheint mir tauglich. Wie ist das da mit dem Ein- und Auschecken, Hochladen der Änderungen? Diese Tätigkeiten sind das, was mich bisher davon abhält, meine simple Ordner-Kopiererei/-Umbenennerei aufzugeben.

Grüße

Gregor

Hi Gregor,

das ist ganz einfach:

Auschecken:

Code: Alles auswählen

svn co https://meinserver/svn/projekt

Einchecken

Code: Alles auswählen

cd MeinProjekt
svn ci 

Siehe hierzu das Subversionbuch [1]. Es gibt auch wirklich gute GUIs wie rapidsvn

Gruß

schorsch

[1] http://svnbook.red-bean.com/

[michaels]

Ich wollte mir immer mal RabbitVCS anschauen. Sieht wirklich gut aus, aber da ich mit NetBeans programmiere und dort die SVN Anbindung einfach super ist, war es nie notwendig (auf der Arbeit müssen wir ja Win benutzen und dann zusätzlich zu NetBeans halt noch TortoiseSVN).

[manes]

an dieser stelle möchte ich wieder mal auf meinen lieblingspodcast verweisen und speziell diese folge mit 162 minuten dauer empfehlen: http://chaosradio.ccc.de/cre130.html

Versionskontrollsysteme (DVCS) waren lange Zeit eine Domäne von Programmierern und Systemadministratoren, gewinnen aber in letzter Zeit auch zunehmend Bedeutung für andere kreative und kollaborative Tätigkeiten. Nachdem sich lange Zeit nur zentralistische Systeme wie CVS und Subversion auf dem Markt befanden, kommt jetzt eine neue Generation verteilter Systeme auf, die neue Voraussetzungen schaffen. Im Gespräch mit Tim Pritlove führt hukl in die Prinzipien der verteilten Versionskontrolle ein und bringt zahlreiche Beispiele, wie Entwicklung und Kollaboration durch neue Werkzeuge wie git, mercurial oder bazaar vorangebracht werden können.
Themen: Online und Offline arbeiten, die Vereinfachung von Forks, warum man Verteilte Versionskontrolle für den Friedensnobelpreis vorschlagen könnte, verlustfreie Vergangenheitserfassung, Interoperabilität von verteilen Versionskontrollsystemen, Integration mit alten Infrastrukturen, Social Coding und neue Kollaborationsstrukturen beim Programmieren, Verwendung von DVCS zur gemeinsamen Erarbeitung von Büchern, Nachträgliches Ändern der Versionsgeschichte, Migrationsstrategien.

[Wenn du alleine arbeitest ist es meine persönliche Meinung dass ein zentrales SCM (wie subversion)die beste Lösung ist.

wenn man sowieso mit versionskontrolle arbeiten will, kann man auch gleich den (nicht mehr ganz) neuesten heißen scheiß lernen und dezentrale versionierungssysteme erlernen, dann ist man auch vorbereitet auf kollaboratives arbeiten.

grüße
manes

[schorsch_76]

Na ich hatte ja gar keine Ahnung dass hier so viel "Feuerpotential" vorhanden ist bei etwas wie Versionsverwaltung

Da ich git nur oberflächlich kenne werde ich mir mal ein Testrepository aufsetzen und etwas spielen

Gruß

schorsch

[michaels]

Hm, wir arbeiten noch gar nicht sooo lange mit Subversion (vielleicht 1,5 Jahre). Damals hatte ich mir auch mal Mercurial angeschaut, aber irgendwie fand ich Subversion, mit dem zentralen Rep, einfacher/übersichtlicher/für ein Unternehmen besser.

Kann mir vielleicht mal jemand erklären, was an einem dezentralen VCS besser sein soll?

[Meillo]

Kann mir vielleicht mal jemand erklären, was an einem dezentralen VCS besser sein soll?

Man arbeitet ganz anders damit.

Um mal kurz was auszuprobieren clont man einfach das Repo und kann dann ganz unabhängig in dem zweiten (gleichen) Repo arbeiten. Das erste Repo bleibt unberührt solange man nicht merged.

Man kann mit DVCS ganz wunderbar offline arbeiten und auf einem beliebigen Rechner. Es muss kein Server laufen, denn jede Working Copy hat das komplette Repo dabei.

Wer will kann ja eines der Repos als zentrales Repo definieren, dann hat man das gleiche Setup wie bei zentralen VCS. Nur, dass man auch ohne zentrales Repo commiten, clonen, mergen kann.

[michaels]

Ok, danke für die Info. Ich denke, ich werde mich da nochmal etwas einlesen bzw. einfach mal ausprobieren.

[schorsch_76]

@Meillo: Zu SVN: Um fix was auszuprobieren mach ich auch ganz einfach eine Working Copy. Das Repo bekommt davon nichts mit. Ob nun ein "git clone" oder ein "svn co" mache ist egal. In beiden Fäälen gibt es einen Rechner von dem ich was hole und beide müssen laufen.

Du bekommst im DVCS oder im zentralisierten VCS auch einen conflict wenn du auf der gleichen Zeile etwas änderst und das eine in das andere commitest oder pusht. Conflikt gibt es immer. Da kann auch ein DVCS nicht zaubern.

Beispiel:

Import Orginalautor

Code: Alles auswählen

int main (int argc, char** argv)
{
printf("Hallo Welt!");
}

Ich zieh nen clone und ändere in meinem lokalen git Repo

Code: Alles auswählen

int main (int argc, char** argv)
{
printf("Hallo wunderbare Welt!");
}

Jetzt hat der orginale Autor das File so geändert:

Code: Alles auswählen

int main (int argc, char** argv)
{
printf("Hallo furchtbare Welt!");
}

Ich will jetzt meine "wunderbare Welt" Änderung hochschieben in das Repo des Orginalautors. Hier gibt es auf jeden Fall, egal mit welchen VCS einen Konflikt. Im zentraliserten VCS gibt es eben einen Master. Hier wird entschieden ob es eine "furchtbare Welt" oder eine "wunderbare Welt" ist die begrüsst wird. Wenn das ein Projekt sein soll, muss entschieden werden. Klar mit einem DVCS kann ich sagen: "Ich mach jetzt daraus mein eigenes Projekt und das ist das Hauptrepo". Mit subversion hab ich "nur eine working copy". Aber auch hier spricht nichts dagegen das in ein neues Repository zu importieren.

Für eine Firma hat der zentrale Ansatz einen Vorteil, da alle Entwickler ja an einem Projekt arbeiten und alle Änderungen aller Entwickler ja in das Projekt einfliessen sollen. Es ist immer klar was der Master ist.

Für eine OpenSource Community hat das DVCS einen Vorteil, falls der Maintainer des "geweihten" Repositories [1] aus irgendwelchen Gründen ausfällt.

Auch ich sehe die Vorteile die ein DVCS mit sich bringt, aber auch der zentrale Ansatz hat Vorteile. Dies hängt immer an den Umständen was erreicht werden soll. Ein (D)VCS ist immer Mittel zum Zweck und nicht der Hauptzweck eines Projektes

Gruß

schorsch
[1] http://book.git-scm.com/index.html

[Meillo]

@Meillo: Zu SVN: Um fix was auszuprobieren mach ich auch ganz einfach eine Working Copy. Das Repo bekommt davon nichts mit.

Aber mit dem DVCS kann ich in dem Testrepo einchecken, es nochmals clonen, mergen -- habe also ein vollwertiges Repo -- und kann es nacher doch verwerfen ... oder die ganze Testentwicklung in's Hauptrepo reinmergen.

Das mag mit zentralen VCS auch gehen, aber IMO nicht so flexibel.


Ich kann die Gründe für ein zentrales VCS nachvollziehen ... auch wenn ich der Meinung bin, dass sie zum größten Teil auf der zentralen Sichtweise/Workflow basieren.

Sei's drum.

[crazyed]

Ein von mir verwendetes Programm wird vom Initiator nicht weiterentwickelt. Der war dazu übergegangen fortlaufend zu numerieren. Das habe ich übernommen und bei allen Änderungen, die ich einfließen lassen, zähle ich einfach weiter.
Ich finde das Gewese um „minor“ und „major releases“ total überflüssig.

[armin]

Für eine Firma hat der zentrale Ansatz einen Vorteil, da alle Entwickler ja an einem Projekt arbeiten und alle Änderungen aller Entwickler ja in das Projekt einfliessen sollen. Es ist immer klar was der Master ist.

Wenn in einer firma z.b. git eingesetzt wird ist auch klar was Master ist -- und zwar der Master-Branch des Repositories von dem alle klonen und in das alle pushen.

[schorsch_76]

Hallo armin,

wie du in deiner Signatur schreibst, bist du ja Mitglied des Debian KDE Teams. Hab mich eben über git etwas eingelesen. Soweit ich weis setzt ja auch KDE git ein. Wie ist hier die "Infrastruktur" aufgebaut? Ähnlich wie beim Linuxkernel mit "Leutnant/Diktator"? [1] Was sind deiner Meinung nach die Stärken/Schwächen von git?

Was hat es mit dem "Developer private/public" Repository auf sich. Das hab ich noch nicht ganz verstanden. Dachte jeder hat eben ein Repository. Wiso braucht man dann ein public und ein private?

Gruß

schorsch

[1] http://progit.chunzi.me/de/ch5-3.html

[michaels]

Für eine Firma hat der zentrale Ansatz einen Vorteil, da alle Entwickler ja an einem Projekt arbeiten und alle Änderungen aller Entwickler ja in das Projekt einfliessen sollen. Es ist immer klar was der Master ist.

Wenn in einer firma z.b. git eingesetzt wird ist auch klar was Master ist -- und zwar der Master-Branch des Repositories von dem alle klonen und in das alle pushen.

Und wo ist dann bei der Vorgehensweise noch ein Vorteil gegenüber zentraler VCS?
So wie ich das sehe, eigentlich nur, das der Entwickler noch eine eigene Kopie des Reps hat, indem er dann wieder commiten kann usw und es dann irgendwann zum Master commitet? Hab ich das so richtig verstanden?

Gibt es für Git gute Oberflächen (wie TortoiseSVN)?
Hat vielleicht schon jemand mit Git und NetBeans gearbeitet?
Wird für jeden ersichtlich, in welches Rep man gerade commitet (also lokale Arbeits-Rep oder Master-Rep)? (per Kommandozeile wohl klar, aber auch mit einer GUI)

Wir arbeiten eigentlich ziemlich "unsichtbar" mit SVN. Die IDE (NetBeans) markiert alle noch nicht commiteten Änderungen in einer Datei (veränderte Zeilen, neue Zeilen, gelöschte Zeilen) (kann man auch abstellen). Die geänderten Dateien werden auch im Verzeichnisbaum farblich hervorgehoben. Per Rechtsklick auf Dateien (oder Verzeichnisse) kann man die dann einfach commiten. Alles ziemlich einfach und sehr schön in die Oberfläche integriert.
(einige unserer Entwickler haben eine tiefe Abneigung gegen Kommandozeilen , und einige haben das vorhandene SVN System auch noch nicht verstanden und bei einem dezentralen VCS stelle ich es mir noch schlimmer vor).

[hupfdule]

Man kann mit DVCS ganz wunderbar offline arbeiten und auf einem beliebigen Rechner. Es muss kein Server laufen, denn jede Working Copy hat das komplette Repo dabei.

Das war für mich der Grund git zu benutzen. Mir fehlte die Möglichkeit auf verschiedenen Rechnern am selben Projekt zu arbeiten, mit und ohne Netzzugang und trotzdem committen, reverten, etc. zu können. Dennoch war mir auch das zentrale Repository wichtig, damit ich immer ein Repository habe, das als Master definiert ist. Das geht deutlich problemloser als ich es mir vorgestellt hatte. Ich hätte mich schon viel früher damit auseinander setzen sollen. Ich habe bis jetzt nur Vorteile gegenüber zentralen VCS gefunden. Ein bisschen schwierig war die Auswahl, welches DVCS ich nehmen sollte. Aber bis jetzt bin ich mit meiner Wahl zufrieden.