[linux-l] Versionskontrollen (war: Warum gibt es keine einheitliche Dokumentation?)

Steffen Dettmer steffen at dett.de
So Jan 21 15:58:24 CET 2007


* Volker Grabsch wrote on Sat, Jan 20, 2007 at 17:19 +0100:
> On Thu, Jan 18, 2007 at 12:02:33AM +0100, Steffen Dettmer wrote:
> > [mercurial + GIT]
> > > Arch und Monotone sind also IMHO keinen Blick wert, aber das ist nur
> > > mein oberflächlicher Eindruck. Ich kann mich da auch übel täuschen.
> > 
> > Wenn GIT nicht changeset basiert ist, bleibt wohl erstmal mercurial
> > heiss :)
> 
> GIT *ist* changeset-basiert. Also nochmal:
> 
> Versions-Basiert    |  Changeset-Basiert
> ------------------------------------------
> RCS                 |  Darcs
> CVS                 |  GIT
> Subversion          |  Mercurial
>                     |  Arch
>                     |  Monotone

(Ja, gut dargestellt: Subversion ist auch nur ein RCS Nachfolger. Mit
HTTP Unterstützung natürlich :))

> > > Jedes Changeset, und damit jede Version des Codes, 
> > 
> > Hum... Changeset == Version? Komisch, dachte eine Version wird durch
> > Anwendung eines Changesets zu einer anderen.
> 
> Wendet man all diese auf das "leere Repository" an, erhält man eine
> bestimmte Version.

ach so, klar.

> > Dabei kann ein Changeset aus beliebig vielen beliebig viele
> > erzeugen. Dachte ich.
> 
> Grundsätzlich schon. Aber in einem konkreten Repository haben die
> Changesets dann eine wohldefinierte Baumstruktur, und das ist auch gut
> so.
> 
> Darcs forciert den Ansatz der unabhängigen Changesets ziemlich stark.
> Das ist interessant, aber der Mehrwert ist eher gering, weil man auch
> bei problemlosen (konfliktfreien) Merges stets Gefahr läuft, dass sie
> gemeinsam einen Fehler darstellen.
> 
> Mercurial verfolgt daher den Weg, jeden Merge explizit im Baum
> darzustellen, und sei er noch so trivial.

Ja klar, wenn man Changesets anders "konfiguriert" (also statt B ein C
nimmt, und beide andere Eltern haben), muss das nicht richtig sein,
sprich, merge ok compile failed oder so :)

> Der *eigentliche*, springende Punkt ist der, dass die Änderungen eine
> Baumstruktur darstellen. 

Das hat man ja immer. Eventuell würde man sich noch gerichtete Graphen
vorstellen können (z.B. im CVS, wenn zuletzt gemergte Version --> dead
wird)

> Entartet diese Baumstruktur zu einer langen linearen Kette, hat man
> effektiv wieder ein CVS/Subversion.

Nee, hier gibt's wohl ein Missverständnis.

> Die Herausforderung, der alle Changeset-basierten Versionskontrollen
> gegenüberstehen, ist folgende: Sie müssen Teilbäume mergen. An
> irgendeiner Stelle driftet der Baum eventuell mehrmals auseinander,
> und zwei der Blätter sollen zusammengeführt werden.
> 
> Das ist glaubich auch der tiefere Grund, warum sich CVS und auch
> Subversion so schwer damit tun, "merges" zu automatisieren: Es ist
> ein konzeptuelles Problem. 

Versteh ich nicht. CVS tut sich nicht schwer und es ist automatisiert.
Ich muss nur genau sagen, /was/ ich mergen will. Von einem
Changeset-basierten SCM erwarte ich, dass es mir da hilft. Wenn ich
Changesets A, B, C und D in dieser Reihenfolge aufeinander aufbauend
habe und B gemergt habe, und dann A - D merge, sollte mir so ein SCM das
B nicht nochmal mergen. Bei CVS wäre das B komplett ein Konflikt. Ich
muss A und dann C-D mergen. CVS weiss davon halt nix. Merge ich Branches
(also sozusagen das komplette Changeset mit Eltern), das kann ich auch
inkrementell machen (und bei neuen CVS sogar ohne wanderndes Mergetag),
hab ich mit CVS aber auch kein Problem. Bloss wenn ich was "auslassen"
will oder eine Änderung, die über einen Branchmerge reinkam, in allen
Zielbranches raushaben will. Da kriege ich mit CVS nichtmal raus, wo die
hingemergt wurde! Gut, man kann natürlich commit messages etc
entsprechend benutzen.

> Wenn Subversion in 100 Jahren endlich das angekündigte "Merge"-Feature
> haben wird, 

Keine Ahnung, was das sein soll. Momentan erwartet SVN wohl noch, dass
man mit RepoNummern mergt. Da ist CVS schon weiter, da kann ich tags
nehemn.

> > > Ist aber wirklich nebensächlich. Du wirst die .hgtags nicht per Hand
> > > bearbeiten, das macht "hg tag ..." für dich. Du musst nur wissen, dass
> > > du die Datei nicht löschen darfst, 
> > 
> > Nee? Warum, kann doch einfach neu auschecken?
> 
> Ja, das schon. Aber während die Datei weg ist, kannst du keinen Checkout
> z.B. von "release-1.0" machen.  :-)
> 
> Außerdem wirst du die .hgtags nicht direkt bearbeiten oder direkt
> committen. Das passiert bei "hg tag" unter der Haube, automatisch.

Versteh ich immer noch nicht. 

Wenn ich die Datei nicht löschen darf, dann *muss* sie unter HG
Verwaltung - allein wegen Backup. 

Oder meinst Du, wenn ich die Datei lösche (weil ich z.B. die ganze
Sandbox lösche), kann ich diese Sandbox nicht mehr verwenden (aber sonst
merkt keiner was davon)? Das ist dann natürlich klar.

> Es ist halt nur interessant, dass auf diese Weise die Interna des
> Features sichtbar werden, und dass sie super mit dem Rest
> zusammenspielen, ohne eine gesonderte extra Implementierung zu
> erhalten.
> 
> So kannst du z.B. nicht nur sehen, *welche* Version als "release-1.0"
> getaggt wurde, sondern auch *wann* und *von wem*, weil das wie jede
> Änderung im "hg log" nachlesbar ist. :-)

Ich denke, dass ist dezentral? Sehe ich denn da nicht nur meine eigenen
Tags?

> > > Nicht ganz. Guter Windows-Client, sowie Zugriff über nicht-SSH, das
> > > sind schon *sehr* spezielle Anforderungen. 
> > 
> > Stimmt, und wenn man ne GUI mit grün-blauem default-Hintergrund braucht,
> > hat man noch eine *sehr* spezielle Anforderung.
> 
> Kennst du überhaupt Tortoise? Das integriert sich in den Windows-
> Explorer, und das ist gerade für Windows-Nutzer ne *sehr* feine Sache.

Ja, ich benutze das unter Windows (aber nur sehr wenig).


Nebenbemerkung:

> > > Projekte gesehen, bei denen Subversion schon allein wegen des
> > > prächtigen Windows-Clients "Tortoise" einfach mal erste Wahl war.
> > 
> > Jo, genau, prima, den Eindruck hab ich auch. Man wählt die Tools nach
> > der Anzahl der gleichzeitig in der GUI darstellbaren Farben aus. IPSec
> > oder PPTP? PPTP mit PAP, da gibt's mehr Themes für die GUI. lol
> 
> Das trifft nicht auf Tortoise zu, der hat höchstens eigene
> Dialogfenster, und die folgen der systemweiten Farbgebung.

loooooooooooooool
Das mit der "Anzahl der gleichzeitig darstellbaren Farben" war natürlich
nicht *wörtlich* gemeint.
(Ich verteile mal lieber keien Schulnoten :))

> > Ich find es i.d.R. nicht so gut, wenn man so tut, als ob komplexe
> > Probleme wie Versionsmanagement einfach wären. Als ob es einen
> > Unterschied macht, 10 Kommandos zu lernen.
> 
> Ja, das ist ein Unterschied. Für ständig benutzte Befehle (update,
> commit) mag das Befehl-Lernen sinnvoll sein.
> 
> Die seltener benutzten Befehle hingegen schlägt man eh ständig nach.
> Diese aus einem Menü auswählen zu dürfen ist definitiv benutzer-
> freundlicher.

Nein, man lässt dass einen Kollegen machen. Muss nicht (SOLL nicht)
jeder alles machen.

> Ein "man hg", Befehl raussuchen, "hg <befehl> ..." kann man natürlich
> auch als Menü-Auswahl interpretieren. ;-)
> 
> Nee, höchsten ein "hg <tab><tab>" ... und dann die Kommandos per
> Autovervollständigung, inkl. Beschreibung. *Das* ist benutzer-
> freundlich. BTW, ich müsste meine Shell mal entsprechend konfigurieren.

Ich würde bei "hg" erwarten, dass es eine Usage ausgibt. Brauchste gar
kein TAB :)

> > Wenn man dank GUI denkt, es wäre einfach, benutzt
> > man es, als wäre es einfach. Da kommt dann oft was "einfaches" bei raus
> > (vorsichtig ausgedrückt).
> 
> Die GUI darf die Konzepte nicht verstecken.

Tortoise versteckt das, finde ich. Beispielsweise wird gern rekursiv
eingecheckt, weil da ja so ein Zeichen am Ordner ist etc.
Natürlich *kann* Tortoise alles richtig, man kann es korrekt benutzen,
aber man wird nicht dazu verleitet, sondern im Gegenteil.

Gerade bei Entwicklern find ich die neumodische GUI Strömung komisch, wo
wir doch gewohnt sind, Befehle in imperativen Sprachen zu schreiben :)

> Vergleicht man hingegen *gute* GUIs (sind selten, ich weiß!) mit *guten*
> Kommandozeilen-Interfaces, dann läuft es letztlich auf rein subjektive
> Vorzüge hinaus. Dann ist es letztlich egal, was von beiden man nimmt.

Na klar, und es hängt immer davon ab, wie man es benutzt.

Aber Du schriebst ja "Subversion schon allein wegen des Clients... erste
Wahl". Das ist IMHO einfach nur falsch. Wenn's keine GUI gibt, kann
man damit leben, aber wenn das Repo nicht zuverlässig ist, dann hat man
ein Problem.

> > Aber wenn Du eine komplexe Struktur hast, die von z.B. 10 Repos stammt,
> > musst Du bei update ja je ein Kommando in 10 Verzeichnissen machen.
> > Macht CVS automatisch. SVN weiss ich nicht, vermute mal, das müsste
> > genauso gehen,
> 
> Ja, svn macht das genauso.
> 
> Mercurial nicht, aber ein "hg up *" oder ähnliches löst das Problem
> genauso.

Wir waren ja bei "atomar": ist "hg up *" atomar? 

Aber wie gesagt, ist IMHO nicht sooooo wichtig.

> > > Ich wüsste nicht, wieso ich in solch einem Szenario
> > > modulübergreifend mergen wollte.
> > 
> > Na, Du hast einen release branch, machst einen Fix (der Änderungen in
> > drei Repos braucht) und willst das halt in den trunk mergen.
> 
> Will man das wirklich? Alles auf einmal?

Ja, natürlich, wie sonst?!

> Hat man das Projekt nicht ursprünglich auf mehrere Repositories
> aufgeteilt, um sie *unabhängig* voneinander zu behandeln?

Natürlich, aber dann müsste man auf ein neues Release von modul1 warten.
So kann man einen Branch in modul1 machen. Das modul1 Team wird den dann
hoffentlich ins Release packen oder sich anderwertig darum kümmern.

In der Praxis muss man evtl. auch mal was dreckiges in so einem Branch
machen. Stört nicht weiter, wenn im trunk des modul1 das schon durch
andere Massnahmen (Refakturierung oder so) gelöst ist (sprich: in -Fixes
branches kann man notfalls hacken, wenn's nie gemergt werden wird,
macht's kaum was). Gut, mein Beispiel war natürlich gerade ein anderes,
merk ich gerade :)

Jedenfalls geht schön, schnell und elegant mit CVS finde ich.

> > > > bei CVS geht jedenfalls ganz einfach:
> > > > 
> > > > $ cvs -d $repo1 module1
> > > > $ cvs -d $repo2 module2
> > > > 
> > > > usw., danach geht ein cvs up, welches automatisch in beide Verzeichnisse
> > > > wechselt.
> > > 
> > > Klappt mit "svn up" genauso.
> > 
> > Nö, tut es nicht:
> > 
> > steffen at hostname:/tmp/steffen_exp/projectroot/ # svn up
> > Skipped '.'
> 
> Weil dein "projectroot" kein Checkout ist, oder?
> Ich dachte, es gibt immer ein "Hauptprojekt", als das "eigentliche"
> Projekt, und der Rest sind Bibliotheken/Module, die es verwendet.  In
> meinen Augen würde es sonst keine klare Struktur mehr haben.

Ja, projectroot selbst ist kein checkout, richtig. module1 und module2
wären (in meiner Praxis) dann in der Tat zwei "Hauptprojekte". Die
könnten evtl. (also in meiner Praxis mit an Sicherheit grenzenden
Wahrscheinlichkeit) ein oder mehrere gemeinsame Module haben (ggf. in
verschiedenen Varianten, Branches, ... - aber die selben logischen
Sourcen).

> Wo ist der Vorteil, das anders zu handhaben?

Weiss nicht, ich arbeite jedenfalls gern so. Wenn ich z.B. einen Bug an
einem verteilten System Stand Dez 2004 debuggen muss oder so. Überhaupt
hab ich oft so Sachen, wo neben einer Applikation oder so noch
Helfertools oder Libpackages oder irgendwas existiert. Dann hab ich ein
trouble ticket, sagen wir mal trt-123456 und würde folgendes machen
wollen:


$ cd work
$ #cd projekt  # fall es das gibt 
$ mkdir trt-123456
$ cd trt-123456
# Applikation 1.0.4
$ cvs -d $repo1 co -r module1-Release_Candidate-1_0_4 module1 
# Helper 2.8.6
$ cvs -d $repo2 co -r module2-Release_Candidate-2_8_6 module2
# Lib xyz
$ cvs -d $repo4 co -r module3-Release_Candidate-xyz module3

(das Tag sollte jeweils noch ein -Fixes- drin haben, so wäre es IMHO
weniger ein Branch als ein Release-Tag, aber dann werden die Zeilen ja
noch länger lol)

oder sowas in der Art. Dann hab ich "alles, was eine Rolle spielt" in
trt-123456. Ich kann mir da noch einen Webserver oder sonstwas
installieren, was auch immer nötig ist. Das lösche ich nach dem Fix auch
nicht gleich, weil ich teils erst nach 3 Monaten weiss, ob das jetzt
alles funktioniert. Aber das sind extreme Ausnahmen. Da kann man auch
die drei cvs up per Hand machen, ist für mich nach wie vor kein
wichtiges Feature. Aber es geht. Bloss halt nicht atomar. Und, um zum
Ausgangspunkt zurückzukommen, es wird auch mit SVN nicht atomar gehen
(gut, nun wissen wir, dass es überhaupt nicht geht).

Aber soviel Text für ein so unwichtiges und diskussionsfähiges Feature
ist unangemessen :)

> > Bei uns wird bestimmt irgendwo auf der Welt gerade jemand ein update
> > machen, einen nicht-kompilierenden Zwischenstand auschecken, nach 15-30
> > Minuten rumsuchen eine Mail schicken und gleich noch eine ("sorry, just
> > saw that it is fixed already") 
> > 
> > :-)
> 
> Merkwürdige Schnittstellen, wenn ein Bugfix mehrere Module beeinflusst,
> und deren Änderungen nicht unabhängig voneinander sind ...
> 
> Wenn die Einzelteile so stark miteinander verwoben sind, wieso teilst
> du sie dann auf unterschiedliche Repositories auf?

lol

Es ist normal, dass eine externe Schnittstelle mindestens in zwei
Modulen eine Rolle spielt: in dem Modul, was sie implementiert und in
dem Modul, was sie benutzt. Oft gibt es natürlich mehrere Module, die es
benutzen. Ist doch ganz klar, oder?

Wenn man z.B. von 100 Bugs pro Release ausgeht (bei einem 500.000 Zeilen
grossen Projekt mit "vielen Änderungen", also z.B 5% - 10% ist das
wenig!!), sind bestimmt eine Handvoll dabei, wo es um Schnittstellen
geht. Beliebt ist gerade in Release-Branches (wo man ja nur einen
temporären Fix machen will, die eventuell notwendige grosse
Änderung/Korrektur macht man natürlich im trunk), mal einen komischen
Parameter einzubauen. Sowas hat man z.B., wenn sich eine Funktion falsch
verhält, aber sich an anderer Stelle auf den Fehler verlassen wird und
eine Änderung zu gross werden würde oder im trunk schon gemacht ist,
aber nicht backgeportet werden soll, z.B. weil zu gross oder abhängig
von anderen Änderungen etc.

(Je mehr ich versuche, dass zu erklären, desto unklarer wird es für mich,
wie man überhaupt zu diesem Trugschluss kommen konnte...)

Das ist nicht stark verwoben. Bei einem Projekt, welches zu 90% libs
verwendet und die Änderungen / Erweiterungen etwa gleich verteilt sind
(also insbesondere "agile software projects") ist zu erwarten, dass 90%
der Bugs in Libänderungen reingekommen sind (bzw. drin waren).

> > > Willst du trotzdem aus irgendeinem Grund mehrere Branches in einem
> > > Repository, geht das mit Mercurial auch. Es warnt halt nur, weil's
> > > i.d.R. nicht das ist, was man will.
> > 
> > in einem Repository oder in einer Sandbox? Oder sind solche CVS/SVN
> > Begriffe hier einfach nur falsch?
> > 
> > Bei CVS hab ich eine Sandbox, die i.d.R. aus einem Branch stammt (die
> > alle im Repository liegen). Ich kann natürlich Dateiweise mischen (nach
> > SCM-Terminologie "konfigurieren").
> 
> Was in CVS als Sandbox-Muster bezeichnet wird, ist genau das, was in
> Darcs/Mercurial/GIT/... bereits ein Repository *ist*. Insbesondere kann
> sich dort jeder selbst beliebig viele "Sandboxes" anlegen. 

Aber das sind doch Eigenschaften von dezentralen Systemen, nicht von
Changeset-basierten, oder? Auch wenn vermutlich viele Tools beides oder
keins davon implementieren...

Kann ich denn in hg nicht so arbeiten, als ob ich ein zentrales Repo
hätte, sprich, in einer per Konvention ausgewählte Sandbox immer alles
reinmergen? Und dann von dieser ein Backup machen etc? Müsste doch
gehen, oder? Statt einchecken (bzw. zusätzlich) macht man hin- und
wieder einen "push" oder wie das heisst. Ginge doch, oder?

> Weil das so einfach ist, ermöglicht es eine Weiter-Entwicklung des
> Sandbox-Musters: Micro-Branches. Häufige, private Branches, die
> ständiges Merging erfahren, dafür sind Mercurial/Darcs/GIT/... super
> geeignet, und das ist eine *sehr* angenehme Art der Entwicklung.

Ob so ein Branch zentral ist oder nicht, sollte man ja gar nicht merken.
Blöd wäre nur, wenn bei dezentral der gleiche Branchname zweimal
verwendet wird. Was macht hg in so einem Fall eigentlich?

> Aus der Mercurial-Philosophie: Jedes Arbeitsverzeichnis ist ein Repository
> und damit ein (potentieller) Branch.
> 
> Kopiere dein gesamtes Arbeitsverzeichnis woanders hin (auch: auf einen
> anderen Rechner), arbeite in beiden Verzeichnissen unabhängig voneinander.
> Jederzeit kannst du die Änderungen des einen in das andere mergen.
> Eventuell musst du Konflikte lösen, aber mehr nicht. Die Übersicht hat
> Mercurial.
> 
> Du kannst dann wirklich frei in Begriffen denken wie: "Branch sowieso
> wurde in Trunk gemerged." Kein Herumfummeln mit internen Versionsnummern
> und ähnlichem.

Ja klar, "Trunk" ist dann eher eine Art "offizieller Stand" oder eine
"Sandbox Claudia" oder wie man die nennt :) 

Aber im Team muss ja sowas wie ein "trunk" existieren, damit alle in die
gleiche Richtung entwickeln, auch wenn man den komfortabler usw.
verwalten kann.

> Schau doch einfach selbst mal in die GIT- und Mercurial-Einleitungen.
> Da gibt's auch spezielle Hinweise für CVS-Umsteiger, also für dich.
> Wenn du dir die Zeit nimmst, meine Mails zu lesen, kannst du dort auch
> ruhig mal surfen. Dort ist es wahrscheinlich auch viel besser erklärt,
> als ich es hier könnte.

Jo, juckt schon ein bisschen unter den Nägeln... Aber gibt so viele
andere Sachen, dass ich das bis jetzt noch nie geschafft habe.
Insbesondere bei der Bitterkeit, dass ich auf Arbeit CVS und SVN nutzen
"muss" :)

> > Praktisches Nummer #1 Beispiel ist wohl, wenn eine "unten" (Basis, lib)
> > Funktionen einen neuen Parameter braucht. Muss in lib (modul1) und
> > natürlich vom Aufrufer (modul2) beachtet werden. nicht-atomares
> > einchecken kompiliert nicht unbedingt (kann ich natürlich machen, wenn
> > ich lib / modul1 kompatibel halte, aber wenn ich gerade Fehler erzwingen
> > möchte, wenn der Parameter fehlt, geht das halt nicht).
> 
> Welchen Sinn haben dann die unterschiedlichen Repositories? Dein
> Szenario funktioniert nur, wenn du davon ausgehst, dass kein weiteres
> Projekt dein "modul1" benutzt. Sonst würde dir auch eine atomische
> Änderung von modul1 und modul2 nichts bringen, weil trotzdem app5 auf
> server132 kaputt geht.

app5 benutzt ja den Branch module1-Release_Candidate-1_0_4 nicht
(sondern z.B. app5-Release_Candidate-2_7_1_9_0_1_1), damit geht app5
nicht kaputt. Ausserdem ist es unwahrscheinlich, dass neben modul1 auch
ein app5 release gemacht werden muss OHNE dass Leute an beidem arbeiten.
Also, wenn app5 und modul1 abhängig sind, muss es einen geben, der beide
integriert. Sind sie unabhängig, muss man nicht beide gleichzeitig
releasen oder extrem ähnliche Stände haben. Zwischendinger sind IMHO
erstmal falsch :).

In dem rein fiktiven Beispiel ( ;) ) würde es ca. 60 Module (SCM
Komponenten) geben, die in vielleicht 40 Systemen (Projekten,
Applikationen) in vielleicht 5 Ländern benutzt werden.

> Will sagen, atomische Commits über mehrere Repositories lösen ein
> Symptom, aber nicht das Problem.

Auf atomare Commits kann man verzichten, wenn man atomar mergen kann,
klar, dann könnte man einen ci-branch machen, in aller Ruhe einchecken
und mergen. Aber das geht bei CVS konzeptuell nicht, bei SVN genauso,
bei anderen weiss ich nicht, aber rein logisch dürfte es auch nicht
(immer, zuverlässig) gehen, weil das merge-Ziel ja immer in der
Zwischenzeit geändert sein könnte und damit immer ein Konflikt auftreten
könnte (den man ja nicht atomar lösen kann).

In der Praxis würde ein atomares Commit das alles lösen. Man könnte sich
beliebiges in die Sandbox mergen und wenn beim einchecken eine Datei ein
Konflikt bekommen würde, wird gar nichts eingecheckt.

CVS macht das so nur Repository-weise.

> Dass Subversion jedoch ein auf HTTP basiertes Protokoll spricht, *hat*
> handfeste Vorteile: Du kannst das Repository über einen Webserver
> verfügbar machen. Kein zusätzlicher Port, kein extra abzudichtener
> SSH-Zugang.

lol

Man hat doch SSH sowieso, aber kein HTTP in ernstzunehmenden Umgebungen,
weil HTTP einfach viiiiiiiiiiiiiiiieeeeeeeeeeel zu viel kann.
Beispielsweise das Tunneln beliebiger Daten. Ohne vernünftige eingebaute
Authentifizierung wie bei SSH :)

Also, wer mit HTTP und "nicht extra abzudichten" kommt... naja.
Vielleicht Geschmackssache.

> Eleganter ist z.B. das, was Mercurial macht: Sie bieten ein CGI-
> Script an. 

genau, besser, Apache unabhängig und vermutlich sogar (ziemlich) HTTP
unabhängig.

> Besonders absurd: Es gibt dann wieder CGI-Scripte für SVN-Repositories,
> d.h. beides geht über HTTP, über einen Webserver, aber das eine per
> CGI-Script und das andere als Apache-Modul, entsprechend mit
> unterschiedlichen URLs etc.

cool :)

> Konkret in Mercurial hast du in deinem Arbeitsverzeichnis ein
> Unterverzeichnis ".hg". Im Gegensatz zu SVN und CVS hast du das
> nur einmal, nicht in jedem Unterordner (".svn/" bzw. "CVS/").

das .hg hab ich nur einmal? Aber was ich wie und wohin auschecke, ist
doch nur meine lokale Sicht? Geht das mit HG nicht? hum, dass wäre ja
eine Einschränkungen...

Na ja, mit meinem Halbwissen komme ich an solchen Detailfragen natürlich
eh nicht weiter :)

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.





Mehr Informationen über die Mailingliste linux-l