Thread Source Code verwalten (30 answers)
Opened by tophoven at 2009-07-15 09:40

sid burn
 2009-07-20 19:21
#123419 #123419
User since
2006-03-29
1520 Artikel
BenutzerIn

user image
Quote
Datensicherheit im Programmdesign und Backups schließen sich nicht aus, sondern ergänzen sich. Ich mache ja auch Backups von Datenbanken, will aber trotzdem, dass die Datenbank ACID-Transaktionen kann.

Das was du ansprichst ACID-Transaktionen ist aber eine ganz andere Datensicherheit auf einen ganz anderen Level. Und wenn wir schon bei Datenbanken sind. Datenbanken selber speichern ebenfalls in einem eigenen Binärformat, und die abstraktion hier ist ähnlich hoch, daher man kann es mit eigenen Dateisystem vergleichen. So bieten die Datenbanken ja auch in der Regel an direkt mit RAW Devices zu kommunizieren was sogar die Performance erhöht da diese auch Caching etc. selber implementieren. Es kann hierbei sogar schädlich sein wenn man keine RAW Devices nutzt da sonst ein doppeltes Caching entsteht. Datenbank + Filesystem und dann z.B. ACID nicht mehr gewährleistet sein kann. Naja Git ist da aber noch weit von entfernt.

Ansonsten erhöht dir auch ACID nicht die Datensicherheit über die wir gesprochen haben. Gibt es ein defekt an den Binärdateien dann hast du ein problem.

Aber deswegen wirst du mir bestimmt gleich sagen das du deswegen auch keine Datenbank nutzt sondern alles schön in performante CSV Dateien auslagerst. ;) :p

Quote
Du kannst es gerne albern finden, dass ich Datensicherheit auf mehreren Ebenen haben will, aber ich sehe es eher so, dass ich da einfach höhere Anforderungen als Du habe.

So kann man albern natürlich auch umschreiben. ;)

Aber ansonsten finde ich es nicht albern das du höhere Datensicherheit haben möchtest. Ein Versionierungssystem ist nur einfach keine Software die Datensicherheit bringt, sondern Source Code Verwaltet und Versioniert.

Datensicherheit ist sicherlich ein gutes Thema. Ich finde es aber ein Trugschluß wenn man meint das man ein Versionierungssystem nutzt und man hat dann bereits Datensicherheit.

Wahrscheinlich habe ich höhere Anforderung an Datensicherheit als du, das ich ein Versionierungssystem nicht in der Kategorie "Datensicherheit" einstufe. ;)

Quote
Zur Geschwindigkeit habe ich gar nichts gesagt, da man darüber nicht vernünftig diskutieren kann, ohne Randbedingungen wie das verwendete Dateisystem und dessen Einstellungen genauer festzulegen und richtige Benchmarks zu machen.

Naja du hast von "effizenz" gesprochen. Was meintest du den dadrunter?

Ansonsten kann man auch über Sachen Diskutieren ohne über alles Benchmarks zu haben. Einen haufen kleine Dateien zu öffnen ist für ein betriebssystem auffendiger als eine einzelne Datei zu öffnen. Das liegt in der Natur des ganzen.

Quote
Der Speicherverbrauch mehrerer Repositories mit ähnlichem Inhalt ist aber definitiv höher, wenn jedes Repository die gesamte Versionsgeschichte als eine große Datei enthält, als wenn sich diese Repositories untereinander teilweise dieselben Daten, z.B. mittels Hardlinks, teilen.

Ja dann schon, nur warum sollte man mehrere Repositories einrichten?

Bei Mercurial? (weiß nicht ob es das war) weiß ich soweit das man sowas ähnliches wie bei Git die lokale branches nicht hat, und es darüber löst indem man das ganze repro clont.

Dann mag das sicherlich sinn ergeben. Aber dass muss man bei Git ja gar nicht erst tun.

Ansonsten ist es natürlich Datensicherheitstechnisch blöd wenn man hardlinks hat. Bei Git hat man immer neue Dateien und der ausfall einer datei reduziert sich. ;)

Quote
Ich denke, wir haben hier wohl etwas aneinander vorbeigeredet, da bei Git der Begriff Branch etwas anders verwendet wird als bei einigen anderen verteilten Versionskontrollsystemen. Ich bin es mehr gewohnt, dass ein Repository im wesentlichen identisch mit einem Branch ist und habe beim Schreiben nicht beachtet, dass Git ja pro Repository mehrere Branches speichern kann.

Was natürlich eine gute Designentscheidung ist, wenn andere Versionierungssysteme zwei unterschiedliche sachen "Reposiory" und "Branches" als das "gleiche" ansieht. ;)

Quote
Nun, das Speicherformat der Repositories ist auf jeden Fall eine Designentscheidung.

Oh sorry, in meinen Satz fehlt etwas es sollte eigentlich heißen.

"Was daran jetzt eine fehlerhafte Designentscheidung ist weiß ich nicht."

Also ich sehe schon was daran eine Designenstcheidung ist, aber nicht was daran Fehlerhaft ist. Es ist einfach nur "anders".

Quote
Einfach zwei Manpages git und git-lowlevel schreiben, damit der Überblick gewahrt bleibt und man nicht mit überflüssigen Informationen bombardiert wird, ist wohl zu schwer? ;-)

Damit du dann gleich danach wieder Meckern kannst warum die Hilfe in zig Manpages unterteilt ist? Und es ja total schwer ist nach infos zu suchen, da man zig manpages ständig öffnen muss?

Letztendlich wenn man möchte findet man immer etwas das man aussetzen kann. Mir gefällt die Font nicht. Die Schriftart ist nicht toll. Bei Mercurial nummerieren sich mit Dezimalen zahlen durch, woanders mit römischen zahlen... ;)

Quote
Genau deswegen hat mich die Manpage ja so genervt: Die Kommandos, die ich nicht durch Ausprobieren sofort gefunden hatte, fand ich im dortigen Datenwald auch erstmal nicht ;-)

Naja wie gesagt welcher Datenwald? Es gibt zwei Kategorien, einmal HIGH-LEVEL Kommandos und einmal LOW-LEVEL Kommandos. Suchst du ein HIGH-LEVEL Kommando scrollst du zu den HIGH-LEVEL Kommandos und gehst du Alphabetisch Sortierte liste durch.

Soll nicht beleidigend sein, aber wenn mir jemand sagt das er dazu nicht in der lage ist, und das ganze in zwei manpages unterteilt braucht anstatt in zwei Kategorien, da zweifle ich daran ob ich mit einem programmierer spreche da kommt es mir irgendwie vor als wenn ich mit jemanden von der Baustelle rede mit Bild zeitungs Niveau. ;)

Soll nicht beleidigend sein was ich schreibe, ich hoffe du siehst meine ironie/sarkasmus in das was ich schreibe. ;)

---

Aber unabhängig davon sprechen wir hier über dinge wo ich immer noch nicht sehe was für ein anfänger schwer sein soll. Die Sachen womit du Probleme hast sind z.B. Sachen weil du die anders gelernt hast von anderen Dezentralen versionierungssystemen.
Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de

View full thread Source Code verwalten