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

[Steffen Dettmer]

* Volker Grabsch wrote on Wed, Jan 17, 2007 at 00:32 +0100:
> > DokuWiki kann keine eMails schicken?! Windows-Programm?
> 
> Damals konnte DokuWiki das nicht. Vielleicht mittlerweile doch, dann
> wäre es wieder für mich interessant.
> 
> Mit einem Kommentar "Windows-Programm?" kann ich nichts anfangen.

Irgendwie kann jedes sinnvolle Unix-Program ne Mail verschicken (z.B. in
dem man ein status-Anzeiger via cron startet, eine "pipe" Funktion drin
ist, mail von sich aus aufgerufen werden kann, irgendwas geht ja immer.
Ausser natürlich beim KDE, aber das hat ja nix mit Unix zu tun). Bei
Windows-Programmen hab ich so eine Funktion allerdings schon hin- und
wieder vermisst.

> > ach so, schlichte Altlast, kenn ich, hab ich auch überall... 
> 
> Nö, nicht unbedingt. Öffentliche Projekte mache ich lieber via SVN
> verfügbar. Dafür gibt's einfach mehr Clients, u.a. einen ziemlich
> guten SVN-Client namens "Tortoise", der sehr gut in Windows integriert
> ist.
> 
> Zudem kann man SVN-Repositories, via HTTP/DAV/SVN aufgesetzt, auch
> direkt mit dem Browser ansteuern. Dies kann man mit entsprechenden
> CGI-Scripten natürlich auch bei Mercurial & Co.

Super. Brigt natürlich die Gefahr, dass Leute, die nur mit'm Browser was
ansteuern können, das Repo ansteuern ;)

Nee, natürlich stark übertrieben. Ich nehme auch gern Browser.

> > "Hand anlegen" geht doch aber absolut nicht, wenn das automatisch
> > erzeugt ist!
> 
> Das ist leider die Crux an der Sache. Wenn *ich* aus einem *eigenen*
> Format LaTeX erzeuge, kümmere ich mich darum, dass übersichtlicher
> Code generiert wird. Gerade *weil* ich ihn noch nachbearbeiten möchte.

Und die ganzen Änderungen notierst Du Dir dann und wenn Du aus einem
aktualisiertem File das aktualisierte LaTeX erzeugst, machst Du die alle
nochmal?!

> > > Ich sehe daher nicht, wieso dieses Argument dafür spricht, gleich alles
> > > selbst in LaTeX zu tippen oder in OpenOffice oder so, und dann nach
> > > PDF zu konvertieren.
> > > 
> > > Nur, weil du in LaTeX kleine End-Korrekturen machen musst, schreibst
> > > du lieber den ganzen Text mehrfach?
> > 
> > Nein, das Problem ist doch, dass ich nach jeder Änderung im reST das
> > LaTeX neu erzeugen muss (also via make oder so, egal).
> 
> Ich sprach von End-Korrekturen!

"Ende" gibt's nicht. Wie soll das gehen? Ab heute per Definition fertig
und fehlerfrei? Wenn man das LaTeX geändert hat, darf man das reST ja
nie wieder ändern, oder muss das LaTeX nach der Neuerzeugung komplett
nochmal so ändern oder man pflegt beide parallel (redundant).

Ergo darf man das automatisch erzeugte (abgeleitete) nicht ändern.
Oder?

> > IMHO ist dann sowas wie \latexonly das kleiere Übel - aber so richtig
> > überzeugend auch nicht...
> 
> Grundsätzlich ja, und bei klassischen Codegeneratoren würde ich vollkommen
> zustimmen. (Bin kein Fan von Roundtrip-Engineering)
> 
> Aber konkret bei End-Korrekturen ist aber die nachträgliche Änderung am
> LaTeX-Code viel schmerzfreier als irgendwelche \latexonly-Aktionen. Die
> wären nämlich tickende Zeitbomben. Sie werden dir in Zukunft sogar eher
> auf die Fuße fallen.

... wo hingegen bei "per Definition" natürlich in Zukunft gar nichts
passiert, weil man ja nichts ändern darf. Klingt prima, aber absolut
unrealistisch, dass man nicht doch was ändern muss :)

> Beispiel: Deine End-Korrektur sieht einen manuellen Seitenumbruch vor.
> Einige Zeit später kommt an diese Stelle viel mehr Text. Also:
> Plötzlich stehen wenige Zeilen allein auf einer Seite.

Wie: "später"? Nach dem Ende? Fängt man von vorn an?
Wenn ich das Korrigierte neu erzeuge, wird doch logischerweise das
Korrigierte überschrieben. Wir reden aneinander vorbei, bloss an welchem
Punkt?

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

> > > Ditto übrigens auch für Tags. Mercurial hat eine .hgtags-Datei. Sehr
> > > clever gelöst, finde ich. In CVS natürlich nicht machbar, weil jede
> > > Datei ihre eigene Rev.-Nummer hat.
> > 
> > Versteh nicht, was eine .hgtags-Datei ist. Bei CVS sind Tags Symbole
> > (strings), werden z.B. bei sticky-tags in CVS/Entries und CVS/weissnicht
> > verwendet. Na egal, eher Implementierungsdetails.
> 
> Jedes Changeset, und damit jede Version des Codes, 

Hum... Changeset == Version? Komisch, dachte eine Version wird durch
Anwendung eines Changesets zu einer anderen. Dabei kann ein Changeset
aus beliebig vielen beliebig viele erzeugen. Dachte ich.

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

> > > Vielleicht hätte ich von Anfang an Mercurial empfehlen sollen.
> > > Aber die meisten, die ich bisher kennenlernte, wollten lieber
> > > erstmal Subversion haben. Und gröartige Keywords, Ignore-Datein
> > > etc. hatten sie eh nicht.
> > 
> > Ja, hab auch den Eindruck, SVN ist gut wenn man keine bes.
> > Anforderungen hat.
> 
> 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.

> Zudem hat die Idee einer *zentralen* Versionsnummer auch eine gewisse
> Berechtigung bei einfachen Projekten. Ich habe durchaus 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

na, genug gelästert :)

> Dennoch: Ein anfängerfreundlicher Client, gut ins Dateisystem oder
> ähnlichem integrierst, das ist schon ne Anforderung, ne ziemlich harte
> sogar. Da rockt Subversion AFAIK gegenüber allen anderen.
> (CVS/Darcs/GIT/Mercurial/...)

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. Das ist einfach. Andere
Sachen sind schwierig. 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).

> > > Ich habe übrigens ein Makefile für meine Java-Sachen geschrieben.
> > > Gut, damals gab es auch noch kein ant.
> > 
> > Ich nehm einfach händische Regeln im automake. Hab auch paar Ideen,
> > wie man das relativ brauchbar machen könnte, aber dazu hat's dann
> > noch nicht gereicht. Aber "make distcheck" ist wirklich cool.
> 
> Automake, sehr schöne Idee. Obwohl ein handgestricktes Makefile auch
> nicht der Hit ist, zumal sich javac (bzw. jikes, den ich nehme) ja
> selbstständig um die Abhängigkeiten kümmert.

Das javac kümmert sich ziemlich dämlich darum. Es kann z.B. kein
analogon zu "clean". Aber es ist verdammt schnell. Aber um
Abhängigkeiten kümmern?

Die Zahlen sind wg. copy und paste genau, aber die Metrik rechnet gar
nicht so genau. Aber Grössenordnung stimmt :-) Es sind zwischen zehn und
hundertausend Zeilen :) 

Beispiel mit 16.227 Zeilen Java:
  nach clean:  0m1.517s
  zweites mal: 0m1.474s

Beispiel mit 43.600 Zeilen Java:
  nach clean:  0m2.601s
  zweites mal: 0m2.593s

spart 40 ms bei 20k LOC, also 0.002 MILLIsekunden pro Zeile... Wozu
da Abhängigkeiten?

Beispiel mit 31.696 Zeilen C++:
  nach clean:  0m32.981s   (zwei Kerne benutzt)
  zweites mal: 0m0.269s

Die C++ Sourcen waren dabei über etliche Verzeichnisse verstreut. Ich
finde das schon interessant. Mit Optimierungen wird C++ natürlich noch
deutlich langsamer. Vermeidet man templates und bestimmte andere
Konstrukte und spart includes, kriegt man C++ natürlich schneller.

Beispiel mit 23.237 Zeilen C:
  nach clean:  0m2.767s
  zweites mal: 0m0.082s

Beispiel mit 61.660 Zeilen C:
  nach clean:  0m5.926s
  zweites mal: 0m0.242s

Immernoch nur halb so schnell wie Java :)

Gut, hinkt natürlich, weil ja Java nicht "ganz" kompiliert etc.

> > Meiner Meinung nach sind das alles Bugs. Ich verwende schon lange make,
> 
> Cool. Dann hab ich mal ne Frage: Wie stehst du eigentlich zu der Frage
> des Projektes mit mehreren verschachtelten Unterordnern:
> 
> a) Jeder Unterordner ein eigenes autonomes Makefile, und "make" rekursiv
>    aufrufen lassen?
> 
> b) Nur ein einziges Makefile, und in den Unterordnern höchstens Include-
>    Dateien für das Haupt-Makefile.
> 
> Siehe auch: http://www.delorie.com/gnu/docs/automake/automake_33.html

Das ist eine sehr schöne Frage! (Die URL ist aber mit Vorsicht zu
geniessen, glaube ich).

Erstmal ist b) in der Leseart "wenig Makefiles" schon besser.
Viele Gründe aus "Recursive Make Considered Harmful" spielen mit
automake/autoconf (und geschickter Benutzung) kaum eine Rolle, aber ein
tolles Argument ist: make ist ein Expertensystem. Rekursiv ist es mehere
Expertensysteme, da kommt weniger effizientes bei raus.

Allerdings hat ein "Einzel-Makefile" Nachteile: Verzeichnisse sind nicht
mehr so unabhängig, wie sie sein könnten. Hat man gar SCM Komponenten,
möchte man das Wissen, wie das gebaut wird, ja lieber in den SCM
Komponenten verwalten (die wissen, wie sie gebaut werden
müssen/können/wollen). In Teams mit Versionskontrolle z.B. möchte man
einzelne Verzeichnisse (Module, ...) in verschiedenen Branches benutzen.
Vielleicht machen (wie z.B. bei uns) nichtmal die selben Leute Sourcen
und Makefiles (gut, letzters sind auch sourcen, aber wir haben sozusagen
automake und autoconf Experten). Dass muss man "mischen" können (also:
Modul X von gestern, Modul Y mit dem Fixes-Branch und den neuen Files,
...). Das geht schlecht, wenn man ein zentral-Makefile hat (das muss es
ja dann für alle Kombinationen geben).

(Modul ist hier nicht im Sinne von .c-Modul zu verstehen, sondern
grösser gemeint. Package, Unit, sowas.)

Ich finde also 

c) Mindestens ein Makefile je SCM Komponente ("Modul", "Package")

Dabei darf das ggf. noch strukturiert sein.

Dabei kommt man dann oft recht schnell zu "Ein Verzeichnis pro
Strukturelement". Sind die eher unabhängig voneinander bzw. bilden einen
schönen gerichten Graphen mit eher schmalen Schnittstellen (fan-ins),
sind das "Untermodule". Die neigen dazu, später (nach gelegentlichem
Wachsen) zu richtigen eigenen Modulen refakturiert zu werden.

Da kann man dann oft sagen: Ein Makefile pro Untermodul. Da man
Untermodule machen soll (sind schliesslich nur logische
Verzeichnisstrukturen), hat man oft ein Makefile pro Verzeichnis
(welches Sourcen enthält).

Daher kann ich recht gut mit der automake-default-Idee leben, dass man
ein Makefile pro Verzeichnis hat.

Die automake-Features sind auch nicht sooo alt. Auf einer Maschine, für
die ich bauen muss, gabs nichtmal "nodist_". Ärgerlich, wenn man
zu kompilierende BUILT_SOURCES hat.

Na ja, automake und autoconf sind (immer noch) krank. Aber ich kenne
nichts besseres :)

Verwendet man (nur, moderene, GNU-) Makefiles, kann man natürlich auch
sehr viel in make programmieren :) Auch includen etc. Allerdings legt
man sich da auch schnell die Karten (wenn man Makefiles automatisch
erzeugen muss). Da gibts eine Million Fallen. Mit automake haben wir es
zumindestens mit neueren Versionen immer irgendwie hingekriegt.

> Ja, da kann ich nur zustimmen. Eines meiner besten Scripte ist sehr,
> sehr klein. Dank make. Als Shell-Script oder in Perl/Python/... wäre
> es ziemlich umständlich geworden. Wenn's dich interessiert:
> 
>     http://oss.m-click.ws/index.php?area=make_crontab
> 
> Ich hab's vor ein paar Wochen nochmal weiter vereinfachen können. Und
> trotzdem mehr Features unterbringen können. Auf der Projektseite ist
> das noch nicht dokumentiert, aber in den README-Dateien im Subversion:
> 
>     https://ds.m-click.de/svn/m-click/make-crontab/trunk/

Das Makefile mit der einen Regel "$(RESULT): $(SOURCES) Makefile" (wenn
man von dist mal absieht)? Das geht doch in bash genauso, wenn man ein
test -nt vormacht, oder?

Da könnte man vielleicht noch bissel was machen, wenn man pattern
definieren kann. Also z.B. (ungetestet, bin mir bei $< und so nicht
sicher):

SOURCES = $(wildcard crontab-*.src)
HELPERS = $(patsubst %.src, %.tmp, $(SOURCES))

$(RESULT): $(HELPERS) Makefile
	cat $(HELPERS) > $@
	crontab $@

%.tmp: %.src
	NAME=`echo "$$FILE" | sed "s,^crontab-,,"` ; \
	... usw ...
	sed "s, at NAME@,$$NAME,g ; s, at PWD@,$(REAL_PWD),g" \
	# irgendwie $< statt $$FILE oder so:
	$< > $@

Das "for" müsste so das Make über Abhängigkeiten machen. Wenn man %.tmp
noch als .SECONDARY erlaubt, wird es nicht gelöscht. Dann macht die
Konstruktion immer nur die .tmps, die wirklich gebraucht werden, weil
die .src geändert sind.

Kann aber sein, dass das falsch ist. Bestimmt lohnt das hier natürlich
eh nicht. Höchstens aus Spass an der Freud :)

> > Diese tollen ant "tasks" sind IMHO eine Krankheit. Es gibt eine jar und
> > ein unjar task. Gut, make kommt mit Regeln, die viele Ausgaben erzeugen
> > auch nicht sooo einfach klar (bzw. der Mensch, der es nutzt nicht ;)),
> > aber es geht.
> 
> Man kann es mit ein wenig Mühe stark verbessern. Schade, dass es
> automake noch nicht kann. 

Was, jar? Kann es:

data_DATA=myfile.jar
myfile.jar: compileSrc
	$(JAR) cf $@ -C $(CLASSDEST) com;
	$(JARSIGNER_CMD) $@ myself

geht fast genauso auch für "jar t" :-)

Leider nicht unter native Win oder so, da ist ant besser.

> Das Makefile vom Linux-Kernel ist ein sehr schönes Beispiel dafür.
> 
> Seit ich das gesehen habe, bemühe ich mich ebenfalls, in Makefiles und
> Shell-Scripten für eine übersichtliche Ausgabe zu sorgen. Er bei
> wirklichen Fehlern braucht man Details.

Ja, da helfen aber auch Tools. vim z.B. kann make/gcc Fehler schön
parsen (leider zeigt er mir immer nur die erste Fehlerzeile an, weiss
nicht, wie man das korrigiert). Manchmal benutze ich auch einfache
Tools, die z.B. je nach Makeebene oder so mit whitespace einrücken oder
so.

> > > > > In Subversion kannst du mehrere Projekte in einem Repository
> > > > > haben, und dann geht das.
> > > > 
> > > > Ich will ja ein Projekt mit mehreren Repositories haben. Nicht
> > > > paar Unterverzeichnisse. Das das geht ist ja wohl
> > > > selbstverständlich. (CVS kann das auch alles).
> > > 
> > > Wieso? Wo ist das Problem? Wo ist der Unterschied?
> > 
> > Der Unterschied ist, dass ich anfangs ja noch gar nicht weiss, aus
> > welchen Repos ich Module benutzen möchte. Die Repos wissen (u.U.)
> > nichts von einandern.
> 
> Kannst du ein konkretes Beispiel geben? Ich sehe immer noch nicht, was
> der Sinn des ganzen ist.
> 
> Wenn ich ein Modul habe, das woanders gepflegt wird, dann packe ich es
> doch in ein Unterverzeichnis, sauber vom Rest getrennt, und lasse es
> dort in seiner eigenen Versionskontrolle. Es könnte sogar eine völlig
> andere Versionskontrolle als das eigentliche Projekt verwenden.

Ja, natürlich Unterverzeichnis etc.

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, weiss ich aber nicht.

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

> > > Egal, ob ganzes Repository oder Unterverzeichnis: in Subversion
> > > ist das Auschecken dafür ein und der selbe Befehl. 
> > 
> > Ja klar, wie auch in CVS muss ich natürlich einmal pro Repo ein befehl
> > verwenden, klar, das SVN muss ja die URL gesagt bekommen etc.
> > 
> > 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 '.'

steffen at hostname:/tmp/steffen_exp/projectroot/ # cd modul1
steffen at hostname:/tmp/steffen_exp/projectroot/modul1 # svn up
svn: Failed to .................. oooopppppppppssss
(na gut, gibt gerade anderen Fehler, aber es macht immerhin was :-))

> > Atomares einchecken über mehrere repos kann ich mir jedenfalls nicht
> > vorstellen. Wie auch immer. Hab ich nie so gebraucht.
> 
> Wozu auch? Ich würde die nacheinander committen, schon allein deshalb,
> weil das Modul wahrscheinlich ne andere Log-Message als der Rest haben
> würde.

Ja, auch ein Problem mit den Messages, klar, aber "nacheinander
committen" ist gerade nicht atomar! 

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

:-)

> > Notfalls branch.
> > Aber die sind meiner Meinung naach mit SVN eher nerviger zu benutzen,
> > finde ich. Gerade, wenn man mal ein File wechseln will, weil man da mit
> > switch-super-long-URL hantieren soll. Na ja, vielleicht hab ich es nur
> > noch nicht verstanden.
> 
> Es ist wirklich etwas nervig, aber die langen URLs brauchst du nicht
> unbedingt.
> 
> In Mercurial ist das aber sowieso eleganter gelöst:
> 1 Repository = 1 Arbeitsverzeichnis = 1 Branch.
> Jede Kopie ist ein potentieller Branch. Merging gehört zur Tagesordnung,
> ist aber sehr schmerzfrei.
> 
> 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").

> GIT hingegen ist wirklich darauf getrimmt, mehrere Branches in einem
> Repository=Arbeitsverzeichnis zu halten. 

Bei uns verwenden wir gern project/branch/... also:

project/trunk/modul1
project/trunk/modul2, ...
project/Branch-1_0_0-Fixes/modul1
project/Branch-1_0_0-Fixes/modul2, ...
project/Branch-1_2_0-Fixes/modul1
project/Branch-1_2_0-Fixes/modul2, ...

Kann man sich aber herrlich bei verhauen :-) Aber das kann man immer,
wenn man durcheinander kommt.

> > > Will man die Repositories auf vielen verschiedenen Servern haben,
> > > sieht das natürlich anders aus. Dann verstehe ich aber nicht, wieso
> > > man dann dazwischen mergen sollte. Auf welcher Grundlage? Wie kommt es
> > > überhaupt, dass Daten über mehrere Repositories hinweg dupliziert
> > > werden?
> > 
> > Na, modul1 liegt auf repo1 (vielleicht ist das 5 Jahre alt und 4 nicht
> > mehr benutzt worden), modul2 ist von jemand anders, anderes Land, repo2
> > usw. Dann gibts Server mit open source repo3 und NDC sourcen repo4 nur
> > intern erreichbar. Oder sowas.
> 
> Und an welcher Stelle musst du da zwischen verschiedenen Repositories
> mergen?

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

> > Beruflich haben wir so ein kleines "übersystem", was u.A. die
> > sourcen auscheckt (im Wesentlichen ein Script, was jeweils eine
> > konfigdatei benutzt) und irgendwann auch configure ausführt.
> 
> Was hat das mit dem Merging zu tun?

Nichts, es hat mit modul1 at repo1 und modul2 at repo2 usw zu tun. Wobei
soweit repo1 CVS und repo2 SVN sein könnte.

> > > Dein konrektes Beispiel würde mich mal interessieren, das du im
> > > Hinterkopf hat. Vielleicht bietet Subversion da ja was viel Eleganteres.
> > 
> > Also, mal was ganz blödes. Ich hab ein eigenes readline "rl2" auf Server
> > opensrv. Wird vom Framework benutzt, sei closed source aber nicht
> > geheim. Liegt auf server1. Der hat noch ein crypto.bin Repo mit
> > binaries. Bestimmte Entwickler (Integrator, ...) dürfen auch davon die
> > Sourcen benutzen, die kommen von secret1, ein besser gesicherter Server.
> > oder was auch immer. Haste ne Sandbox wie:
> > 
> > my_system/
> > my_system/readline2/...
> > my_system/framework/...
> > my_system/crypto.bin/...
> > statt .bin haben mache auch:
> > my_system/crypto/...
> > 
> > in my_system könnte jetzt ein Makefile liegen.
> > 
> > Macht das Sinn?
> 
> Ja, so würde ich das auch tun. (siehe oben)
> 
> Da musst du aber auch nicht zwischen verschiedenen Repositories mergen,
> oder?

nicht "zwischen", sondern "über". Ich möchte my_system komplett mergen.
Geht natürlich nicht, wenn readline2 CVS und framework SVN ist. Aber
geht, wenn alles CVS ist. Geht leider auch nicht, wenn alles SVN ist!

> > > > Aber wenn man keine Anforderungen hat, ist SVN sicher ok.
> > > 
> > > SVN erfüllt auch Anforderungen, die CVS nicht hat.
> > 
> > Ja, ich weiss. Es kann http und basiert auf XML/SOAP.
> 
> Subversion kann HTTP(S) + WebDAV.

Ist das gleiche, bloss ich hab die besseren Hype-Wörter benutzt, oder?

:)

Obwohl "WebDAV mit Web 2.0 Technologie" auch cool klingt. So richtig
nach "mach einen Bogen um mich".

> > > Ich starte dauernd mal was, für das ich ein SCM gebrauchen kann.
> > > Und wenn ich für das SCM kein extra zentrales Repository
> > > einrichten muss wie bei CVS und SVN, sondern das
> > > Arbeitsverzeichnis schon das Repository ist, dann ist das sehr
> > > angenehm.
> > 
> > mmm... und wenn das weg ist? Platte kaputt oder so? Zentral hat auch
> > Vorteile (besser für backup).
> 
> Wenn das Repository im Netz ist, ist das noch viel nerviger.  Davon
> abgesehen: Regelmäßige Backups tun's auch.

Ich mein, Backup ist einfach, wenn man "ein Verzeichnis" sichert und
"alles" hat. Bei CVS und SVN geht das. Bei anderen kriegt man es
hoffentlich irgendwie hin :)

> Bei CVS und Subversion war mein zentrales Repository von privaten
> Projekten immer lokal.

Hat den Vorteil, dass es vermutlich erreichbar ist...

> Selbst wenn ich das aufspalten würde, Repository aufm Server,
> Arbeitsverzeichnis bei mir zu Hause. Dann wäre das Risiko doch
> viel größer, weil ich ein Problem kreige, wenn auch nur eines
> der beiden stirbt.

Nee, sandbox kann sterben. Am besten schmeisst man die eh einmal in der
Woche oder im Monat weg.

> Nein, von Sicherheit würde ich erst dann reden, wenn ich *zwei*
> Rechner habe, auf denen *jeweils* alles drauf ist.

Ja, Repo-Server (Raid etc) und backup (das selbst auch redundant).

Na, da kann man nicht genug sichern, wie immer :)

oki,

Steffen

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