"moderne" Versionsverwaltung und shared Units

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



Sherlock

[Assarbad]

Zitat von shmia:

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 ) 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

[mkinzler]

Schau dir mal PlasticSCM an

[Sherlock]

Habs mir angesehen, aber ich denke von einem teilkommerziellen Projekt, das eventuell mit der nächsten Version schon vollkommerziell wird, lass ich lieber die Finger. Sieht aber insgesamt sehr gut aus. Dennoch versuche ich mein Glück ab heute mit Mercurial. Werde vielleicht die Zeit finden ein Tutorial zu schreiben, denn sowas hab ich hier echt noch vermisst. Vielleicht findet sich dann doch noch der eine oder andere Input

Sherlock

[mkinzler]

Die Lizenzdatei, die man bekommt läuft nicht ab. Selbst wenn der Hersteller für neuere Programmversionen keine freie Version mehr anbieten würde, können ältere Programmeversionen so unbeschränkt weiter genutzt werden.

[himitsu]

Das wäre ja sonst so, als wenn der Zündschlüssel nimmer passen würde, wenn das nächste Model auf den Markt kommt.

Die Frage ist dann nur, wie das z.B. mit Bugs ist (kennt ihr ja von Emba, wenn die nächste Version kommt) und neuere Features lassen wir mal außen vor.