Siduction Forum
Siduction Forum => Experimental => Topic started by: agaida on 2011/04/19, 13:21:48
-
Hi,
vielleicht fällt noch jemandem was ein, was ich noch nicht bedacht habe - Ausgangslage:
Externes gemietetes Repo mit der Möglichkeit, svn, git und mercurial zu nutzen. Bisher fahre ich die Kombi rein git + trac für meine internen Entwicklungen und git-svn + trac für Webseiten.
Ich bin noch mal in mich gegangen, weil zwar svn im Handling durch das Auschecken von Subtrees innerhalb eines Repos gewisse Vorteile für mich brachte. Andererseits ist der erhöhte Speicherbedarf und die unterirdische Verarbeitungsgeschwindigkeit von Subversion ein echter Blocker.
Bei Git habe ich auf der Negativseite 2 Punkte stehen, die mich stören - keine native Windowsimplementation, ich bin auf msysgit angewiesen, als 2. Punkt die etwas merkwürdige Behandlung von leeren Verzeichnissen, die so nicht unbedingt zu meinen Favoriten gehört.
Aus diesem Grund würde ich als Alternative gerne auf mercurial aufsetzen. Spricht da irgendwas dagegen? Mir ist beim Vergleich der Features nichts aufgefallen, was ich gegenüber Git unbedingt vermissen würde, eigentlich alle Kritikpunkte sind weg, ich frage mich nur, ob ich irgendetwas richtig wesentliches übersehen habe, bevor ich mich an eine Migration machen, die samt Anpassungen in der Programmierung mehrere Tage dauern wird? Gibt es irgendeinen Blocker bei mercurial, den ich übersehen habe?
-
Da ist gerade eine hervorragende Mercurial hg Schau:
http://www.ibm.com/developerworks/aix/library/au-mercurial/index.html?ca=drs-
Soweit ich verstanden habe gegenüber git:
- besser unter Ms Win
- besseres auschecken von Subtrees
Aber:
- Mehr Festplattenplatz
-
Das mit dem mehr Platz kann ich bestätigen, aber noch nicht quantifizieren. Was bis jetzt aber von mir sehr feststellbar ist - Mercurial ist besser dokumentiert, was beim Stand der Dokumentation von git aber wirklich fast jedem unbeschriebenen Blatt Papier gelingt. Durch den größeren Hype um Git gibt es aber wesentlich mehr brauchbare Webquellen zum Thema. Dafür sind die Werkzeuge rund um hg in beklagenswertem Zustand, vor allem die fertig paketierten. aptitude search git vs. aptitude search hg.
Mercurial ist aufgrund der etwas geringeren Verbreitung bei Hostern nicht ganz so häufig zu finden wie git. Die Entwicklung rund ums Projekt ist ein wenig "nachlässig". Es scheint so, dass sich die Entwickler selbst genug sind. Es fehlt ein wenig die Ernsthaftigkeit. Das nehme ich übel. Die sind nicht verrückt genug, um vernünftige Arbeit in minimaler Zeit abzuliefern. Beleg dafür: Debian Bug report logs - #577560. und davor und danach. Die Buben haben einfach kein Interesse, wesentliche (für mich) Teile und extensions nach debian zu bringen. Funktioniert ja auch so. :evil:
Da ist git wesentlich weiter. Ich habe jetzt ein Probem, was durch eine "Nachlässigkeit" wahrscheinlich einige Leute betrifft und davon abhält, hg einzusetzen. Ich habe recht große Subversion-Repositories, die nach hg sollen. Mit hgsvn keine Chance, das rechnet Tage und Wochen. Mein Workaround: Erstellung eines Archivs mit git-svn, konvertierung von git nach mercurial als schnellste und beste Variante. hgsubversion würde helfen, müsste ich aber am Paketmanagement vorbei machen oder "grade mal" zum Paket machen. Auch nicht das große Problem, aber ich hab lieber was Fertiges, gut Funktionierendes.
Ist das Zeug erst mal in Mercurial, ist es geil. Die Unterstützung für den Nicht-Nerd unter Linux und Windows ist wesentlich besser, da ich unter git nur mit dem Tafelgeschirr gearbeitet habe, habe ich alles, was ich brauche. Ich bin nie unter die Prozellan-Ebene gegangen. TortoiseHg mach eine bis jetzt sehr guten Eindruck, sogar bcompare wurde in funktionierend eingebunden. In Linux und Windows. Das macht mich zum Beispiel wieder glücklich. Mit meld als 2. Chance hab ich das noch nicht probiert.
Insgesamt wirkt alles ein wenig aufgeräumter und weniger in die Breite. Durch die Beschränkung auf weniger Funktionen kann ich auch weniger falsch machen. Subtrees auschecken habe ich noch nichts von gelesen, da ist alles besser als git, das kann das nämlich gar nicht. Soll es aber auch nicht. Was hochgradig interessant ist -die Impementation in python. Damit ergeben sich vollkommen neue Möglichkeiten für mich. Ich muss nur noch die Sprache lernen.
-
Jetzt habe ich auch ein paar Zahlen vorliegen, so stellt sich mein Testprojekt (lebendes Repo in aktiver Entwicklung dar):
gcom-websites - Settings
gcom-websites / svn / 231 MB / Last Commit: 13 Mar 2011 10:04
Alle Webseiteb g-com.eu
gcom-websites-git - Settings
gcom-websites-git / git / 156.8 MB / Last Commit: 13 Mar 2011 10:04
das selbe repo in git
gcom-websites-hg - Settings
gcom-websites-hg / hg / 372.5 MB / Last Commit: 13 Mar 2011 10:04
Meine Seiten in mercurial
Das hat mich dann doch ein wenig überrascht. Zugegebenerweise stört mich das mit dem Platz schon ein wenig, aber da ich in diesem Projekte kaum an die Kritikpunke von Git komme, wird es wohl oder übel Git werden. Andererseits kosten zusätzliche 1G $12 im Jahr bei repositoryhosting. Das sollte für eine aktive closed-Entwicklung auch nicht dass große Problem sein.
Clientseitig mutiert das dann zu:
1,4G ./svn-co/trunk
40K ./svn-co/.svn
1,4G ./svn-co
514M ./git-test/trunk
151M ./git-test/.git
664M ./git-test
513M ./hg-test/trunk
758M ./hg-test/.hg
1,3G ./hg-test
516M ./svn-export/trunk
516M ./svn-export
Was allerdings grausam war - das Hochladen der Quelldaten in Mercurial dauerte auch wesentlich länger im Vergleich zu Git. Das nächste Kriterium wird die Verarbeitungsgeschwindigkeit, sprich die Trac-Anbindung im Vergleich der Kontrahenten. Etwas positives hat die ganze Geschichte aber doch, mein offenes Zeug kommt nach bitbucket, das macht erst mal einen wirklich guten Eindruck und hat auch in freien Projekten unbegrenzt Plattenplatz. Dann darf auch das Repo gern ein paar Byte größer sein.
Der obligatorische Griff in die braune Masse blieb natürlich nicht aus. Hätte man auch durch Handbuchlesen in Erfahrung bringen können, mercurial unterstützt auch keine leeren Verzeichnisse. Der alte, aber bewährte Griff zu Dummy-Dateien ist also auch hier notwendig. Es bietet sich, als Gemeinsamkeit mit git an, die Datei .gitignore respektiere .hgignore zu missbrauchen, die könnte man wenigstens irgendwann noch mal sinnvoll gebrauchen.
Mist, eigentlich wollte ich doch nur meine Quellen ordentlich hosten...
-
Die Unterstützung für den Nicht-Nerd unter Linux und Windows ist wesentlich besser...
Mal 'ne dumme Frage so ganz nebenbei. Welcher Nicht-Nerd braucht denn Versionsverwaltungen für Quellcode? :roll:
Ganz abgesehen davon, funktioniert git, auch für einen Anfänger wie mich, nicht nur unter Windows unspektakulär einfach!
-
Gegenfrage 1: Wer sprach von Quelltext?
Gegenfrage 2: Schon mal ein Wiki aktiv benutzt? So richtig mit selbst reinschreiben. Da könnte man sehen, dass da Versionen mitgepflegt werden.
So was habe ich mir im gestalterischen Bereich (Layout, Satz, Content - Prospekte, Visitenkarten, Werbung, Webshop etc) immer gewünscht. Ich ändere was und kann schauen, was ich wann geändert habe. Oder z.B. Verträge etc. Das wird im allgemeinen recht gut angenommen. Voraussetzung dafür ist, dass mich das als Benutzer nicht über Gebühr behindert. Du musst mal sehen, wie elektrisch einige Leute werden, wenn die die Möglichkeiten sehen - vorausgesetzt, das geht primitiv einfach.
-
Den Sebstversuch, einen Kernel mit hg zu verwalten, ist kläglich gescheitert. 600M git pusteten sich mal ganz rasch auf mehrere G hg auf. Nach 3 Stunden hab ich dann die Übertragung abgebrochen. Da ist git doch irgendwie geeigneter.
Der Rest bleibt auch auf Git. Wie schon angemerkt wurde - Git geht auch unter Windows gar nicht so schlecht. Trotzdem wollte ich eingentlich auf msysgit verzichten. Pech (oder Glück) gehabt. Es geht doch nicht über ausführliche Tests.
-
Klar, git ist eindeutig begrenzt für Kernelentwicklung von Linus Thorwalds konzipiert worden. Und weil es begrenzt ist, können die minimierten Verwaltungsbytes schneller im Internet übertragen werden.
Wenn eine Versionsverwaltung mehr Verwaltungskram speichert, müsste sie auch entsprechend mehr Features können (subtrees), wenn sie nicht einfach nur dumm konzipiert wurde. Aber, dass hg auch keine leeren Verzeichnissse kann, ist ja echt traurig: Für Nicht-Entwicklungszwecke (die Beispiele, die Du oben ansprichst) brauch man einfach leere Verzeichnisse, und es ist Unbedarften der Sinn einer Datei ".gitignore" schwer zu erklären. Bist Du Dir sicher, dass es keine Option bei hg dafür gibt (git kann es definitiv nicht) ?? Svn kann es doch auch ...
-
http://hg.intevation.org/mercurial/crew/rev/b98d7ffa5c5b
Da hast Du die Messages. Einiges andere ist möglich mit Klimmzügen. Besonders tragisch empfinde ich nicht die Datenmenge, sondern dass da irgendwie recht wenig Kompression bei der Übertragung passiert. Ob dass an https lag und ob es mit ssh anders wäre, hab ich nicht mehr geprüft. Git ist da irgendwie cleverer aufgebaut. Das mit den leeren Verzeichnissen ist wohl alte Schule, ich erinnere mich daran, dass ich solch einem Mist zusammen mit einem Kollegen einige Zeit in Borland Delphi, C und C++ hinterherdebuggt habe. Hat insgesamt nur 4 voll fakturierte Manntage gedauert ;) Ist halt ein philosophisches Problem. Auch eine leere Menge ist eine Menge mit der Anzahl Elemente 0. Und diese Menge ist existent, abzählbar und somit in der Programmierung zu beachten. Einige Leute sehen das auch so wie ich, baazar soll das können. Das ist aber das geringste Problem. auch SVN hat seine Daseinsbereichtigung, die sich mir zwar nur sehr schwer erschließt, aber was solls.
Um das Problem des partial checkouts zu umgehen kann man natürlich in git auf die subs gehen, dass funktioniert inzwischen ganz gut, in hg tauchen immer wieder die Begriffe nested oder forrest auf. Da die Abhandlung eines partial checkouts aber nicht ganz trivial ist, wird es wohl auf reines ziehen ohne die Möglichkeit zu commiten hinauslaufen. Datenaustausch via patch ist ja auch was Feines. Inzwischen bin ich in der Theorie auch soweit, dass ich einen klassischen Export hinbekomme, mit den selben Einschränkungen bezüglich der Commits - auf Deutsch Dummsinn.
Torwalds hat das übrigens nicht nur für die Kernelentwicklung geschrieben, sondern als eine Art generelles versionierendes Dateisystem. Der Typ ist irgendwo einfach nur genial. Das Problem mit den Verzeichnissen ist seit Jahren bekannt, es findet sich nur keiner, der das implementiert. Hab ich gestern noch in einer Diskussion zum Thema gelesen, Issuenummer hab ich mir natürlich nicht gemerkt.
Sei es wie es ist, trotzdem finde ich mercurial im lokalen Netz gar nicht schlecht. Auf jeden Fall haben die Buben bei Bitbucket da eine schicke Oberfläche rumgebaut, die was hermacht. Wenn das wirklich Jira ist, lerne ich eventuell irgendwann mal, wie man einen Tomcat-Server aufsetzt. Bis dahin wird es wohl Redmine (Chiliproject) werden, dass ich von Tag zu Tag besser finde. Das werde ich aber garantiert nicht übers Knie brechen, Trac ist ja, vernünftig eingerichtet, auch recht mächtig. Und ich hab den großen Vorteil, dass ich von dieser ganzen Thematik keinen blassen Schimmer habe, also da vollkommen unvoreingenommen rangehen kann. Python oder ruby höhren sich auf jeden Fall erotischer an als Java.
-
Meines wissens nutzt Mozilla Corp. mercurial.
Die Ansicht das ein leeres Verzeichnis etwas ist teile ich übrigens nicht. Für mich ist auch ein Verzeichnis nichts. Um mathematisch zu bleiben: Wie ein Punkt - zwar gut zu beschreiben, aber effektiv nicht vorhanden da keine Ausdehnung. Verzeichnisse bilden eine Gruppierung für Dateien die den Inhalt tragen von denen es unterschiedliche Versionen gibt. Welchen Inhalt tragen den Verzeichnisse…?
(Zitate des Tages: "Ich stimme mit der Mathematik nicht überein. Ich meine, daß die Summe von Nullen eine gefährliche Zahl ist." ~ Stanislaw Jerzy Lec)
bzr hast du selbst schon erwähnt, sonst hätte ich mich gewundert, dass das nicht vorkommt.
An deinen Größentests kann irgendwas nicht stimmen. Es widerspricht dem Sinne des dezentralen VCS es in Server und Client zu unterscheiden -- vor allem wenn man dabei signifikante Größenunterschiede beobachten will - immerhin ist jeder Checkout vollständig…
Was hg forest betrifft so ist das meineswissens "nur" eine simple Verwaltung von unterschiedlichen Bäumen (=Projekten) innerhalb eines Überverzeichnisses als wald/baumA wald/baumB wald/baumC und du kannst in wald deine pulls durchführen und die Bäume werden dann gepulled. Sowas sollte es auch für git geben…
bitbucket für git heißt übrigens github und ist wohl das ältere von beiden…
Und trac bietet auch hg-Plugins an…
bezüglich: #577560 - ich verstehe deinen Zorn nicht. Es hat sich bisher keiner gefunden, der das paketieren möchte. So what? Du möchest es ja scheinbar auch nicht tun, obwohl du es ja scheinbar brauchen kannst was ja jetzt nicht gerade bei vielen der Fall ist…
(das Problem an den Konvertern ist ja auch: Man braucht das einmal - und dann?)
-
Um mathematisch zu bleiben: Wie ein Punkt - zwar gut zu beschreiben, aber effektiv nicht vorhanden da keine Ausdehnung.
Wenn ein Punkt effektiv nicht vorhanden wäre weil er "keine Ausdehnung" hat würde man ihn dann als Punkt wahrnehmen?
Selbst schwarze Löcher sind vorhanden, obwohl man sie nicht wahrnehmen kann, nur ihre Auswirkungen.
-
Oh je. Ein mathematischer Punkt (der in der Tat nicht wahrnehmbar ist) ist ein recht schlechter Vergleich zu leeren Ordnern. Aber egal.
Leere Ordnern können dazu dienen:
- beim Aufbau eine Struktur zu geben bzw. einen Rahmen für zukünftige Änderungen zu geben
- Informationen über den Ordnernamen (durchaus üblich) zu übertragen
Ein schwarzes Loch ist übrigens kein Punkt, sondern - so existent - etwas Kugelartiges
-
@gerd: man könnte sagen, schwarze Löcher haben etwas sehr anziehendes.
Als Strukturierungspunkt: Wenn das Verzeichnis für die Strukturierung so wichtig ist, dann sollte es auch eine README enthalten. Dann it es nicht mehr leer. Sonstige benötigte Verzeichnisse hat die Programmierung bei Bedarf anzulegen, die müssen nicht unbedingt im Repository enthalten sein. Stil und Ansichtssachen. Für definitive Strukturmittel wie die Ablage temporärer Dateien biten sich wirklich die .xyzignore-Dateien an.
@donkult: Zwiespältig. Siehe 0 und null.
Zur Paketierung: Es ist übrigens nicht so, dass nicht schon mal der Versuch unternommen worden wäre mit den Paketen. Dem von mir angeführten Fehler ging ja etwas voran. Es gab durchaus Bestrebungen, debian-Pakete bereitzustellen.
https://bitbucket.org/yuja/hgsubversion-deb/overview
Ich werde das garantiert nich an- und packen. Warum sollte ich ein Paket packen, was ich wahrscheinlich nie benutzen werde? Der Zustand der Programmierung ist halt noch nicht so, dass es problemlos möglich wäre. Wäre der Rest von mercurial brauchbarer, könnte man sich das ans Bein binden. Ist es aber nicht. So ist es nur ein weiterer negativer Punkt im direkten Vergleich. Git ist einfach erwachsener.
Nach den Tests von gestern werde ich meine umfangreicheren Pakete weiter mit git verwalten. Für kleinere Sachen werde ich mir in aller Ruhe mal bitbucket und vor allem
JIRA zu Gemüte führen. Eine Kombi von Jira und Git sehe ich auch sehr positiv - wenn ich je in die Verlegenheit komme, so was zu brauchen, habe ich dann einen fundierten Ansatz.
github und bitbucket kann man imho so miteinander nicht vergleichen. Meine Ansicht. Da ich github für meinen aptosid-Kernel nutze, weiss ich eigentlich recht genau, was mir daran auf den Sack geht. Es ist eigentlich wie immer: eine Kombination von beiden Sachen wäre für mich das Optimum. Was ich an jira und trac so toll finde, kommt bei vielen anderen nicht so gut an. Die exzellenten Trackingmöglichkeiten, eingebettet in eine tolle Oberfläche.
Was die Größenunterschiede betrifft, kannst Du mir ruhig glauben. Ich sehe da auch keine signifikanten Unterschiede in meinen Zahlen, die sich nicht erklären lassen. Einer der Hauptkritikpunkte an hg ist doch die doppelte Ablage der Objekte. Warum das so sein muss, hab ich nicht verstanden, suche ich aber gern noch mal raus.
Auf jeden Fall sollten man unterscheiden - die Unterscheidung ist bei git die eines vollstädigen Clones gegenüber --bare. Die selbe Sache in unterschiedlicher Verpackung. Das liegt aber auch in der Natur der Sache.
Das, was Du als so simpel ansiehst, ist es nicht: subrepos haben bei git ewig nicht wirklich funktioniert, die nested Sachen habe ich mir nicht genauer angesehen. nested REpositories ist nicht einfach das Zusammenprömpeln von Verzeichnissen, sonst wäre es ja noch erstaunlicher, dass es da überhaupt Probleme geben sollte.
-
ich selber habe jetzt hgsubversion nicht probiert, aber vllt. ist es mit einem einfach hg clone auch einfach getan, weswegen auch niemmensch findet das zu paketieren was so einfach kurz istalleirt werden kann ;) Natürlich ist ein deb schöner;)
Aber nachdem ich jetzt monatelang an einem Rechner arbeiten musste, bei dem ich keine Admin rechte hatte habe ich zu schätzen gelernt als benutzer solche Sachen im home-dir platzieren zu können.
trac/mecurial rennt bei mir schon seit zwei Jahren ohne Fehler durch...
achso vllt. noch zwei screencasts(englisch) der pycon2010, ein bischen geschichte zu git/hg und unterschiede & gemeinsamkeiten:
"Modern version control: Mercurial internals (#113)": http://us.pycon.org/2010/conference/schedule/event/132/
"Hg and Git : Can't we all just get along? (#154)": http://us.pycon.org/2010/conference/schedule/event/137/
-
ich selber habe jetzt hgsubversion nicht probiert, aber vllt. ist es mit einem einfach hg clone auch einfach getan, weswegen auch niemmensch findet das zu paketieren was so einfach kurz istalleirt werden kann ;) Natürlich ist ein deb schöner;)
hgsubversion wäre die Voraussetzung für hg clone ...
Der kürzeste Weg zwischen 2 Punkten ist der Umweg:
in /etc/mercurial/hgrc.d/hgext.rc
# Extensions included in Mercurial listed in alphabetical order
#[extensions]
#hgext.git =
-->
# Extensions included in Mercurial listed in alphabetical order
[extensions]
hgext.git =
Damit ist interoperabilität mit git hergestellt. Da müsste meiner Meinung nach jetzt ein hgsubversion rein.
git svn clone https://server.de/meinrepo/svn/verzeichnis mein-checkout-git
hg clone mein-checkout-git mein-checkout-hg
nano mein-checkoupt-hg/.hg/hgrc
Hier dann noch auf den hg-server umbiegen und pushen. Ich habe ab sofort ein hg-Repository mit kompletter Historie. Leider ist das eine Einbahnstraße.
hgsubversion könnte dieses Manko lösen, wenn es denn stabil wäre. Ich habe jetzt eine Zeit lang mit git-svn gearbeitet, da war gegenüber reinem svn schon ein Fortschritt, wie man aber im obrigen Block sieht, müsste man eigentlich mit dem Klammerbeutel gepuert worden sein, wenn man nicht komplett auf hg umstellen möchte. Die Idee eines zentralen svn mit vorgeschaltetem git-svn wurde ja auch bei KDE längere Zeit erfolgreich praktiziert.
Bei meinen kleineren Sachen ist svn jetzt erfolgreich gestorben und durch hg ersetzt worden. git hätte es auch getan, aber irgendwie gefällt mir mercurial.
Der Kernel liegt weiterhin bei github und wird da auch bleiben. Die Seiten stelle ich von svn/git-svn auf reines git um, es muss zwar ein wenig umstrukturiert werden, aber was solls. Im Großen und Ganzen war die ganze Sache ein voller Erfolg. Jetzt muss nur noch Chili oder Trac an den Start kommen, wobei mir Trac zwar gut gefällt, so rein vom Gefühl aber Chili eventuell den etwas weiteren und auf Dauer besseren Umfang hat. Da ist die Entscheidung ganz einfach - Ich setze beides auf und wir nutzen dann einfach nach ausführlichen Tests das, was besser gefällt und womit alle besser klar kommen. Je nach Lust und Laune ist auch Jira + Wiki noch nicht aus dem Rennen, was da stört ist im Moment nur Tomcat.
-
Habe hier https://bbs.archlinux.org/viewtopic.php?pid=918745 vielleicht noch was zum Thema "leere Verzeichnisse" gefunden.
-
Die Ansicht das ein leeres Verzeichnis etwas ist teile ich übrigens nicht. Für mich ist auch ein Verzeichnis nichts. Um mathematisch zu bleiben: Wie ein Punkt - zwar gut zu beschreiben, aber effektiv nicht vorhanden da keine Ausdehnung.
Imaginäre Zahlen (Wurzel aus minus Zwei) sind in Deiner Realität dann wohl auch nicht vorhanden? Aber ich habe gerade neulich irgendwo gelesen, dass man mit Hilfe der imaginären Zahlenmathematik die Wahrscheinlichkeit bestimmter Quanteneffekte, die tatsächlich in der Realität existieren, berechnen kann (leider vergessen, welcher Effekt). Quanteneffekte in der Physik sind nichts abstruses, hergeholtes: Ohne sie würden wir alle nicht existieren: Die Stabilität vieler Atome ist ohne den Quanteneffekt der Elektronen nicht vorstellbar. Nur weil Elektronen an vielen Stellen quantenmechanisch gleichzeitig sein können, fliegt uns unsere Welt nicht um die Ohren.
Eigentlich ist auch die einfachste Mathematik vollkommen imaginär: Ich habe in der Realität noch nirgendwo 1+1=2 beobachten können. Wenn du zB zwei Äpfel nimmst, sind sie nur vom abstrakten/imaginären Begriff Apfel her gleich. Sogar das UrKilo in Paris hat Abweichungen, die sich in 80 Milliaden Jahren durch die Halbwertzeit aller existierenden Materie noch verstärken. Schon von der Zeitachse her, die ja in der Realität, aber nicht in der Mathematik, dargestellt werden muss, kann es also nie 1+1=2 geben.
Verzeichnisse bilden eine Gruppierung für Dateien die den Inhalt tragen von denen es unterschiedliche Versionen gibt. Welchen Inhalt tragen den Verzeichnisse…?
Den Informationsgehalt, dass es eine Gruppierung ist, die auf bestimmte Weise mit anderen Gruppierungen verschachtelt sein soll. Ausserdem können Verzeichnisse Schreibberechtigungen tragen/verweigern. (Wie oft ist Dir schon ein Installationsscript gecrasht, weil es das angenommene Verzeichnis nicht gibt, es also keine Berechtigung gibt, etwas zu hinterlegen). Wenn Du das alles nicht als wesentlichen Inhalt sähest, verständest Du wohl nicht soviel von Linux :)
-
Ich verstehe auch nix von Linux. Ich verstehe vielleicht einzelne Teile, aber alles? Es versteht ja auch keiner die Welt oder die Frauen… ;)
Und ja in meiner ℝealität gibt es keine Wurzeln aus negativen Zahlen. Dafür muss es schon ℂomplex werden. :)
Was ich aber nicht verstehe ist was jetzt das gute ⅈ hier verloren hat. Mir ist bewusst, dass in ℂ die Wurzel aus -1 = ⅈ ist, kommt eben auf das Bezugssystem an. Die Sache ist aber: So eine komplexe Zahl hat ja einen Wert und stellt etwas da. Ein Punkt hat keinen Wert, er ist eine "Ortangabe" genau wie ein Verzeichnis. Daher gibt es ja auch Linien zwischen zwei Punkten und Punkte auf Linien, aber egal wie viele Punkte ich nehme, es wird doch nie eine Linie daraus weil ich nicht alle Punkte aufzählen kann durch die die Linie geht (immer vorausgesetzt wir unterhalten uns über ℝeale Linien, nicht über ℕatürlich, weil die wären ja abzählbar). Und in einem VCS in dem ich Dateien verwalte muss man sich eben spezielle Tricks einfallen lassen um bestimmte leere Verzeichnisse sichtbar zu machen (weil leere Verzeichnisse gibt es unendlich viele) genauso wie ich mir mit einem Punkt einen Wert markiere unter den vielen vielen Werten die möglich wären… (alle anderen Orte im Koordinatensystem sind ja auch "Punkte", die interessieren mich nur nicht).
Oder kurz und bündig gefragt: Welche unterschiedlichen Versionen kann ein Verzeichnis den durchlaufen ohne Dateien zu beinhalten? Richtig keine, den wenn man es umbenennt ist es ja nicht mehr das selbe Verzeichnis, ein mkdir würde reichen, was man dabei erhalten will ist ja der Inhalt - wenn aber keiner da ist…
Zugriffrechte sind übrigens nicht gerade der Freund eines VCSes - vor allem wenns portabel sein soll, aber das ist ein anderes Thema…
P.S.: Und mir schlagen keine Installationsscripte fehl, dpkg legt die für mich an (was übrigens auch Tricks benötigt um leere Verzeichnisse anzulegen). :)
P.P.S.: "… schwarze Löcher haben etwas sehr anziehendes." :lol:
-
Auf das Argument, 'dpkg legt das für mich an' habe ich gewartet. und gehofft. Dann sind wir uns einig. An dieser Stelle kann dann auch gleich noch mal die übliche Warnung kommen, dass eine Versionsverwaltung eine Datensicherung nicht ersetzen kann. Der würde ich es Übelnehmen, wenn sie die Verzeichnisstrukturen nicht ordentlich und vollständig abbildet.
Ein Repository ist auch kein Ersatz für eine ordentliche Installationsroutine und wenn man auf solche Sachen Wert legt, könnte auch hier ein Hook helfen, der nach dem Checkout eines Repos noch ein Post-checkout-script abarbeitet.
Ich hab noch einen zum Thema gefunden: mercurial kann zwar keine leeren Verzeichnisse, aber man kann ja einen Hook setzen, der einem eine .hgignore in die leeren Verzeichnisse schreibt. Dann steht eine leere Datei in einem sonst leeren Verzeichnis. Muhaha ;)
Wer noch richtig Spass in den Backen hat und sich mal einen wirklich blöden Gesichtsausdruck anschauen will, dem sein dieser Selbstversuch empfohlen:
Man nehme ein leeres hg-repo und lege darin ein Verzeichnis an. Man wechsele in das Verzeichnis und lege 2 Dateien (z.B. mit touch, vi oder nano) an. Dann ein Commit.
test2$ ls -a
. .. a1 a2 .hg
test2$ mkdir test3
test2$ mv a1 a2 test3; ls -a
. .. .hg test3
test2$ hg add
Füge test3/a1 hinzu
Füge test3/a2 hinzu
test2$ hg commit
test3/a1
test3/a2
Änderungssatz 1 erzeugt:66e0be5705a3
test2$ cd test3; hg mv * ..
Verschiebe a1 nach ../a1
Verschiebe a2 nach ../a2
test2$ cd ..; ls -a
. .. a1 a2 .hg
test2$ hg add; hg commit -m 'willi'
a1
a2
Änderungssatz 2 erzeugt:f6737b770cb4
An dieser Stelle hatte ich leichten Schaum vor dem Mund und hab abgebrochen. Wzt ist mein test3. Auch wenn das eventuell nicht mit versioniert wird, das geht ein wenig zu weit, da kann ich nicht mehr drüber lachen. Obwohl es eigentlich ja nur konsequent ist ...
Bitte jetzt einen Blick in den Spiegel nicht vergessen ;)
-
Für die Instanz, die Verzeichnisse anlegen darf, gibt es unendlich viele Verzeichnisse, für eine Instanz, die keine Verzeichnisse anlegen kann (zB touch), gibt es nur die endliche Menge real existierender, auch leerer Verzeichnisse, die es mit den richtigen Berechtigungen erlauben, Dateien anzulegen.
Die unterschiedlichen Versionen von Verzeichnissen müssten die unterschiedlichen Unterverzeichnisse und ihre Berechtigungen angeben. Integriert in git müsste auf diese Weise nur ein nicht leeres Verzeichnis Versionsdaten speichern: Immer der Parent speichert die relevanten Daten. Dann wäre ein solches VersionsConstrolSystem auch eine richtige Backup Lösung.
-
Quanteneffekte in der Physik sind nichts abstruses, hergeholtes: Ohne sie würden wir alle nicht existieren: Die Stabilität vieler Atome ist ohne den Quanteneffekt der Elektronen nicht vorstellbar. Nur weil Elektronen an vielen Stellen quantenmechanisch gleichzeitig sein können, fliegt uns unsere Welt nicht um die Ohren.
Wenn ich in der Schule aufgepasst habe besagt die Quantenmechanik doch, dass Atome, Elektronen und andere Quantenteilchen (Quarks & Co) sowohl Teilchen- als auch Welleneigenschaften besitzen. Ihre Zukunft ist unbestimmt und wenn man sie zum Zeitpunkt x misst ist das Ergebnis nicht präzise. Oder? Ist natürlich sehr abstrakt das in Relation zu leeren Verzeichnissen zu stellen.
-
Das so eventuell beschriebene Phänomen?? soll wahrscheinlich auf die Heisenbergsche Unschärferelation hinauslaufen - den Zusammenhang zu Dateien und Verzeichnissen kann ich da auch nicht nachvollziehen.
Was ich auch nicht nachvollziehen kann, ist die Diskussion pro- und kontra. Es wäre schön, vor allem im Hinblick der Beschreibung von git durch Linus als Bateisystem, wenn man leere Verzeichnisse speichern könnte. Das würde einem Dateisystem gut zu Gesicht stehen. ;) Bestimmten Argumentationen kann ich nicht ganz folgen. Ein Verzeichnis ändert sich nicht. Es existiert oder es existiert nicht. Das ist eigentlich ganz einfach. Nur dass diese eigentlich triviale Sache nicht ganz so trivial abzuhandeln ist - aber das wurde ja auch schon angesprochen.
Mal was offizielles dazu
https://git.wiki.kernel.org/index.php/GitFaq
Currently the design of the git index (staging area) only permits files to be listed, and nobody competent enough to make the change to allow empty directories has cared enough about this situation to remedy it.
Directories are added automatically when adding files inside them. That is, directories never have to be added to the repository, and are not tracked on their own.
You can say "git add <dir>" and it will add the files in there.
If you really need a directory to exist in checkouts you should create a file in it. .gitignore works well for this purpose (there is also a tool MarkEmptyDirs using the .NET framework which allows you to automate this task); you can leave it empty or fill in the names of files you expect to show up in the directory.
Wir können also in alle Ewigkeit debattieren, ob richtig oder falsch. Entweder einer von uns ist kompetent genug und implementiert es - dann muss nur noch der Rest der Entwickler überzeugt werden, dass die Implementation richtig, geil und ein must have ist und nichts kaputt macht. Dann wird das wahrscheinlich noch ein oder zwei Jahre getestet. Dann könnte dieses Feature in git erscheinen. Ich habe (leider oder zum Glück) die Voraussetzungen zu diesen Änderungen nicht. Ich bin dazu nicht kompetent genug, spreche kaum C und perl ist für mich eine unauflösbare Form der Kryptographie. Ich bleib dann mal bei .gitignore und vielleicht einem hüschen hook dazu.