Ein Sparse-File ist eine Datei, deren tatsächliche (physikalische) Größe sich von der logischen erkannten Größe unterscheidet. Die angezeigte Größe kann sogar höher als der verfügbare Speicherplatz auf diesem Volume sein.
Sparse bedeutet so was wie "spärlich". Oft wird es in der Informatik benutzt um grosse Datenmengen mit viel redundante Information (z.B. sehr viele Nullen) platzsparend unterzubringen. Beispiele: sparse-files (wie NaSe oben beschrieben hat), spärliche mathematische Matrizen (z.B. diagonal, tri-diagonal), oder aber auch run-length-encoding (RLE).
Ist schon lustig, wie mit einem Mal Bewegung ins Spiel kommen kann. Mit einem Mal hat jeder Programmierer ein neues Patch-tool im Ärmel, das kleiner und schneller ist, als die anderen, und nebenbei noch den Urlaub plant und Kaffee kocht ... Naja, ich finds cool. Es braucht halt nur Stromstöße, damit OS wieder zeigt, was drin steckt.
Jup, sehe ich auch so. Open Source Entwicklungen brauchen einen Grund, einfach so passiert nicht viel. Aber wenn es einen guten Grund pinkt: BOOOMM und die Lösung ist da, bevor das Problem völlig erkannt wurde ;)
Ich bin gespannt wohin der Weg führt. Ich selbst nutze CVS, bin aber nicht sehr zufrieden. Ein gutes VCS wäre wirklich wunderbar, Subversion ist für mich auch nur CVS mit Addonds, das ist nicht wirklich eine große Verbesserung. In anbetracht der Zeit die Subversion schon entwickelt wird ist es eher enttäuschend.
Subversion wurde als CVS-Ersatz entworfen und erfüllt den Job sehr gut. Es erweitert CVS behutsam und vor allem an den Stellen, wo es bisher hakte. Aber es gibt ja noch weitere VCSse:
"Subversion wurde als CVS-Ersatz entworfen und erfüllt den Job sehr gut."
Ja, aber es ist leider auch kaum mehr, obwohl es auch viele sinnvolle Verbesserungen gibt, die andere VCS integrietr haben. Es ist doch recht funktionsarm, und nur im Vergleich mit CVS Leistungsfähig. Das heisst nicht das Subversion nichts taugt, ich habe mir davon aber mehr erhofft.
Subversion hat aber nicht nur die bekannten Vorteile bezüglich der Repositorybedienung gegenüber CVS, es hat noch weitere.
So liegt zum Beispiel der gesamte Clientcode in Form einer Shared Library vor, was die Entwicklung verschiedenster graphischer oder anderweitig spezialisierter Clients enorm erleichtert. Desweiteren ist Subversion im Gegensatz zu CVS eher eine erweiterungsfähige Plattform. Was auf dieser Basis möglich ist, zeigen zum Beispiel Projekte wie svk.
Wenn man dazu noch weiß, daß Subversion im Prinzip nichts als ein versioniertes Filesystem abbildet und die Details dahinter mittels einer API abkapselt, so ist zB irgendwann einmal ein Wechsel von der Berkeley DB hin zu SQL-Datenbanken denkbar und möglich.
Fazit: Subversion ist vor allem unter der Haube CVS deutlich überlegen, wer es nur auf die Bedienung des svn-Clients reduziert, muß sich nicht wundern, daß er nicht viele Neuerungen wahrnimmt.
Was ich an Subversion vor allem schätze, ist die Tatsache, dass Subversion Unterstützung für HTTP hat und man somit auch hinter einer Firewall Zugriff auf SVN-Repositories hat. Notfalls verwendet man wget -m -np http://svn.foobar.org/bla/ Mit cvs no chance.
Das ist alles schön und gut, aber wie du schon sagst: Das ist alles unter der Haube, und nützt mir als nutzer erstmal garnichts. Es sind sachen, die vieleicht mal wichtig sein könnten, aber für einen Entwickler aktuell nicht wichtig sind.
Und da sind zwar viele sinnvolle Veränderungen drinne, aber das Basisprinzip von CVS wurde ja bewusst für den Entwickler beibehalten. Und daher sind auch viele Funktionen nicht integriert, welche die "großen" VCS integriert haben. Ich habe gehofft das Subversion mit der Zeit weiter gehen würde. So bleibt es für mich ein aufgebohrtes CVS. Ob es intern ganz anders funktioniert ist mir ehrlich gesagt völlig gleich. ich muss mit dem arbeiten, was bei rauskommt
> das Basisprinzip von CVS wurde ja bewusst für den Entwickler beibehalten Das Basisprinzip... Du meinst die Syntax des SVN-Clients? Ja, die ist angelehnt. Was noch?
> So bleibt es für mich ein aufgebohrtes CVS Eben nicht, wie gesagt, schau Dir doch mal svk an! Na, weckt das schon eher Dein Interesse? Das ist eines dessen, worauf ich mit den Ausführungen über die internen Unterschiede Subversion vs. CVS hinaus wollte. Es steckt eben so viel mehr in Subversion, als man nach der Betrachtung des SVN-Clients glauben möchte.
"Du meinst die Syntax des SVN-Clients? Ja, die ist angelehnt. Was noch?"
Das gesamte arbeitne mit Subversion ist an CVS angelehnt. Das ist ja auch Sinn der Sache. Das es intern anders funktioniert ist mir, wie gesagt, relativ egal. Es gibt auch für CVS patches die einige Probleme lösen. Wie Subversion diese technisch löst ist mir nicht sonderlich wichtig.
Ich werde mir svk mal ansehen, es ist mir bisher unbekannt. Es klingt auf jeden fall schonmal ganz interessant.
> Das gesamte arbeitne mit Subversion ist an CVS angelehnt Und genau diese Erklärung ist mir ziemlich schwammig, deshalb hab ich die Frage extra so ausdrücklich gestellt. :)
Hast Du vielleicht noch was spezielleres, daß ich übersehen habe?
Ähem. Subversion ist ein exzellenter CVS-Ersatz ..
Wenn du mehr bzw.was anderes willst halte nach Monotone, Arch, Darcs, etc Ausschau. David Wheeler führte da mal ein paar Vergleiche durch: http://www.dwheeler.com/essays/scm.html
"Ähem. Subversion ist ein exzellenter CVS-Ersatz .."
Das habe ich nicht bestritten, sondern gesagt das es eben leider kaum mehr ist.
"Wenn du mehr bzw.was anderes willst halte nach Monotone, Arch, Darcs, etc Ausschau."
Die nützen mir nichts, da die Entwickler die ich Anleite keine nicht-Grafischen Clients mögen. Daher mögen sie z.B. Eclipse mit CVS. Das ist dort gut integriert. Subversion ist auch ganz gut integriert, wenn es auch noch etwas wackelig ist. Und da beginnt auch das Problem: Die anderen Clients scheinen über keine guten Frontends zu verfügen. Selbst CVS hat kaum gute Clients. WinCVS und LinCVS kann man IMHO in die tonne tretten. Viel zu umständig in der Bedienung, schlecht durchdacht usw.
Das ist natürlich vor allem mein Problem, da ich diese Systeme daher nicht nutzen kann. Aber darum habe ich auch meine Hoffnungen in Subversion gelegt, da sich dort schon früh zeigte das so manche Clients die CVS beherschen auch Subversion Support bekommen, da beide recht ähnlich sind (für den Entwickler)
Wenn ihr gute clients für Monotone und co. kennt, die mir unbekannt sind, oder gute Editoren die diese clients bereits perfekt integriert haben, immer raus damit. Ich würde mich freuen
Schmeiß die Entwickler raus. Eclipse ist der größte Junk, den es gibt... Wer als Entwickler nicht in der Lage ist, ein Versionskontrollsystem adäquat zu bedienen ohne irgendein krankes GUI-Frontend, hat den Job verfehlt und sollte schnellstmöglich wieder ans Fließband...
Ist wohl Ansichtsache, aber auch ich finde das eine gute GUI zu einem guten VCS dazugehört. Ein VCS ohne gut GUI ist für mich kaum halb so viel Wert. Abgesehen davon ist Eclipse selbst wirklich gut, die Modularität ist gut umgesetzt, die Bedienung logisch. Du musst es ja nicht mögen.
Danke für die URL, aber SmartCVS kenne ich schon :) SmartCVS ist auf jeden fall wesentlich besser als WinCVS und co. Aber leider immernoch fern ab der einfachen Bedienung
Was ist das Sparse?
Wozu wird es verwendet?
Wo kann man es erhalten?
Wie wendet man es an?
Danke
Ein Sparse-File ist eine Datei, deren tatsächliche (physikalische) Größe sich von der logischen erkannten Größe unterscheidet. Die angezeigte Größe kann sogar höher als der verfügbare Speicherplatz auf diesem Volume sein.
Anwendungsbeispiele?
Ist es auch außerhalb der Kernel Sourcen anwendbar?
Was für Fehler sucht es ?
Danke!
Naja, ich finds cool. Es braucht halt nur Stromstöße, damit OS wieder zeigt, was drin steckt.
GFS
Open Source Entwicklungen brauchen einen Grund, einfach so passiert nicht viel. Aber wenn es einen guten Grund pinkt: BOOOMM und die Lösung ist da, bevor das Problem völlig erkannt wurde ;)
Ich bin gespannt wohin der Weg führt. Ich selbst nutze CVS, bin aber nicht sehr zufrieden. Ein gutes VCS wäre wirklich wunderbar, Subversion ist für mich auch nur CVS mit Addonds, das ist nicht wirklich eine große Verbesserung. In anbetracht der Zeit die Subversion schon entwickelt wird ist es eher enttäuschend.
Subversion wurde als CVS-Ersatz entworfen und erfüllt den Job sehr gut. Es erweitert CVS behutsam und vor allem an den Stellen, wo es bisher hakte. Aber es gibt ja noch weitere VCSse:
http://better-scm.berlios.de/comparison/comparison.html
iGEL
Ja, aber es ist leider auch kaum mehr, obwohl es auch viele sinnvolle Verbesserungen gibt, die andere VCS integrietr haben. Es ist doch recht funktionsarm, und nur im Vergleich mit CVS Leistungsfähig.
Das heisst nicht das Subversion nichts taugt, ich habe mir davon aber mehr erhofft.
So liegt zum Beispiel der gesamte Clientcode in Form einer Shared Library vor, was die Entwicklung verschiedenster graphischer oder anderweitig spezialisierter Clients enorm erleichtert. Desweiteren ist Subversion im Gegensatz zu CVS eher eine erweiterungsfähige Plattform. Was auf dieser Basis möglich ist, zeigen zum Beispiel Projekte wie svk.
Wenn man dazu noch weiß, daß Subversion im Prinzip nichts als ein versioniertes Filesystem abbildet und die Details dahinter mittels einer API abkapselt, so ist zB irgendwann einmal ein Wechsel von der Berkeley DB hin zu SQL-Datenbanken denkbar und möglich.
Fazit: Subversion ist vor allem unter der Haube CVS deutlich überlegen, wer es nur auf die Bedienung des svn-Clients reduziert, muß sich nicht wundern, daß er nicht viele Neuerungen wahrnimmt.
lg
Erik
Mit cvs no chance.
Und da sind zwar viele sinnvolle Veränderungen drinne, aber das Basisprinzip von CVS wurde ja bewusst für den Entwickler beibehalten. Und daher sind auch viele Funktionen nicht integriert, welche die "großen" VCS integriert haben. Ich habe gehofft das Subversion mit der Zeit weiter gehen würde. So bleibt es für mich ein aufgebohrtes CVS. Ob es intern ganz anders funktioniert ist mir ehrlich gesagt völlig gleich.
ich muss mit dem arbeiten, was bei rauskommt
Das Basisprinzip... Du meinst die Syntax des SVN-Clients? Ja, die ist angelehnt. Was noch?
> So bleibt es für mich ein aufgebohrtes CVS
Eben nicht, wie gesagt, schau Dir doch mal svk an! Na, weckt das schon eher Dein Interesse? Das ist eines dessen, worauf ich mit den Ausführungen über die internen Unterschiede Subversion vs. CVS hinaus wollte. Es steckt eben so viel mehr in Subversion, als man nach der Betrachtung des SVN-Clients glauben möchte.
lg
Erik
Das gesamte arbeitne mit Subversion ist an CVS angelehnt. Das ist ja auch Sinn der Sache. Das es intern anders funktioniert ist mir, wie gesagt, relativ egal. Es gibt auch für CVS patches die einige Probleme lösen. Wie Subversion diese technisch löst ist mir nicht sonderlich wichtig.
Ich werde mir svk mal ansehen, es ist mir bisher unbekannt. Es klingt auf jeden fall schonmal ganz interessant.
Und genau diese Erklärung ist mir ziemlich schwammig, deshalb hab ich die Frage extra so ausdrücklich gestellt. :)
Hast Du vielleicht noch was spezielleres, daß ich übersehen habe?
lg
Erik
Wenn du mehr bzw.was anderes willst halte nach Monotone, Arch, Darcs, etc Ausschau. David Wheeler führte da mal ein paar Vergleiche durch: http://www.dwheeler.com/essays/scm.html
Das habe ich nicht bestritten, sondern gesagt das es eben leider kaum mehr ist.
"Wenn du mehr bzw.was anderes willst halte nach Monotone, Arch, Darcs, etc Ausschau."
Die nützen mir nichts, da die Entwickler die ich Anleite keine nicht-Grafischen Clients mögen. Daher mögen sie z.B. Eclipse mit CVS. Das ist dort gut integriert. Subversion ist auch ganz gut integriert, wenn es auch noch etwas wackelig ist.
Und da beginnt auch das Problem: Die anderen Clients scheinen über keine guten Frontends zu verfügen. Selbst CVS hat kaum gute Clients. WinCVS und LinCVS kann man IMHO in die tonne tretten. Viel zu umständig in der Bedienung, schlecht durchdacht usw.
Das ist natürlich vor allem mein Problem, da ich diese Systeme daher nicht nutzen kann. Aber darum habe ich auch meine Hoffnungen in Subversion gelegt, da sich dort schon früh zeigte das so manche Clients die CVS beherschen auch Subversion Support bekommen, da beide recht ähnlich sind (für den Entwickler)
Wenn ihr gute clients für Monotone und co. kennt, die mir unbekannt sind, oder gute Editoren die diese clients bereits perfekt integriert haben, immer raus damit. Ich würde mich freuen
Wer als Entwickler nicht in der Lage ist, ein Versionskontrollsystem adäquat zu bedienen ohne irgendein krankes GUI-Frontend, hat den Job verfehlt und sollte schnellstmöglich wieder ans Fließband...
Ein VCS ohne gut GUI ist für mich kaum halb so viel Wert.
Abgesehen davon ist Eclipse selbst wirklich gut, die Modularität ist gut umgesetzt, die Bedienung logisch.
Du musst es ja nicht mögen.
Danke für die URL, aber SmartCVS kenne ich schon :)
SmartCVS ist auf jeden fall wesentlich besser als WinCVS und co.
Aber leider immernoch fern ab der einfachen Bedienung