Mercurial Struktur aufbauen (Benötige Hilfe)

[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.

[Sherlock]

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

Sherlock

[RWarnecke]

Zitat von Sherlock:

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 ?

[Sherlock]

Zitat von RWarnecke:

Zitat von Sherlock:

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

[Uwe Raabe]

Zitat von Sherlock:

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.