Diskussion:Apache Subversion/Archiv

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:Apache Subversion/Archiv#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:Apache_Subversion/Archiv#Thema_1

Unterschiede zu CVS

"Somit kann man einfacher – und im Gegensatz zu CVS konsistent – eine exakte Version beschreiben (z. B. „Version 2841“ statt „Version vom 23. März 2004 20:56:31 UTC“)." Okay, das die Angabe "2841" einfacher ist als "23. März 2004 20:56:31 UTC" kann ich nachvollziehen. Aber was heisst in diesem Zusammenhang "konsistent"? Eindeutig sind ja wohl beide. Siggisiggi 10:29, 2. Mär. 2007 (CET)

In CVS hat jede eingecheckte Datei ihre eigene (fortlaufende) Revisionsnummer; in Subversion gelten Revisionsnummern stets für das gesamte Repository. Bei Subversion gibt die Nummer somit den Stand des kompletten Repositorys eindeutig an, während bei CVS die Revision 50 der einen Datei aus dem Pleistozän und der anderen aus dem Trias stammen kann... --Tobias 19:31, 16. Jan. 2008 (CET)

Unsere Abteilung steigt von CVS auf SVN um, deshalb lese ich diesen Artikel; und bin erstaunt, dass nirgendwo CVS-Tags erwähnt werden! In CVS kann man eine beliebige Teilmenge der Dateien eines Repository (z.B. die Quellen eines bestimmten Softwaremoduls) mit einem Tag (einem symbolischen Namen, typischerweise einer Versionsbezeichnung wie "v1_2_3") markieren und kann genau diese Dateistände später anhand des vergebenen Tags wieder auschecken. (Die so getaggten Dateien haben i.a. ganz unterschiedliche CVS-Revisionsnummern - je nach dem, wie oft die einzelne Datei bislang verändert wurde.) Ein Tag kann man nachträglich sogar zu einem Branch umwandeln. Dann können auch Änderungen dieser (alten) Dateistände innerhalb vom Branch eingecheckt werden, ohne mit dem "Head" (dem aktuellen Entwicklungsstand, "Trunk" im SVN-Jargon) zu kollidieren. Das ist super-praktisch bei der Betreuung von erfolgten SW-Auslieferungen: denn es ermöglicht im Bedarfsfall lokales Bugfixing an einem älteren SW-Stand, ganz unabhängig vom aktuellen (Weiter-)Entwicklungsstand des Moduls. In SVN suche ich vergeblich nach einem ähnlich praktischen Konzept. "Tags" in diesem Sinne scheint es nicht zu geben, nur komplette Kopien eines ganzen Repository. Empfinde ich momentan als einen gravierenden Nachteil von SVN gegenüber CVS. Eskymak 17:39, 11. Apr. 2011 (CEST)

In SVN gibts genauso Tags. Siehe http://svnbook.red-bean.com/en/1.5/svn.branchmerge.tags.html Diese sind aber nicht fürs Markieren einzelner Files vorgesehen, sondern fürs gesamte Repository. Was Du möchtest sind Marker, die einzelne Files in spezifischen Revisionen markieren. Das heisst in SVN Properties. Siehe http://svnbook.red-bean.com/nightly/en/svn.advanced.props.html Generell würde ich aber davon abraten einzelne Files als z.B. "Ready for Testing" zu markieren. Ein Programm besteht ja nicht aus einzelnen unabhängigen Files, sondern aus dem korrekten Zusammenspiel vieler Files in genau einer Version. --Sebastian.Dietrich ✉ 19:21, 11. Apr. 2011 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Sebastian.Dietrich ✉ 21:18, 20. Okt. 2011 (CEST)

Angeblicher Nachteil der Abhängigkeit von Apache

In der derzeitigen Version liest man unter "Nachteile":

Benötigt den Apache HTTP Server 2.0, wenn das WebDAV-Feature genutzt werden soll. Allerdings könnte man hier entgegnen, dass CVS WebDAV gar nicht unterstützt.

Und deshalb finde ich, dass man diesen Punkt gleich streichen sollte. Denn wenn man Subversion mit den gleichen Zugriffsmethoden auf das Repository wie CVS betreibt, also ohne WebDAV, gibt es diese Abhängigkeit nicht. Wenn ich natürlich mehr Features haben will, muss ich gegebenenfalls mehr Abhängigkeiten von anderer Software in Kauf nehmen, das ist klar.

Weiterhin liest man:

Außerdem gibt es auch ein eigenes Protokoll, welches vergleichbar mit dem Netzwerkprotokoll von CVS ist.

Hier müsste man fairerweise auch noch den SSH-Zugang erwähnen, welchen es wie bei CVS auch gibt.

Da ich aber eben den gesamten Punkt nicht sinnvoll finde, werde ich ihn löschen und hoffe, dass diese Idee bei euch auf Gegenliebe stößt.

-- Blauwal 15:13, 14. Jul 2005 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Sebastian.Dietrich ✉ 21:17, 20. Okt. 2011 (CEST)

Unklar

Den dritten Punkt bei den Vorteilen verstehe ich leider nicht:

In CVS geht das umständlicher über Eintrag von binären Dateitypen (deren Endung) in cvswrappers und wobei diese Filetypen voll gespeichert werden.

Was ist denn damit gemeint? --Mst 16:00, 14. Jul 2005 (CEST)

habs geändert, hoffe es stimmt. --Mst 18:57, 18. Jul 2005 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Sebastian.Dietrich ✉ 21:17, 20. Okt. 2011 (CEST)

Abhängigkeiten

• XML-Parser Expat

Kommentar aus dem Artikel: Ich habe das Paket nicht benötigt, war das in einem der anderen schon enthalten?

Kann das stimmen? --Thornard, ^Diskussion, 22:57, 31. Mär. 2007 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Sebastian.Dietrich ✉ 21:16, 20. Okt. 2011 (CEST)

SVN im Licht von CVS

Ich muß mich der bereits mehrfach geäußerten Kritik anschließen. Der Artiken behandelt SVN fast ausschließlich im Vergleich zu CVS. Das sollte m.E. aber nur ein Unterpunkt sein. Ich vermisse eine Beschreibung der Struktur von SVN. Was ist zum Beispiel ein Repository und wie verwaltet SVN denn nun die Dateien? Ich würde für eine komplette Umstrukturierung des Artikels plädieren in der versucht wird, die zahlreichen Erkärungen die CVS als Ausgangspunkt verwenden umzuschreiben.

beste Grüße, Alpha

Ist denke ich inzwischen schon ganz anders als damals bekritelt --> :Archivierung dieses Abschnittes wurde gewünscht von: Sebastian.Dietrich ✉ 21:16, 20. Okt. 2011 (CEST)

zerlegte-UTF-8-Version

zerlegte-UTF-8-Version ??? --Thornard, ^Diskussion, 13:17, 8. Aug. 2007 (CEST)

nun, im Englischen heißt es "composed" und "decomposed" - siehe dazu diesen Thread: http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=128668

Ich habe Wörter "composed" und "decomposed" weder in dem Artikel UTF-8 noch in der von dir angegebenen Seite gefunden. Mir ist nicht klar was genau gemeint ist. Auch der Artikel Dateiname bietet keine weiteren Infos darüber. --Thornard, ^Diskussion, 16:19, 8. Aug. 2007 (CEST)

"composed" und "decomposed" sind als NFC bzw. NFD im genannten Thread zu finden 84.145.52.17 20:08, 8. Aug. 2007 (CEST)

Ich bezweifle ja auch nicht die Richtigkeit. Trotzalldem ist der Absatz so wie er jetzt im Artikel steht unverständlich. Wenn das nicht in UTF-8 erklärt wird, muss das eben hier geschehen. Ich fühle mich hierzu nicht in der Lage. Daher habe ich den Baustein eingesetzt. Vielleicht kannst du das ja machen. Sonst bleibt der Baustein eben drin. --Thornard, ^Diskussion, 22:45, 8. Aug. 2007 (CEST)

„Zerlegte-UTF-8-Version“ war ziemlich daneben: Hierbei handelt es sich im zusammengesetzte Zeichen, ganz unabhängig vom verwendeten UTF. Die jetzige Formulierung mit „zwei“ bzw. „ein Zeichen“ ist korrekt, aber etwas kryptisch (wieso sollte ein Betriebssystem für einen Buchstaben zwei Zeichen speichern?). Habe deshalb ein Beispiel hinzugefügt, um klarzumachen, was gemeint ist. Die Fußnote ist notwendig, weil »¨« eben nicht COMBINING DIAERESIS ist, sondern DIAERESIS. Da ohnehin eine Fußnote notwendig ist, habe ich gleich einen passenden Quellen-Verweis angebracht.

134.34.1.209 15:35, 5. Dez. 2007 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Sebastian.Dietrich ✉ 21:15, 20. Okt. 2011 (CEST)

Vorschlag: 'Alternative' statt 'Ablösung'

Die englische Wikipedia verwendet mit Vorteil 'alternative' statt ein Wort wie 'Ablösung'.

("Subversion wurde als moderne Ablösung für das mit vielen Schwächen behaftete, in Entwicklerkreisen trotzdem noch sehr verbreitete Programm CVS entwickelt.
Deshalb ist es mit Bedacht in der Bedienung sehr ähnlich gehalten, hat dasselbe zentrale Paradigma und behebt die meisten Schwächen von CVS.") 

Greetasdf 12:59, 13. Okt. 2007 (CEST)

Ist im Artikel schon längst anders & besser --> :Archivierung dieses Abschnittes wurde gewünscht von: Sebastian.Dietrich ✉ 21:15, 20. Okt. 2011 (CEST)

Branch und Tag erklären

Mir ist nicht richtig klar geworden, was Tag und Branch in diesem Zusammenhang bedeuten. Der Artikel scheint für Leute geschrieben, die das schon wissen. Kann mir (und dem Artikel) jemand auf die Sprünge helfen? Ungebeten 07:41, 17. Okt. 2007 (CEST)

Da es bei Subversion beides nicht gibt, sollte man nur geeignet verlinken. --Trublu ?! 10:28, 17. Okt. 2007 (CEST)

Ich bin der Meinung, dass man Branches, Tags und Trunk auch bei wikipedia erklären sollte. Bisher konnte ich keinen Hinweis dazu finden, jedoch wird die Verwendung dieser "Verzeichnisse" in der Entwicklung ja immer wieder empfohlen!

BSG2000 Hinweis hinterlassen 10:40, 15. Nov. 2007 (CEST)

Der Abschnitt „Tag- und Branchkonzept“ ist mir völlig unverständlich, da die Begriffe „Tag“ und „Branch“ als bekannt vorausgesetzt werden. Da das Konzept hier anhand des Unterschieds zu CVS erklärt wird, habe ich im Artikel Concurrent Versions System nachgeschaut: Dort kommen diese Begriffe überhaupt nicht vor! Im englischen Artikel gibt’s zwar einen eigenen Abschnitt Branching and tagging, aber der blieb mir, ehrlich gesagt, auch ziemlich unverständlich.

Also: Unbedingt hier „Branch“ und „Tag“ erläutern, oder den Abschnitt ohne diese Begriffe formulieren, und zwar verständlich für Leser, die zum ersten Mal etwas von einem Version Controll System hören: Zuerst den Zweck der Übung umreißen und dann erst schildern, was SVN dafür tut.

134.34.1.209 14:38, 5. Dez. 2007 (CET)

Habe mal den Versionsverwaltungsartikel um einen Abschnitt Branching und Tagging ergänzt. Reicht das als Erklärung? --Tobias 20:37, 16. Jan. 2008 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Sebastian.Dietrich ✉ 21:14, 20. Okt. 2011 (CEST)

Neutralität

Dass SVN die meisten Schwächen von CVS behebt, halte ich für eine haltlose Behauptung. Gerade das zentrale Paradigma ist eine der größten Schwächen und ist verantwortlich dafür, dass beispielsweise jeder commit sofort global sichtbar ist und es nicht möglich ist, eine Serie von Änderungen durchzuführen und als ganzes zu commiten, dabei aber eine feine Gliederung der einzelnen Änderungen beizubehalten (Patchserie). Eine weitere gravierende daraus resultierende Schwäche ist die Unmöglichkeit für externe Entwickler ohne Commit-Access mehr als eine Änderung zu pflegen, ohne auf diff zurückzufallen => totalversagen. Am besten trifft es dieses Zitat von Linus Torvalds (sinngemäß): "there is no way to do CVS right". --(nicht signierter Beitrag von 87.234.156.78 (Diskussion) 11:28, 9. Nov. 2007)

Neutralität wiederhergestellt, hoffe ich; allerdings habe ich Erläuterungen hinzugefügt, die SVN klar besser dastehen lassen als CVS. Ich wünschte, ich hätte auch das zentrale Paradigma erhellen können, doch da bin ich leider ratlos. --Peu 10:31, 14. Nov. 2007 (CET)

„Gerade das zentrale Paradigma ... ist verantwortlich dafür, dass beispielsweise jeder commit sofort global sichtbar ist und es nicht möglich ist, eine Serie von Änderungen durchzuführen und als ganzes zu commiten“

Äh. Für so etwas macht man einen Branch: Man erzeugt also eine Kopie, führt auf dieser nach und nach alle Änderungen durch und testet das Ergebnis. Wenn alles funktioniert, reintegriert man das ganze in den Trunk (svn merge -r M:N /url/des/branches o.ä.), testet wieder und committet abschließend alles auf einmal. Oder was ist gemeint? --Tobias 19:54, 16. Jan. 2008 (CET)

„... die Unmöglichkeit für externe Entwickler ohne Commit-Access mehr als eine Änderung zu pflegen, ohne auf diff zurückzufallen => totalversagen“

Also, ein Totalversagen stelle ich mir anders vor; wer ernsthaft an einem Projekt mitarbeitet, braucht eben Commit-Zugriff, zumindest eben in einem Branch; es ist schließlich möglich, die Zugriffsrechte fein zu regeln (wenn auch unterschiedlich je nach Zugriffsmethode). --Tobias 19:54, 16. Jan. 2008 (CET)

Ich plädiere dafür, auch einen Abschnitt »Kritik« einzufügen, wo thematisiert wird, inwieweit Subversion tatsächlich die vermeintlichen oder echten Schwächen von CVS behebt. Scheinbar teilen ja noch mehr Leute meine Ansicht, dass Subversion dem eigenen Anspruch »CVS-Ersatz« nicht wirklich gerecht wird. Stichpunkte der Kritik:

• Die angeblichen Branches und Tags von Subversion sind völlig unbrauchbar. Eine Kopie eines Repositories oder Projekts kann ich mit jedem x-beliebigem Versionskontrollsystem machen.
• Dass die globalen Revisionsnummern einer Versionierung auf Dateiebene vorzuziehen sind, ist schwer nachvollziehbar. Das Versionsschema von CVS hat einen höheren Informationsgehalt (Fakt, nicht Meinung). Wer das Schema von SVN lieber mag, kann einen Stand taggen, und hat dann auch benamte Tags.
• Atomare Commits von Subversion beheben ein Phantomproblem.
• Auch mit CVS kann jeder, der nicht ganz blöd ist, Dateien oder ganze Verzeichnisse umbenennen, ohne die Versionshistory zu verlieren. Dass es dafür keine Frontendbefehle gibt, ist nicht zwangsläufig ein Fehler, Stichwort Revisionssicherheit.
• CVS speichert Daten transparenter.
• ...

Ich hab wirklich nichts gegen Subversion, aber der ganze Artikel transportiert aus meiner Sicht das populäre Vorurteil, dass Subversion die Verbesserung von CVS wäre. Subversion ist ein anderer Ansatz, es gibt noch etliche weitere, aber letztlich ist die Wahl der Software eine Abwägung zwischen den Vor- und Nachteilen der einzelnen Systeme. Dass SVN mit CVS im Artikel verglichen wird, halte ich für legitim. Ich sehe aber nur einen einzigen unbestrittenen Fortschritt, den SVN im Verglich zu CVS gemacht hat, und das ist der verschlüsselte Zugriff out of the box. Alles andere ist lediglich ein konkurrierender Ansatz. --Gflohr 14:23, 13. Mai 2009 (CEST)

Ich war bisher genau dieser Meinung (SVN sei die "Verbesserung" von CVS). IMHO "verkauft" sich SVN selbst sogar so. Eure Diskussion finde ich deshalb interessant, und es wäre sicher bereichernd, einen Kritik-Absatz zu schreiben. Allerdings sollte sich dieser stilmässig natürlich sehr stark von dem unterscheiden, was ihr hier geschrieben hat, damit er nicht in eine politische Diskussion abgleitet. Die meisten Aussagen hier sind nicht wirklich sachlich, etwas wage und nicht mit Fakten belegt. In einem "Kritik"-Abschnitt müssten dann vorallem sachliche Aussagen mit Quellenbelegen stehen. --Chiccodoro 09:16, 15. Mai 2009 (CEST)

Meine »Kritik« war überzogen, das ist klar, deshalb steht sie hier auf der Diskussionsseite und nicht im Artikel. Und mein Vorschlag für einen Abschnitt »Kritik« entsprang einem kleinen Wutanfall als Reaktion auf einen unreflektierten »wieso benutzt du denn noch immer CVS, obwohl es SVN gibt???«-Vorschlag. ;-) Neuer Vorschlag: Jemand sollte die Advocacy-Aussagen aus dem Artikel entfernen. Vergleiche und Bewertungen gehören imho eher in den Artikel Versionsverwaltung. Das Thema ist seit Linus Torvalds Git begonnen hat, ja ungefähr so interessant wie die Platzierung geschweifter Klammern. --Gflohr 23:47, 16. Mai 2009 (CEST)

Ich hab den Artikel jetzt selber etwas neutraler formuliert. Ich hoffe, ich bin nicht über's Ziel hinausgeschossen. --Gflohr 23:58, 16. Mai 2009 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Sebastian.Dietrich ✉ 21:13, 20. Okt. 2011 (CEST)

GUI-Anwendung verweist falsch

Hallo zusammen,

als noch nicht so Geübter, verweist die SVN-GUI "Cornerstone" fälschlicherweise auf eine Rockband. Wie kann man dies beheben?

Besten Dank trinix

Ist geändert. Trublu ?! 09:27, 26. Okt. 2008 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Sebastian.Dietrich ✉ 21:13, 20. Okt. 2011 (CEST)

Horrormärchen von Repository-Zerstörung bei kompletten Entfernung von Dateien.

Das ist eine häufig aufgestellte Behauptung die komplett falsch ist. Das alte Repository wird gedumpt ,der dump gefiltert, und eine neues repository ohne die betreffenden Dateien aufgebaut. Das alte Repository wird also gar nicht verändert kann also auf keinen Fall zerstört werden. Der Hintergrund ist vermutlich : Wenn die Datei notwendig für das funktionieren der verwalteten Software so kann das Repository in diesem Sinne unbrauchbar werden. Das ist aber definitiv kein Subversion-Problem. Ich habe deswegen das entfernt,und näher erläutert was so aufwendig an dem Verfahren ist. -- Thekensportler 13:19, 30. Jun. 2010 (CEST)

Der Wunsch eine Datei inkl. Historie zu entfernen ist genauso ungewöhnlich wie den Grundsätzen (Historisierung) eines Repositories zuwiederlaufend. Ich hab daher die Formulierung vom negativen ins positive umgewandelt & auch die Referenz auf den uralt Featurerequest, der wohl bewusst nie umgesetzt werden wird entfernt. --Sebastian.Dietrich ✉ 18:01, 30. Jun. 2010 (CEST)

Aus meiner Sicht ist der ganze Absatz irrelevant - echtes Löschen ist ein Hack, der beschriebene Ablauf ein seltsamer workaround für etwas, das keiner braucht. Mit einem dump könnte man alles mögliche anstellen, aber das hat doch hier nichts verloren?!--194.48.126.192 09:48, 20. Okt. 2011 (CEST)

Hab die Anleitung wie das geht rausgenommen, weil 1) nicht SVN Technik und 2) ist Wikipedia keine Gebrauchsanleitung. --Sebastian.Dietrich ✉ 21:12, 20. Okt. 2011 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Sebastian.Dietrich ✉ 21:12, 20. Okt. 2011 (CEST)

Dateien mit Unterschieden in Gross/Kleinschreibung korrigieren

Zitat: "Die aktuelle Subversion-Version hat lediglich Probleme [snip] Ein vergleichbares Problem tritt bei der Verwendung innerhalb von Unix-Windows-Projektumgebungen auf. So ist es möglich, unter Unix zwei Dateien anzulegen, welche sich nur in der Groß/Kleinschreibung unterscheiden. Dies wird von Windows nicht unterschieden und führt somit dazu, dass eine der beiden Dateien immer die andere überschreibt. Gelöst werden kann dieses Problem nur durch Änderung der Benennung auf dem Server."

Ich denke, das Problem lässt sich auch im Repository Browser und auch auf einem Linux Client lösen.

Den Abschnitt gibts schon seit 24.7.2009 nicht mehr im Text - wenn doch hätte ich ihn auch gelöscht, da das kein SVN-, sondern ein Windows-Problem ist. --Sebastian.Dietrich ✉ 17:50, 9. Jan. 2016 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Sebastian.Dietrich ✉ 17:50, 9. Jan. 2016 (CET)