@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/overviewIch 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.