"moderne" Versionsverwaltung und shared Units

[Sherlock]

Moin zusammen,
wir wollen von JediVCS umsteigen auf ein etwas moderneres Versionsverwaltungssystem wie zum Beispile Mercurial oder Git. Was man da so drüber im Internet liest, ist es praktisch Geschmackssache, welches davon man verwendet.
Es gibt reichlich Ein- und Umsteiger Tuts, so daß die ersten Schritte vermutlich gar nicht weh tun werden. Was ich aber nicht so ohne weiteres finde, ist ein bestimmtes Detail, über das wir uns im Rahmen von JVCS gar keine Gedanken machen mussten, bei hg/Git scheint das aber etwas komplexer zu sein: Wie ist das mit der projektübergreifenden Verwendung von Units?
Wir versuchen möglichst viel Code wiederzuverwenden, JVCS unterstützt das transparentund nahezu automagisch (entsprechende Verzeichnisstruktur und Disziplin in den Projektdateien vorausgesetzt). Bei hg/git sehe ich so Dinge wie Subrepositories und Submodules und viele "pain in the ass" Kommentare dazu. :roll:

Wer hat so ein System unter ähnlichen Bedingungen im Einsatz und kann ein bis zwei (handvoll) Tips geben? Vielleicht noch mit Version Insight Kommentaren gewürzt? :D

Ich danke im Voraus.

Sherlock

[Phoenix]

Also ich les da nur 'really really easy to use': http://stackoverflow.com/questions/2...or-remote-repo

Ich würde übrigens eher Mercurial (Hg) empfehlen.
Es hat nur ein paar extrem selten genutzte Features weniger als Git, aber dafür ein deutlich besseres grafisches Tooling.

Ausser natürlich, ihr seid alles Commandline-Wizards und könnt Euch ungeheuer viele Befehle auswendig merken und wollt auch immer alles eintippen was ihr macht - dann ist Git das richtige ;-)

[Uwe Raabe]

Zitat:

Zitat von Phoenix (Beitrag 1181142)

Ich würde übrigens eher Mercurial (Hg) empfehlen.
Es hat nur ein paar extrem selten genutzte Features weniger als Git, aber dafür ein deutlich besseres grafisches Tooling.

Dem kann ich mich nur anschließen! Ich bin schon seit ein paar Jahren von SVN auf Mercurial umgestiegen und nach dem obligatorischen Kulturschock komme ich bestens damit klar.

Leider hat mein Vortrags-Vorschlag für die Delphi-Tage "DVCS für Delphianer" es dieses Jahr nicht in die Agenda geschafft. Aber vielleicht beim nächsten Mal.

[Panthrax]

Ich habe mich für Git entschieden, aus diesen Gründen:

Ich fand Git auf der Befehlszeile hilfreicher und das Auftreten dort etwas gelungener als bei Mercurial, auch wenn die vielen Optionen und Schalter von Git anfangs etwas einschüchtern. Eigene Automatisierungen durch das programmatische Aufrufen von Befehlen und das Abgreifen ihrer Ausgaben gingen mir bei Git daher etwas leichter von der Hand. Bspw. nutze ich für die automatische Versionierung Informationen aus dem Projektarchiv.

Bei Git kann man auswählen, welche entfernten Linien in das lokale Projektarchiv kopiert werden sollen und welche von denen nachverfolgt werden sollen. Mercurial übernimmt immer die Informationen zum gesamten Projektarchiv. Nichts abwählen oder auslassen zu können, war für mich irgendwie wider dem Prinzip "So viel wie nötig, so wenig wie möglich". (Aber diese Information ist mittlerweile einige Jahre alt.)

Ich habe mit Subversion angefangen und es meistens über TortoiseSVN bedient. Ich bin dort aber schon auf die Befehlszeile gewechselt, so dass beim Umstieg auf eine dezentrale Versionsverwaltung die grafische Bedienung keine Rolle mehr spielte -- mit einer Ausnahme: Die Betrachtung der Versionshistorie. Dafür bieten sowohl Git (gitk) als auch Mercurial (Befehl ist mir entfallen) gute grafische Betrachter, oder man nutzt doch wieder Hilfssoftware (TortoiseGit, TotoiseHg,...), womit ich mich aber nicht näher auskenne.

Git unterstützt es, ein Subversion- in einem Git-Projektarchiv zu halten. Damit deckt man viel ab, wenn man Fremdbibliotheken in ihrer Originalversionsverwaltung halten will. Für Mercurial gibt es eine Erweiterung, um ein Git- in einem Mercurial-Projektarchiv zu halten. (Das ist auch eine ältere Information, vielleicht gibt es da heute mehr.)

Mit Mercurial kann man Dateien explizit umbenennen, Git macht das nur implizit.

Mercurial for Git Users
A Collection of how Git compares to other Version Control Software
Git vs. Mercurial: Please Relax
Mercurial and Git: a technical comparison
Mercurial vs. Git: Why Mercurial?

Und bezüglich der Molularität:

Git Submodule Tutorial

Zu guter Letzt: Allgemein ist es sicherlich weniger ein ausschlaggebender Grund, aber doch ein bestätigendes Ereignis meiner Entscheidung für Git: Der Befehl "git bisect" ließ sich vergleichsweise leicht automatisieren. Mercurial hat sich diesen Befehl zwar irgendwann einmal souverän abgeguckt, aber hat die schöne Automatisierungsgrundlage ("git bisect run") nicht übernommen.

Weil ich für die Automatisierung mit Delphi nichts im Netz fand, habe ich dafür selbst etwas geschrieben und das Ergebnis veröffentlicht, denn es war dennoch ein gewisser Aufwand, den sich andere vielleicht nicht machen müssen -- ganz besonders, weil es (hoffentlich) ein seltener Anwendungsfall ist. Mal gucken, ob es jemandem nützt...? Mehr Informationen gibt es hier: Panthrax Qualitas. Hinweis zum Projekt: Das Projekt ist erst seit August veröffentlicht, und nicht groß in die Welt getragen. Der Name ist eigentlich der interne Projektname, einen externen Projektnamen hat das Projekt nie (noch nicht?) erhalten. Ernsthafte Vorschläge werden gern angehört.

[shmia]

Etwas OT aber hier ist mein .gitignore File das auch für Mercurial passen dürfte.
Dieses File sollte vor dem 1. Commit vollständig sein, damit man keinen Ballast (Zip-Dateien,...) eincheckt, den man nie wieder aus dem Repository entfernen kann.

Code:

# Delphi files
*.~*
*.exe
*.map
*.gex
*.local
*.identcache
*.res
*.dcu
*.dsk
*.drc
*.cfg
*.dti
__history/

# other files
thumbs.db
*.rar
*.zip
*.7z
*.bak
*.sav

# DUnit ini file
dunit.ini

# directory for local,private stuff
Private/

[Sherlock]

Bist Du sicher, daß .res Dateien ausgeschlossen sein sollten?

Sherlock

[Panthrax]

Ja, das ist üblich. Ich mache das auch. Die Losung lautet: Das Projektarchiv nimmt nur originäre Daten auf. Anders herum gesagt: Das Projektarchiv nimmt keine Daten auf die sich aus anderen Daten erstellen lassen.

Etwa bei Ressourcen sollten die *.rc-Dateien und von ihnen referenzierte Quellen aufgenommen werden. Im Erstellungsprozess der Anwendung könnten die Ressourcendateien (*.res) dann miterstellt werden -- so wie das Delphi für die Formulare macht. In diesem Zusammenhang wird Konfigurationsmanagement für Projekt und Entwicklungsumgebung bedeutsam.

[Sherlock]

Ich danke allen für ihren Input. Speziell das hier (was ich nach den Anregungen fand)
http://www.fogcreek.com/kiln/trainin...brepositories/
hat wirklich geholfen.

:thumb:

Sherlock

[Assarbad]

Zitat:

Zitat von shmia (Beitrag 1181257)

Etwas OT aber hier ist mein .gitignore File das auch für Mercurial passen dürfte.

Bei Hg gehört noch ein

Code:

syntax: glob

davor ... oder ein glob: bzw. regexp: auf jede Zeile, entsprechend der benutzten Syntax.

Ansonsten halte ich es mit Hg, weil die Windows-Unterstützung bei Git gelinde gesagt räudig ist. Es geeeeeht, wenn man ein wenig leidensfähig ist, aber insgesamt keine schöne Erfahrung. Inzwischen hat sich an der Front auch etwas getan und man muß sich sein Git nicht mehr selber kompilieren (was dann etwa 1,5 GiB Objektdateien hinterließ und lange dauerte). Dennoch zeigt sich leider immer wieder der Ursprung von Git durch diese seltsame Mischung von Shellskripten und Programmen.

Von den Features her sind sie so gut wie identisch. Und das vielfach behauptete Killer-Feature von Git, "Staging", ist wirklich kein Grund den Komfort von Hg aufzugeben (ähnliches erreiche ich auch mit lokalen Klonen). Das eigentliche Killer-Feature in Git für mich ist git-cvsserver. Auf Windows benutze ich TortoiseHg mit hgsubversion und hg-git (+ dulwich, welches aber in TortoiseHg schon enthalten ist) und auf den unixoiden Systemen eben reines Hg.

Auch schön: mußte letztens auf einem alten Redhat-Linux 5-irgendwas (ja, ich meine nicht RHEL) Hg aus den Quellen bauen und das ging schmerzfrei, während sich Git etwas anstellte.

Der zuvor verlinkte Artikel ("Mercurial vs Git: Why Mercurial?") faßt übrigens einige meiner Erfahrungen mit Git und Hg gut zusammen. Ich muß beruflich aber ohnehin beide, plus SVN und CVS benutzen.

Aber jeder nach seiner Façon, gell? ;)

[Sherlock]

So, nach einem Urlaub, Entwicklungsarbeit und sonstigen Kleinigkeiten (XE3 Roadshow Frankfurt, letzte Woche :thumb:) bin ich wieder an dieser Sache dran. Nochmal eine kurze (stellenweise detailliertere) Zusammenfassung:
Ziel ist Mercurial als SCM zu verwenden.
Es gilt grob geschätzt 30 Projekte zu pflegen, die mal größer mal kleiner sind, mal arbeiten mehrere Kollegen gleichzeitig daran, mal nicht. Für beinahe jedes dieser Projekte gilt, daß sie auf mehrere gemeinsame Units zugreifen, von denen es mindestens ein Dutzend gibt. Bisher wurde JVCS verwendet, das aber nunmal tot ist. Dort hat alles wunderbar geklappt, bis auf Branching, was für uns aber immer mehr zur Notwendigkeit wird - darum der Umstieg.

Konkretisierte Fragen:
Welche Methodik muss man anwenden, wenn man solche projektübergreifende Units hat, damit man bei der täglichen Arbeit von Änderungen an diesen Units erfährt? Wie sollte die Verzeichnis-/Repositorystruktur aussehen?

Mein Wissensstand bisher:

• http://hginit.com/01.html - Sehr schönes Tut, das mir eingies klar gemacht hat, auch wenn ich Tortoise und VersionInsight verwende
• http://www.selenic.com/hg/help/subrepos - Scheint eine ziemlich fummelige Handarbeit zu sein, immerhin nur einmal pro Hauptprojekt nötig (in meinem Fall jedoch mindestens 30 mal)
• http://mercurial.selenic.com/wiki/Subrepository - Abschreckender Hinweis: "Feature of last resort"
• http://mercurial.selenic.com/wiki/Un...urial#line-252 - im von mir erträumten Zusammenhang ein ziemlicher Abtörner

Provokante Nebenfrage: Ist Mercurial also unter dem Strich eigentlich nur für Hobby-Entwickler gedacht, die mal in diesem (Mozilla) mal in jenem (Linux) Projekt ihre Finger haben, so daß Codesharing irrelevant ist?

Ein leicht frustrierter,
Sherlock