Mercurial Struktur aufbauen (Benötige Hilfe)

[Mavarik]

Zitat von Uwe Raabe:

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 von RWarnecke:

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 von RWarnecke:

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. Was ist da denn passiert? Also grundsätzlich ist SVN auch recht cool.

Zitat von RWarnecke:

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.

[jfheins]

Zitat von Phoenix:

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.

[Phoenix]

Zitat von jfheins:

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 von jfheins:

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 von RWarnecke:

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 von RWarnecke:

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.