Mercurial Struktur aufbauen (Benötige Hilfe)

[RWarnecke]

Hallo zusammen,

ich möchte meine ganze Softwareentwicklung neu aufbauen mit Mercurial. Dazu benötige ich ein paar Tipps von euch, wie ich meine derzeitige Struktur in Mercurial übernehmen kann. Ich habe einen Windows 2012 Server und zwei Mac's. Auf beiden Mac's arbeite ich in einer Paralells VM mit Windows 8.1. Auf Mac 1 arbeite ich direkt mit der VM auf dem Windows 2012 Server. Beim MacBook Pro kopiere ich vor jeder Benutzung die Dateien vom Windows 2012 Server auf's MacBook Pro und wenn ich wieder zurück bin, dann gibt es wieder einen Sync auf den Windows Server 2012. Mittlerweile wird das alles etwas umständlich, zumal ich für ein Projekt auch noch drei Versionen pflegen muss. Jetzt zu meinen Fragen :

1. Wo muss ich Mercurial installieren, so dass ich auf meinem Windows Server 2012 immer eine aktuelle Kopie habe ?
2. Wie funktioniert dann das synchronisieren zwischen den einzelnen Rechnern ?
3. Kann ich das Repo-Verzeichnis von dem Windows 2012 Server ganz normal mit FreeFileSync zum Beispiel sichern oder benötige ich hier bestimmte Befehle ?
4. Wie händelt Ihr die Sicherung von Mercurial Repo-Verzeichnissen und der entsprechenden Datenbank dahinter?

[Stevie]

Sowas wie ein Mercurial Tutorial hast du schon durchgelesen oder?

[RWarnecke]

Ja, ich habe das ganze ja schon auf einem Testsystem ausprobiert. Mir geht es hauptsächlich dabei, wie das mit dem Windows Server und den beiden Mac's hinbekomme. Auf einem einzelnen Rechner habe ich eine funktionierende Installation hinbekommen.

[Stevie]

Naja, du legst ein Repository auf deinem Server an und syncst dann ganz einfach über den Hg client deiner Wahl auf deine Macs.
Ebenso machst du ein Backup, du clonest dein Repo einfach. Oder einfaches Datei backup.

Ich weiß nicht, von welchem VCS du kommst, ich vermute mal, nicht von einem dezentralen. Bei einem solchen VCS braucht man eigtl weniger irgendwelche Backups, weil jeder, der damit arbeitet quasi ein Backup hat. Dein Server raucht ab? Kein Ding, setz ihn neu auf und push danach von einem deiner Macs das Repo wieder drauf. Fertich.

[RWarnecke]

Ich habe mal eine Zeitlang mit SVN gearbeitet. Bin dann aber wieder auf ein selbstverwalteten Dateisystem umgestiegen. Habe aber nun die Nachteile, wegen der Verwaltung von mehreren Versionen festgestellt.

Das heißt, dass ich auf jedem Rechner jeweils eine Kopie meiner Projekte liegen habe. Das ist eigentlich nicht ganz das was ich will. Ich möchte nur eine Kopie auf dem Server haben und eine auf dem MacBook Pro. Aber wenn ich das ganze richtig verstanden habe, geht das so nicht mit Mercurial.

Eine andere Frage, kann ich auf dem Server einen Automatismus aktivieren, sobald ich einen Commit auf meinem Client mache, dass dann die Änderungen automatisch auf den Server übertragen werden ?

[Stevie]

Zitat:

Zitat von RWarnecke (Beitrag 1261990)

Ich habe mal eine Zeitlang mit SVN gearbeitet. Bin dann aber wieder auf ein selbstverwalteten Dateisystem umgestiegen. Habe aber nun die Nachteile, wegen der Verwaltung von mehreren Versionen festgestellt.

Das heißt, dass ich auf jedem Rechner jeweils eine Kopie meiner Projekte liegen habe. Das ist eigentlich nicht ganz das was ich will. Ich möchte nur eine Kopie auf dem Server haben und eine auf dem MacBook Pro. Aber wenn ich das ganze richtig verstanden habe, geht das so nicht mit Mercurial.

Eine andere Frage, kann ich auf dem Server einen Automatismus aktivieren, sobald ich einen Commit auf meinem Client mache, dass dann die Änderungen automatisch auf den Server übertragen werden ?

Ich glaube, du hast den Gedanken eines verteilten Versionsverwaltungssystems noch nicht verstanden.
Da du schon mit SVN gearbeitest hast, solltest du eventuell diesen Artikel von Joel Spolsky dazu lesen. Ja, der ist lang, lohnt aber. Ansonsten reden wir hier weiter aneinander vorbei.

[jfheins]

Zitat:

Zitat von RWarnecke (Beitrag 1261990)

Das heißt, dass ich auf jedem Rechner jeweils eine Kopie meiner Projekte liegen habe. Das ist eigentlich nicht ganz das was ich will. Ich möchte nur eine Kopie auf dem Server haben und eine auf dem MacBook Pro. Aber wenn ich das ganze richtig verstanden habe, geht das so nicht mit Mercurial.

Warum möchtest du das nicht? Speicherplatz ist bei 35 cent/GB SSD hoffentlich kein Argument mehr ;-)
Ich habe zufällig heute mein (git) Repo genauer angeguckt. Das Arbeitsverzeichnis hatte 150MB oder so, das kam von den ganzen Kompilaten. Der .git Ordner (also die gesamte Geschichte von den QUelltexten inkl. binären Bibliotheken) lag irgendwo bei 20 MB. Da ist ja auch automatisch alles komprimiert.

Eine zusätzliche Kopie kann eigentlich nicht schaden, im Gegenteil es ist eine zusätzliche Sicherheit. Syncronisierungsaufwand fällt im Grunde weg, und die Gefahr "versehentlich" einen neuen Stand mit einem alten zu Überschreiben ist quasi nicht existent.

Also eigentlich willst du es, du weiß es vielleicht noch nicht :stupid:

Zitat:

Eine andere Frage, kann ich auf dem Server einen Automatismus aktivieren, sobald ich einen Commit auf meinem Client mache, dass dann die Änderungen automatisch auf den Server übertragen werden ?

Ich bin mir ziemlich sicher, dass das geht. Allerdings geht der Automatismus schon in Richtung "erweitere Funktionalität". Ich empfehle dir SourceTree, das ist für den privaten Gebrauch kostenlos und in meinen Augen die beste GUI für git bzw. Mercurial. Ich benutze circa 97% SourceTree, 2% Kommandozeile und 1% Tortoise. (Letzteres ist praktisch, wegen den Shell-Icons)

SourceTree gibt es übrigens für Windows und Mac ;-)

[Stevie]

Zitat:

Zitat von jfheins (Beitrag 1261994)

Ich empfehle dir SourceTree, das ist für den privaten Gebrauch kostenlos und in meinen Augen die beste GUI für git bzw. Mercurial.

Da stimme ich dir zu. Nur 3 kleine Sachen stören mich etwas. Der integrierte Differ und die Dateilisten können manchmal etwas träge sein. Gerade, wenn man mehrere Dateien markiert um sie zu stagen (weil er die dann alle im Differ anzeigt)
Und das andere ist das fehlende Autostash (lokale Änderungen, ich will Pullen, geht nicht). Klar, kann ich selbst stashen oder commiten. Will ich aber manchmal nicht und sind zusätzliche Arbeitsschritte, die ich machen muss. Außerdem das fehlende automatische "dann pull doch!" wenn ich pushen will und ich nicht auf dem head bin.

Zu der eigentlichen Frage, in Sourcetree gibt es die Option "Push to default/origin remote when committing", die man anhaken kann.

[Mavarik]

Zitat:

Zitat von RWarnecke (Beitrag 1261990)

Eine andere Frage, kann ich auf dem Server einen Automatismus aktivieren, sobald ich einen Commit auf meinem Client mache, dass dann die Änderungen automatisch auf den Server übertragen werden ?

Damit habe ich mich auch schwer getan...

Es gibt keinen klassischen Server mehr. Jeder Rechner hat alles und ein Commit geht immer erst lokal.
Auf Wunsch, kannst Du dann Pushen. Das geht aber ggf. auch an verschiedene Ziele.

Mavarik

[RWarnecke]

Zitat:

Zitat von Mavarik (Beitrag 1262038)

Damit habe ich mich auch schwer getan...

Es gibt keinen klassischen Server mehr. Jeder Rechner hat alles und ein Commit geht immer erst lokal.
Auf Wunsch, kannst Du dann Pushen. Das geht aber ggf. auch an verschiedene Ziele.

Ja, damit tue ich mich noch ein bisschen schwer. Vom Grundprinzip habe ich es verstanden, aber ich muss das ganze jetzt erstmal in meinem Arbeitsablauf einbauen und das fällt mir etwas schwer.

[Uwe Raabe]

Gibt es eventuell Interessenten für einen diesbezüglichen Vortrag bei den Delphi-Tagen? Ich könnte da vielleicht ein paar Worte drüber verlieren. Vielleicht wäre aber auch ein etwas ausführlicherer Workshop interessant?

[mkinzler]

Es werden wohl noch Referenten gesucht
http://www.delphipraxis.net/180595-d...ml#post1260979

:wink:

[Der schöne Günther]

Zitat:

Zitat von Uwe Raabe (Beitrag 1262042)

Gibt es eventuell Interessenten für einen diesbezüglichen Vortrag bei den Delphi-Tagen? Ich könnte da vielleicht ein paar Worte drüber verlieren. Vielleicht wäre aber auch ein etwas ausführlicherer Workshop interessant?

Großer Gott, ja!

[Uwe Raabe]

Zitat:

Zitat von mkinzler (Beitrag 1262043)

Es werden wohl noch Referenten gesucht
http://www.delphipraxis.net/180595-d...ml#post1260979

:wink:

Deswegen frage ich ja. Wenn aber nur wenig Interesse besteht, macht das wenig Sinn.

[roter Kasten]
Günther scheint schon mal interessiert zu sein :-D

[mkinzler]

Zitat:

Günther scheint schon mal interessiert zu sein

Rolf sicher auch ;)

[RWarnecke]

Zitat:

Zitat von mkinzler (Beitrag 1262046)

Zitat:

Günther scheint schon mal interessiert zu sein

Rolf sicher auch ;)

Da hat Markus garnicht so unrecht. Ich bin auf jedenfall interessiert.

[Phoenix]

Zitat:

Zitat von RWarnecke (Beitrag 1261974)

ich möchte meine ganze Softwareentwicklung neu aufbauen mit Mercurial.

Okay, Du hast Dich also offensichtlich für Hg entschieden.

Darf man mal ketzerisch fragen, warum Du bewusst auf ein Nischenprodukt setzt?
Die Situation von vor 2-3 Jahren, wo Mercurial unter Windows noch das deutlich bessere Tooling als Git hatte, ist heute grundlegend anders.

Es gibt deutlich mehr Support für Git, es gibt deutlich mehr Tutorials für Git, es gibt deutlich mehr und besseres Tooling für Git. Es gibt vor allem auch deutlich mehr und bessere Repository-Verwaltungstools für Git als für Hg.

Was hat Dich dennoch, entgegen dieser überwältigenden (auch wirtschaftlichen) Vorteile von Git, dazu bewegt auf Mercurial zu setzen?

Ich frage da rein aus Interesse, weil ich das gerne nachvollziehen würde.

[RWarnecke]

Zitat:

Zitat von Phoenix (Beitrag 1262050)

Okay, Du hast Dich also offensichtlich für Hg entschieden.

Darf man mal ketzerisch fragen, warum Du bewusst auf ein Nischenprodukt setzt?
Die Situation von vor 2-3 Jahren, wo Mercurial unter Windows noch das deutlich bessere Tooling als Git hatte, ist heute grundlegend anders.

Es gibt deutlich mehr Support für Git, es gibt deutlich mehr Tutorials für Git, es gibt deutlich mehr und besseres Tooling für Git. Es gibt vor allem auch deutlich mehr und bessere Repository-Verwaltungstools für Git als für Hg.

Was hat Dich dennoch, entgegen dieser überwältigenden (auch wirtschaftlichen) Vorteile von Git, dazu bewegt auf Mercurial zu setzen?

Ich frage da rein aus Interesse, weil ich das gerne nachvollziehen würde.

Mercurial hat mir ein Freund empfohlen, da er gesehen hat, dass ich das ganze mit SVN machen wollte. Darauf hin habe ich mir SourceTree und Mercurial heruntergeladen und ausprobiert und fand es recht übersichtlich. Und durch die Übersichtlichkeit habe ich mich dann dazu entschieden eine entsprechende Umgebung für mich aufzubauen, wie in meinem ersten Beitrag beschrieben.

Ich habe vor ein paar Jahren mal SVN ausprobiert und bin damit auf die Schnauze gefallen. Zum Schluß war so ein heilloses durcheinander, dass ich ganze 4 Tage gebraucht habe meinen Quelltext wieder herzustellen. Deshalb finde ich die Übersichtlichkeit von SourceTree in Verbindung mit Mercurial sehr gut. Eine richtige Entscheidung ist noch nicht ganz gefallen, da ich ja noch Probleme habe mit der Umsetzung und auch mit der Arbeitsweise. Aber was ich nachher einsetze, steht noch nicht hunderprozentig fest.

Wo liegen die Unterschiede zwischen Mercurial und Git ? Ich habe mal versucht einen Git Client unter Windows zu installieren um dann ein Open-Source Repository zu ziehen, was leider fehlschlug. Bei SourceTree in Verbindung mit Mercurial fand ich das Anlegen eines Repositories sehr einfach. Einfacher als unter SVN zum Beispiel.

[mkinzler]

Zitat:

Ich habe mal versucht einen Git Client unter Windows zu installieren um dann ein Open-Source Repository zu ziehen, was leider fehlschlug.

Mit was für einen Client? Mit TortoiseGit ist das eigentlich kein Problem: Url der .git-Datei in Zwischenablage und dann im Kontextmenü des übergeordneten Ordners Git-Clone ausführen.

[Uwe Raabe]

Zitat:

Zitat von Phoenix (Beitrag 1262050)

Darf man mal ketzerisch fragen, warum Du bewusst auf ein Nischenprodukt setzt?

Also wegen Nischenprodukt und so - wir sind hier schließlich in der Delphi-Praxis, oder?

[mkinzler]

Zitat:

Zitat von Uwe Raabe (Beitrag 1262057)

Zitat:

Zitat von Phoenix (Beitrag 1262050)

Darf man mal ketzerisch fragen, warum Du bewusst auf ein Nischenprodukt setzt?

Also wegen Nischenprodukt und so - wir sind hier schließlich in der Delphi-Praxis, oder?

Er verwendet ja auch kein Delphi :mrgreen:

[Namenloser]

Mercurial ist besser wegen dem "history is sacred"-Prinzip. Bei Git läufst du ständig Gefahr, alle deine Daten zu verlieren, weil du ein Rebase falsch durchgeführt hast o.ä.. Das ist kein Witz.

Ok, bisher konnte ich zwar alles wieder retten, aber trotzdem ist es Glückssache. Wenn der GC schon zugeschlagen hat, hast du gelitten.

Ich hab mich inzwischen zwar auch gezwungenermaßen an git halbwegs gewöhnt und mache in der Regel keine Fehler mehr, aber bei hg hab ich gerade am Anfang deutlich weniger geflucht. Und mit hg kann ich alles machen, was ich mit git auch kann (ggf. mit Plugins), also warum sollte man sich da mit git in den Fuß schießen, wenn man es auch angenehmer haben kann?

[Mavarik]

Zitat:

Zitat von Uwe Raabe (Beitrag 1262057)

Also wegen Nischenprodukt und so - wir sind hier schließlich in der Delphi-Praxis, oder?

Autsch...

Mich hat TortoiseHg einfach von der Oberfläche überzeug... Die Darstellung der einzelnen Braches usw...

Ich muss wenn ich das Büro wechsele nicht jedes mal alles zusammen zippen sondern Pushe einfach auf einen USB Stick fertig.

Außerdem wurde mir das hier in der DP "aufgezwungen" als ich mal in SVN einsteigen wollte...

Danke nochmal dafür...

Mavarik

[samso]

Also mal "aus der Praxis für die Praxis".

Zu 1) Du musst auf allen Arbeitsplatzrechnern ein Mercurial haben
zu 2)
Schritt 1: Commit auf Arbeitsplatz 1 (=> neuer Eintrag in die lokale "Datenbank")
Schritt 2: Push auf Arbeitsplatz 1 zu Deinem Server (Version wird zum Server übertragen)
(TortoiseHg kann diese beiden Schritte auf eine Knopfdruck ausführen lassen)
Schritt 3: Pull auf Arbeitsplatz 2 (Version wird vom Server in die lokale "Datenbank" übertragen)
Schritt 4: Update auf Arbeitsplatz 2 (*.pas/*.dfm/*.dpr... auf dem Arbeitsplatz werden aktualisiert)
(TortoiseHg kann auch diese beiden Schritte auf eine Knopfdruck ausführen lassen)
Bei mir ist das also pro Arbeitsplatz ein Knopfdruck.
zu 3) Das Verzeichnis (".hg") in dem die Versionsverwaltungsdaten liegen, kann mit jedem beliebige Kopierprogramm kopiert werden.
zu 4) Ich mache nie Sicherungen, weil auf allen meinen Arbeitsplätzen quasi eine Sicherung liegt. Da ich alle Arbeitsplätze mindestens einmal am Tag synchronisiere, ist die Sicherung höchstens ein Tag alt.

[Phoenix]

Disclaimer vorneweg: Ich möchte hier niemanden bekehren oder so. Ich persönlich finde halt, das durch den stärkeren Fokus der gesamten Entwickler-Community auf Git hier einfach deutlich mehr Potential ist als bei Hg, das früher deutlich die Nase vorne hatte (zumindest auf Windows).

Zitat:

Zitat von RWarnecke (Beitrag 1262053)

Mercurial hat mir ein Freund empfohlen, da er gesehen hat, dass ich das ganze mit SVN machen wollte. Darauf hin habe ich mir SourceTree und Mercurial heruntergeladen und ausprobiert und fand es recht übersichtlich. Und durch die Übersichtlichkeit habe ich mich dann dazu entschieden eine entsprechende Umgebung für mich aufzubauen, wie in meinem ersten Beitrag beschrieben.

Ah, Sourcetree :)
Dann hast Du grundsätzlich mal kein Problem, denn SourceTree kann mindestens genauso gut mit Git umgehen wie mit Mercurial.

Zitat:

Zitat von RWarnecke (Beitrag 1262053)

Ich habe vor ein paar Jahren mal SVN ausprobiert und bin damit auf die Schnauze gefallen. Zum Schluß war so ein heilloses durcheinander, dass ich ganze 4 Tage gebraucht habe meinen Quelltext wieder herzustellen.

Wow. :shock: Was ist da denn passiert? Also grundsätzlich ist SVN auch recht cool.

Zitat:

Zitat von RWarnecke (Beitrag 1262053)

Wo liegen die Unterschiede zwischen Mercurial und Git ? Ich habe mal versucht einen Git Client unter Windows zu installieren um dann ein Open-Source Repository zu ziehen, was leider fehlschlug. Bei SourceTree in Verbindung mit Mercurial fand ich das Anlegen eines Repositories sehr einfach. Einfacher als unter SVN zum Beispiel.

Git ist etwas Feature-reicher als Mercurial. Hier muss man sich immer mit Plugins im Repo rumschlagen wenn man mal was ausser der Reihe machen will, was mit Git gleich out of the box geht. Wobei der Standard-Funktionsumfang von beiden reicht aber eigentlich in 99,999% aller Fälle die man im normalen tagtäglichen Umfang braucht aus. Ausser einer Ausnahme: Versuche mal bei Mercurial, einen named branch zu löschen. Viel Spass beim history strippen...
Hier gibt es einen (imho) sehr guten Artikel zu den Unterschieden: http://www.rockstarprogrammer.org/po...urial-and-git/

Git für Windows gibts hier: http://git-scm.com/download/win Und ich installiere das ganz normal mit den Default settings, so dass Git (und nur git) im Path sitzt.

Ein Entferntes Repo dann lokal auszuchecken ist dann so einfach wie:

Code:

git clone https://github.com/gingters/EKON16_JavaScript.git

Wenn Du das dann - egal ob Git oder Hg - wirklich professionell einsetzen willst, dann wird man - obwohl beides ja per se verteilte Systeme sind - trotzdem irgendwo ein Repository anlegen und als 'master' deklarieren, zu dem alle ihre Changes pushen werden und von dem alle die anderen Changes pollen werden. Ggf. über andere zwischenrepos oder auch nicht, aber es sollte grundsätzlich irgendeinen Punkt im System geben, der einem Backup unterliegt und von dem z.B. das CI-System aus alle Changes automatisch auscheckt, baut, Unit- und Integration Tests laufen lässt und aus dem man dann am Ende die Releases baut.

Du willst dafür aber nicht viele Repositories von Hand anlegen und ggf. dort Rechte verwalten (das ist dann auch der Punkt wo jedes System irgendwann eklig wird, sei es SVN, Git oder auch Hg). Für Git gibt es hier z.B. das freie GitLab (https://gitlab.com), das eine Ruby-Weboberfläche bietet um Zentral Repositories und Rechte zu verwalten (inkl. AD-Integration etc.). Für Mercurial kenne ich jetzt nur HgLab (http://hglabhq.com/) das aber kostenpflichtig ist. Als weitere Kostenpflichtige Lösung bietet sich z.B. Stash von Atlassian an, das kann sogar Hg und Git gemeinsam.

[Valle]

Zitat:

Zitat von RWarnecke (Beitrag 1262053)

Wo liegen die Unterschiede zwischen Mercurial und Git ?

http://thkoch2001.github.io/whygitisbetter/#hg

Ist ganz interessant und fasst es zusammen.

[jfheins]

Zitat:

Zitat von Phoenix (Beitrag 1262097)

Als weitere Kostenpflichtige Lösung bietet sich z.B. Stash von Atlassian an, das kann sogar Hg und Git gemeinsam.

Naja, nicht laut aktueller Webseite: https://confluence.atlassian.com/dis...ontrolsystems?

Zitat:

Q: Does Stash support Mercurial (Hg)? What about other version control systems?

A: Currently Stash does not support Mercurial. We will be gauging demand for Mercurial support as we move forward -

Oder meintest du FogCreek Kiln?

Zu git kann ich noch festhalten, dass es wohl eine schlachte Idee ist per Samba (Windows Dateifreigabe) auf einem git Repo zu operieren.
Das Repo sollte immer auf einer lokalen SATA-Destplatte liegen (idealerweise natürlich eine SSD). Alle Daten, die über LAN oder WLAN gehen, sollten per git push/pull verschickt werden.

[mkinzler]

Zitat:

Zitat von Uwe Raabe (Beitrag 1262057)

Zitat:

Zitat von Phoenix (Beitrag 1262050)

Darf man mal ketzerisch fragen, warum Du bewusst auf ein Nischenprodukt setzt?

Also wegen Nischenprodukt und so - wir sind hier schließlich in der Delphi-Praxis, oder?

Eine richtige Nische wäre wohl Plastic

[Phoenix]

Zitat:

Zitat von jfheins (Beitrag 1262101)

A: Currently Stash does not support Mercurial. We will be gauging demand for Mercurial support as we move forward -

Oder meintest du FogCreek Kiln?
Äh ja. Kiln. Sorry. Ich dachte Atlassian würen die Hg Fahne noch so hoch hängen. Deren Bitbucket kann Hg, und ich dachte Stash wäre das Inhouse-Bitbucket. Hab mich da wohl vertan.

Zitat:

Zitat von jfheins (Beitrag 1262101)

Zu git kann ich noch festhalten, dass es wohl eine schlachte Idee ist per Samba (Windows Dateifreigabe) auf einem git Repo zu operieren.
Das Repo sollte immer auf einer lokalen SATA-Destplatte liegen (idealerweise natürlich eine SSD). Alle Daten, die über LAN oder WLAN gehen, sollten per git push/pull verschickt werden.

Gilt genauso für Hg. Deswegen sind es ja verteilte Systeme. Die sollten immer lokal liegen und im Idealfall über ihr eigenes Protokoll (auch nicht unbedingt über HTTP) Daten austauschen. Http ist hier nochmal deutlich langsamer.

[RWarnecke]

So, nach einigen hin und her, habe ich mich dafür entschieden Git mit Sourcetree zu verwenden. Ich habe den Server auch schon soweit installiert und konfiguriert. Das Commit, der Pull und das Push funktionieren auch. Ich bin noch etwas unschlüssig, wie ich jetzt die Repositories für meine Projekte aufbauen soll.

Meine Frage ist, trennt Ihr die Repositories in die einzelnen Plattformen oder habt Ihr immer nur ein Repository für das ganze Projekt (alle Platformen) ?

Ich habe ein Projekt, wo ich über zwei Verzeichnisse zwei unterschiedliche Versionen pflege. Würdet Ihr hier aus ein Repository oder zwei machen ?

[himitsu]

Zitat:

Zitat von RWarnecke (Beitrag 1263713)

Meine Frage ist, trennt Ihr die Repositories in die einzelnen Plattformen oder habt Ihr immer nur ein Repository für das ganze Projekt (alle Platformen) ?

Gemeinsame Codeteile in ein eigenes weiteres Repository?

Wenn die gemeinsamen Codes einen großen Anteil haben (was vermutlich so sein sollte), dann macht es sich besser, alles in Eines zu machen.

Zitat:

Zitat von RWarnecke (Beitrag 1263713)

Ich habe ein Projekt, wo ich über zwei Verzeichnisse zwei unterschiedliche Versionen pflege. Würdet Ihr hier aus ein Repository oder zwei machen ?

Wenn die Projekte stark getrennt sind, dann Beides in jeweils was Eigenes und dann hast du besseren Überblick welche Codes von einem Projekt in das Andere übergegen.



Also das ist jetzt einfach so meine naive Meinung/Vorstellung.

[Sherlock]

Für unterschiedliche Versionen gibts doch Branches. Wozu dann komplett getrennte Repositories führen?

Sherlock

[RWarnecke]

Zitat:

Zitat von Sherlock (Beitrag 1263759)

Für unterschiedliche Versionen gibts doch Branches. Wozu dann komplett getrennte Repositories führen?

Das mit den Branches habe ich gelesen, dass man die für unterschiedliche Versionen nutzt. Wie würdest Du ein Repository erstellen, wo Du zwei unterschiedliche Versionen in zwei unterschiedlichen Verzeichnissen gepflegt hast ?

[Uwe Raabe]

Zitat:

Zitat von Sherlock (Beitrag 1263759)

Für unterschiedliche Versionen gibts doch Branches. Wozu dann komplett getrennte Repositories führen?

Das sind halt zwei unterschiedliche Verfahren: Versioning by Branching und Versioning by Cloning. Ich persönlich bevorzuge auch das Versioning by Cloning. Es hält die Repositories übersichtlicher und reduziert den Merging-Aufwand erheblich. Man hat dann halt noch eine übergeordnete Stuktur der voneinander abhängenden Repositories, die man im Auge behalten muss. Durch diese Trennung wird aber m.E. die Übersichtlichkeit des Gesamtsystem deutlich erhöht.

Es mag allerdings durchaus Szenarien geben, wo die andere Vorgehensweise besser geeignet ist. In vielen Fällen ist es auch einfach nur eine Geschmacksfrage.

[Sherlock]

Zitat:

Zitat von RWarnecke (Beitrag 1263761)

Zitat:

Zitat von Sherlock (Beitrag 1263759)

Für unterschiedliche Versionen gibts doch Branches. Wozu dann komplett getrennte Repositories führen?

Das mit den Branches habe ich gelesen, dass man die für unterschiedliche Versionen nutzt. Wie würdest Du ein Repository erstellen, wo Du zwei unterschiedliche Versionen in zwei unterschiedlichen Verzeichnissen gepflegt hast ?

Du musst Dir vor Augen halten, das eine Revision eines Repositories einen kompletten Dateibestand (zur Entwicklung nötige Dateien freilich) wiederspiegelt (samt den dorthin führenden Changesets). Eigentlich kennen sich zwei verschiedene Versionsbranches nicht. Erst durch Merges (die ja nötig sind, um Änderungen, die beide Versionen betreffen sollen, zu propagieren) gibt es eine Verbindung zwischen den Branches (abgesehen vom gemeinsamen Elternteil). Die unterschiedlich benannten Ordner sind dadurch nicht nötig, sogar kontraproduktiv. Man sollte sich bei "modernen" Versionsverwaltungen vom Konzept der "Versionierung durch Ordner" wirklich verabschieden. ;)

Die Branches koexistieren dann ganz friedlich, bis sie eben abgeschlossen werden und/oder zu neuen Branches führen (siehe den kleinen Auszug aus dem Baum eines Projekts meiner Firma - jede Farbe ist ein benannter Branch).

Sherlock

[RWarnecke]

Hallo Uwe, Hallo Sherlock,

danke erstmal für eure Antworten. Ich bin ja am Aufbau der Repositories für meine Projekte. Wenn ich das ganze jetzt richtig verstanden habe, wäre es sinnvoll jede gepflegte Version, die sich gerade in einem separaten Verzeichnis befindet, in ein einzelnes Repository zu stecken. Was ist eure Meinung bezüglich den Platformen ? Jede Platform ein Repository oder alle Platformen in ein Repository ?

[himitsu]

Nunja, da es ja aktuell schon 2 getrennte Programme/Versionen sind und wenn diese sich schon "stark" unterscheiden, dann kann einem schon die Idee kommen, das auch weiterhin als getrennte Programme anzusehen und demnach auch einzeln zu versionieren.

Wenn man Beides nun getrennt in ein Repository aufnimmt, dann bleiben diese Versionen dennoch "physisch" getrennt.


Was aber auch ginge -> Beides wieder zusammenzumergen.
* für alte Version ein Repository erstellen
* davon/darin einen Branch für die neue Verion erstellen (erstmal ohne Dateien, sondern nur die alte Version branchen)
* die Dateien des neuen Branches durch die Dateien der neueren Version ersetzen und die Ändernungen einchecken
Dann hat man doch erstmal wieder 2 Branches, welche ihre aktuellen Änderungen kennen. Man kann ab da nach herzens Lust hin- und hermergen und vorallem sieht man die Unterschiede auch richtig.

[Uwe Raabe]

Einen bestehenden Multi-Versionsstand zu übernehmen kann schon mal schwierig werden, wenn man die gemeinsame Historie nicht so einfach übernehmen kann. Insofern setzt eine Aussage zur Übernahme natürlich eine gründliche Analyse des bestehenden Umfelds unter Berücksichtigung der bisherigen Versionsverwaltung voraus. Ich könnte mich da jetzt so nicht festlegen.

Im laufenden Betrieb gehe ich (mit Mercurial) bei neuen Versionen immer so vor, daß ich irgendwann einen Clone des Repos für die neue Version anlege und fortan in (mindestens) zwei Repos arbeite. Die neue Version bekommt deshalb schon ein neues Repo, damit die gesamte Build-Struktur für die alte Version unverändert weiterarbeiten kann (schließlich ist es zu diesem Zeitpunkt noch eine Weile hin bis zum Release der neuen Version). Kommt dann die neue Version raus laufen beide Systeme parallel weiter bis die alte Version eingestellt wird.

Die Repos sind durch ihre gemeinsame Versionshistorie ja immer noch verbunden und es lassen sich auch weiterhin noch Bugfixes aus der alten Version in die neue mergen, solange nicht massive Strukturänderungen dies erschweren. Insofern verliere ich durch die getrennten Repos keine Funktionalität, die ich mit Branches innerhalb eines Repos hätte. Es erhöht meiner Meinung aber deutlich die Übersicht. Sherlock's Grafik empfinde ich in diesem Zusammenhang auch eher als abschreckendes Beispiel (@Sherlock: no offence!). In meinen Repos entstehen solche Verzweigungen fast ausschließlich durch Implementierung von Features, das Beheben von Bugs oder das Tagging des Build-Systems - und sie werden immer lokal aufgelöst. Auf den zentralen Server-Repos gibt es keine multiple heads.

[himitsu]

Zitat:

Zitat von Uwe Raabe (Beitrag 1263794)

Sherlock's Grafik empfinde ich in diesem Zusammenhang auch eher als abschreckendes Beispiel (@Sherlock: no offence!).

Wenn du nicht zu Tode erschrecken willst, dann schau dir das besser nicht beim Firefox an (mit den Features und den großen Clonen, wird as ein hübscher "Baum")

[Stevie]

Zitat:

Zitat von Uwe Raabe (Beitrag 1263794)

Im laufenden Betrieb gehe ich (mit Mercurial) bei neuen Versionen immer so vor, daß ich irgendwann einen Clone des Repos für die neue Version anlege und fortan in (mindestens) zwei Repos arbeite. Die neue Version bekommt deshalb schon ein neues Repo, damit die gesamte Build-Struktur für die alte Version unverändert weiterarbeiten kann (schließlich ist es zu diesem Zeitpunkt noch eine Weile hin bis zum Release der neuen Version). Kommt dann die neue Version raus laufen beide Systeme parallel weiter bis die alte Version eingestellt wird.

Die Repos sind durch ihre gemeinsame Versionshistorie ja immer noch verbunden und es lassen sich auch weiterhin noch Bugfixes aus der alten Version in die neue mergen, solange nicht massive Strukturänderungen dies erschweren. Insofern verliere ich durch die getrennten Repos keine Funktionalität, die ich mit Branches innerhalb eines Repos hätte. Es erhöht meiner Meinung aber deutlich die Übersicht. Sherlock's Grafik empfinde ich in diesem Zusammenhang auch eher als abschreckendes Beispiel (@Sherlock: no offence!). In meinen Repos entstehen solche Verzweigungen fast ausschließlich durch Implementierung von Features, das Beheben von Bugs oder das Tagging des Build-Systems - und sie werden immer lokal aufgelöst. Auf den zentralen Server-Repos gibt es keine multiple heads.

Ich bin kein Mercurial Experte, aber das hört sich irgendwie nicht sehr nach einer sinnvollen Strategie an. Für sowas gibts doch Branches und Tags.
Du scheinst auch nur allein mit dem VCS zu arbeiten, sonst würd dich so einen Commit Graph ziemlich kalt lassen, da hab ich schon wilderes gesehen.
Außerdem gibt's immer die Anzeigeoption "only current branch".

Da sich ja inzwischen für Git entschieden wurde, werf ich einfach mal ein Stichwort in den Raum: Git flow