Diskussion:Apache Subversion

Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „Apache Subversion“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen.

• Diskussionsregeln
• Hilfe zu Diskussionsseiten
• Sei sachlich und freundlich!
• Greife niemanden persönlich an!
• Geh von guten Absichten aus.

Zum Archiv

Automatische Archivierung

Auf dieser Seite werden Abschnitte ab Überschriftenebene 2 automatisch archiviert, die seit 30 Tagen mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind.

Wie funktioniert SVN?

Ich möchte gern in SVN einsteigen und dachte mir, mal eben bei Wikipedia vorbeizuschauen um einen Überblick zu erhalten wie SVN funktioniert - aber nichts da :( Meiner Meinung nach stehen hier zu viele in-depth informationen, zB Vergleiche zu CVS etc., ohne zu erklären welche Konzepte SVN eigentlich verfolgt und wie es grundsätzlich funktioniert.

edit: ich seh gerade, der CVS Artikel ist in dieser hinsicht wesentlich besser!

→Ich bin gleicher Meinung; statt als erstes zu erklären, wie sich subversion von cvs unterscheidet, sollte erklärt werden, wie das Prinzip funktioniert. Als Anfänger hat man sonst keine Chance, den Inhalt des Textes zu verstehen --213.144.130.33 16:02, 11. Jul. 2007 (CEST)

Ich muss euch recht geben, allerdings kenne ich mich auch kaum mit SVN aus, um da was zu ändern. Vielleicht findet ja mal jemand Zeit und Lust.--Alberto Balsam 20:19, 12. Mär. 2008 (CET)

Ansteigende Repository-Größe?

Was soll den der Nachteil gegenüber CVS bedeuten, dass die Repository-Größe ansteigt? (nicht signierter Beitrag von 80.143.6.249 (Diskussion) 14:56, 10. Sep 2004)

Die gleichen Daten (z.B. nach Konvertierung) benötigen in einem Subversion-Repository deutlich mehr Platz, als in einem CVS-Repository. Ich werde das mal auch im Artikel klarer schreiben. -- Dishayloo [ +] 13:14, 11. Sep 2004 (CEST)

Tun sie das wirklich im _Repository_? Die _workingcopies_ sind natürlich größer, Faustregel: doppelt so groß wie sie sein müssten, weil für jede Datei die Version nach dem letzten Update aufbewahrt wird. Meines Erachtens sind sie die Repositories aber eher kleiner, zumindest ab Version 1.10 mit FSFS. Stichwort "Binärdateien".

Ab Version 1.1 mit FSFS mag sein. Mein Kommentar bezog sich auf Version 1.0, mein Beitrag ist von September, bedenke das bitte. :-) Ich habe nur konvertierte CVS-Repositories im Datenbankformat bisher ausprobiert, und die sind alle etwa doppelt so groß. Vielleicht, aber nur vielleicht, werden die Repositories kleiner, wenn Binärdateien gespeichert werden, die viele Versionen haben, denn Subversion hat binäre Diffs. Ist FSFS empfehlenswert? Es dürfte ja wahrscheinlich langsamer sein als die Speicherung in der Datenbank, aber ausprobiert habe ich das tatsächlich noch nicht. -- Dishayloo [ +] 17:21, 19. Nov 2004 (CET)

Ich würde eher FSFS als Berkeley DB empfehlen, da ich die (für Linux-Benutzer unnatürliche und außerdem viel zu fehleranfällige) Kompilierung von DB abgrundtiefst hasse, weswegen ich lieber ./configure --without-berkeley-db verwende. Ich habe es mit DB noch nie probiert, da ständig Kompilierungsfehler dann bei Subversion auftreten. Ich glaube, dass SVN mit FSFS ziemlich schnell ist, doch bisher habe ich es nur über mein Lokalnetzwerk verwendet, und CVS habe ich auch noch nicht ausprobiert. Das werde ich aber bald nachholen. ~~WhiteTimberwolf 16:57, 10. Jan 2005 (CET)

Da Subversion auch für Binärdateien Diffs speichert und bei Branches keine Kopien, erzeugt glaube ich auch nicht an grössere Repositories. Eher kann es sein, dass der CVS2SVN Konverter nicht sauber arbeitet und daher erstmal eine Vergrösserung des Repositories geschieht. --P.C. ✉ 11:09, 10. Jan 2006 (CET)

Anmerkung zur Komplexität von Subversion

Subversion ist sehrwohl alleine laufähig, nämlich 1. lokal bzw. über gemappte Serverlaufwerke. Bei diesem Einsatz sind die Commits zwar nicht mehr atomar, aber nach einem sehr langen und häufig genutzen Betrieb mehrerer SVN-Archive in meinem Firmennetzwerk sind noch keine Fehler aufgetreten.

2. eigenes SVN-Protokoll entweder direkt oder über SSH-Tunnel. Die Archive in unserem Netzwerk habe ich mittlerweile auf das SVN-Protokoll umgestellt da hier atomare Commits möglich sind.

Beide Versionen funktionieren unter Windows und Linux ohne Probleme.

Wieso sollten die Commits nicht mehr atomar sein, nur weil auf das Repositry nicht über einen zwischengeschalteten Serverprozess zugegriffen wird? Das ist meines Erachtens falsch. Beide derzeitigen Dateisystem-Implementationen, FSFS und BDB, bieten atomare Commits, egal auf welche Weise auf das Repository zugegriffen wird (file://, svn:// oder http://). Einzige Einschränkung beim Einsatz von BDB ist, dass ein solches Repository nicht einfach über NFS- oder SMB-Freigaben benutzt werden kann, FSFS allerdings schon (mit atomaren Commits!). -- Tom

Ähh, wenn ich den Begriff "Komplexität" in Bezug auf Software höre denke ich an etwas anderes. Vielleicht sollte man sich über eine andere Bezeichnung Gedanken machen... --Ziggystar 09:16, 24. Mai 2006 (CEST)

Frontends

Müssen wir alle GUI-Frontends mit Weblink aufzählen? Wenn Subversion den Erfolg von CVS wiederholt, dann wird diese Liste zwangsläufig explodieren. Schon jetzt könnten viel mehr Programme genannt werden, da es Plugins für viele IDEs gibt. Und bevor wir hier entscheiden, welcher Client wichtig ist und welcher nicht, sollten wir die Liste lieber komplett streichen und stattdessen erwähnen, dass es Frontends für verschiedene Betriebssysteme gibt. Wenn ein Client etwas extraordinäres tut, dann hat er auch ein paar Sätze ordentlichen Text und einen Wikilink verdient. Und in einem eigenen Artikel sollte dann natürlich auch ein Weblink gesetzt werden. Aber bitte nur dann, wenn der Subversion-Client auch etwas wirklich erwähnenswertes bietet. Was meint ihr, sollte die Auflistung der Clients bleiben oder gelöscht werden? -- Dishayloo [ +] 23:38, 26. Jun 2005 (CEST)

Ich habe sie nun rausgeschmissen, da es keinen Widerspruch gab. -- Dishayloo [ +] 01:09, 27. Jul 2005 (CEST)

Alle relevanten Frontends müssen hier nat. nicht aufgezählt werden − aber lediglich die populärste GUI für Windows zu verlinken, ist vielleicht auch ein bisschen knapp. Ich schlage vor, zumindest noch einen Link auf RapidSVN einzufügen, das ist − würd ich mal sagen − das populärste Multi-Plattform-GUI. Gibts keine Widerrede, werd ich den Link die Tage noch ergänzen. --Falk 11:29, 12. Mai 2008 (CEST)

So, gemacht. Jetzt sind beide quasi-offiziellen GUI-front-ends verlinkt. Damit sind dann laut RapidSVN-Projektseite alle Plattformen abgedeckt, auf denen SVN überhaupt nutzbar ist (und "bessere"/populärere freie GUIs gibts meines Wissens auch nicht). --Falk 22:52, 12. Mai 2008 (CEST)

In der en-wiki gibt es einen Artikel über das weitverbreitete ViewVC. 84.173.204.16 14:23, 8. Jul. 2007 (CEST)

In dem Artikel gibt es einen Hinweis darauf, dass in Vim ein Plugin zur verfügung steht, Emacs wird aber nicht erwähnt, wieso? (nicht signierter Beitrag von 80.153.191.50 (Diskussion | Beiträge) 17:25, 26. Mai 2009 (CEST))

Entfernter Punkt bei Nachteilen (Berkeley DB)

Ich habe den folgenden Punkt über die Verwendung von Berkeley-DB entfernt:

• Wenn das Berkeley-Datenbanksystem für Subversion als Repository-Grundlage verwendet wird (Standardeinstellung), unterliegen die Daten einerseits dessen binären Inkompatibilitäten abhängig von der verwendeten Version, und andererseits den damit eingebrachten Stabilitätsproblemen, die die Sicherheit der Daten gefährden können - insbesondere, da es keine Möglichkeit gibt, wie bei CVS die Daten rein manuell zu reparieren.

Gründe: Erstmal ist die Nutzung von Berkeley-DB seit Version 2.2 eben NICHT mehr die Standardeinstellung, jetzt wird standardmäßig FSFS benutzt. Weiterhin lehne ich den Kommentar über die händische Korrigierbarkeit des CVS-Repositories ab: damit kann man sich sein Repository zerschiessen. Das Repository ist weder bei CVS noch bei Subversion zur manuellen Reparatur ausgelegt. Bitte keine Anleitungen zum Datenverlust in die WP. Das mit den Inkompatibilitäten möchte ich genauer erklärt haben, bisher konnte man in den neuen Subversion-Versionen sein Repository (auch mit der Berkeley-DB als Backend) übernehmen. Was hat der Kommentar mit den binären Inkompatibilitäten also zu bedeuten? -- Dishayloo + 00:33, 19. Okt 2005 (CEST)

OK, das mit den binären Inkompatibilitäten konnte ich doch bestätigen, Zitat von hier: A lot of operating systems now ship Berkeley DB 4.3. Sometimes the system Berkeley DB libraries can be unintentionally upgraded to 4.3 as part of some other change pulled down via an OS package delivery mechanism — for example, upgrading one's Subversion package. If this happens to you, you will need to upgrade existing BerkeleyDB-based repositories to 4.3. Ich passe das entsprechend im Artikel an. -- Dishayloo + 00:37, 19. Okt 2005 (CEST)

In meimen Augen ist es ein großer Nachteil, wenn ich das Repository nicht von Hand reparieren kann. Klar kann man damit auch was zerschießen, aber das kann man als root auch, und trotzdem finde ich sinnvoll, daß Unix nen root-Acount hat. Ich hatte schon mehrfach das Problem, daß zum Beispiel ein User Daten eingecheckt hatte, die auf garkeinen Fall ins Repository sollen (sei es, weil ein Passwort in der Datei steht oder andere vertrauliche Daten oder sei es, weil die Datei viel zu groß ist (Mehrere GB großes Dump)). In CVS ist sowas sehr einfach wieder zu entfernen, in Subversion nur mit der Gefahr, sich sein komplettes Repository zu zerschießen!(nicht signierter Beitrag von 129.132.10.66 (Diskussion) )

Es gibt durchaus einige Möglichkeiten solche Dateien oder Commits zu löschen[1] – leider mit Einschränkungen. Vielleicht ändert sich das aber mit einer der nächsten Major-Versionen! --Haeber 17:56, 3. Aug 2006 (CEST)

Beschreibung der Funktionen

Hallo, ich finde es fehlt am Anfang des Artikels eine Beschreibung was Subversion überhaupt ist bevor es mit irgendetwas anderem verglichen werden kann. Wenn ich den Artikel lese ohne CVN und Subversion zu kennen hilft mir der vergleich nicht viel.

Gruß, Konzales 14:03, 25. Apr 2006 (CEST)

der normale Subversion-Port 3690

Bennennung

Die Benennung „Subversion“ verweist einerseits auf den politisch-soziologischen Begriff der Subversion und greift andererseits die Bedeutung von sub version im Sinne von Unterversion, früherer Version auf.

Den ersten Teil dieser Aussage... kann den irgendwer durch Quellen belegen ? Subversion ist meiner Ansicht nur aufgrund der Versionierung so benannt, nicht wegen irgendwelchen politisch-soziologischen Worte. --91.2.55.238 20:36, 26. Feb. 2009 (CET)

Das ist einfach ein Wortspiel auf dem Begriff. Da Subversion "früher" nur die erste Bedeutung hatte und erst durch die Software auch die zweite bekam, ist dies den Benennern bekannt und bewusst gewünscht oder zumindest hingenommen worden. Daher sollte der Satz stehenbleiben. Auch ohne Einzelnachweis, was sich die Benenner gedacht haben. Trublu ?! 21:47, 26. Feb. 2009 (CET)

Das sehe ich anders. Das Wort Subversion mag vorher eine Bedeutung gehabt haben - das heißt aber nicht, dass die Bedeutung gewünscht war. Auf jeden Fall sollte das nachgewiesen werden, da es sonst erstmal haltlos ist. :: Ich benenne Produkte auch ab und an mit Wörtern die es es vorher schon gab, aber die bedeutungen haben da mit mal gar nichts zu tun. Es mag sein, dass es bei Subversion so ist, aber Zweifel daran bestehen -> Quelle oder raus. --Mullinger 22:06, 26. Feb. 2009 (CET)

Ich stimme Mullinger zu. Die soziologische Bedeutung ist hier m.E. höchstens eine sekundäre, wortspielerische, aber zumindest bei einer schnellen Suche auf der off. Homepage habe ich keinen Hinweis darauf gefunden, dass das Absicht ist -- man vergleich das mit den in der FLOSS-Gemeinde verbreiteten und dann üblicherweise ca. im zweiten Paragraph der Einleitung erklärten Wortspielen wie GNU usw. Ich habe den fraglichen Satz (in zwei aufgetrennt) umgeschrieben und hoffe, diesen Umstand damit zur Zufriedenheit aller Parteien berücksichtigt zu haben. Mfg. Sesc 18:01, 27. Feb. 2009 (CET)

Deine Formulierung fand ich allerdings nun etwas stark in die Gegenrichtung zielend ("hineinlesen" ist ziemlich unneutral...). Entsprechend habe ich nun versucht eine neutralere Formulierung zu finden. Den Quellenbaustein habe ich wieder herausgenommen, da ja nun keine Behauptung mehr drin steht, die einer Quelle bedürfte. BTW: Ich halte es führ SEHR wahrscheinlich, dass das Wortspiel beabsichtigt war. Deswegen muss man dieses als Entwickler den Leuten noch lange nicht unter die Nase reiben. Aber wenn es nicht so war, bräuchte ich eine Erklärung, wie es sonst zum Namen gekommen sein soll, da er aus einem eigentlich nicht existierenden Wort besteht (s. z.B. LEO). Ausserdem ist es erklärtes Ziel von Subversion, CVS zu ersetzen... Aber das ist nur meine Meinung. Quellen habe ich auch keine. --Chiccodoro 18:24, 27. Feb. 2009 (CET)

Naja... die Versionierung basiert auf dem anlegen verschiedener Unterversionen. Aber ist ja auch wurscht ;) --Mullinger 19:43, 27. Feb. 2009 (CET)

@Chiccodoro: Da hast du mehr Gegenrichtungsabsicht hineingelesen (sic!) als meine Absicht war! ;-) Ich sehe aber auch, dass mein Wort unnötig Interpretationsspielraum ließ und finde deine Lösung mit "andere Lesart" an 2. Stelle gut. Persönlich neige ich (eben auch, weil das sonst übliche "Herausposaunen" des Wortspiels in der Doku fehlt) eher zu Mullingers ganz profaner Lesart von Sub-Versionen, aber das hindert ja keinen daran, das Wortspiel zu genießen (vllt. gerade humorvoll, weil Subversion seinen Umsturz nicht sehr "subversiv" sondern recht offiziell betreibt? :)). Um nochmal Mullinger zu bemühen: ist ja auch wurscht ;) Cheers Sesc 13:54, 28. Feb. 2009 (CET)

@Mullinger: Ich würde meinen, die Versionierung basiert auf dem Anlegen verschiedener Versionen. ;-) Was ich unter einer Unterversion verstehen soll, müsstest du mir zuerst erklären, aber ich streite deswegen natürlich nicht ab, dass es die gibt, weiss ja auch nicht alles :-). Aber der Name ist IMHO eine Wortschöpfung. Über den Ausdruck "subversion" im Sinne von "Unterversion" kann ich auf die Schnelle nichts finden. − Danke für den typo-fix.

@Sesc: Ist das Hinausposaunen wirklich üblich? Ich kann dir nicht mehr sagen, welche Namen es waren, aber ich habe schon mehrmals über einen Namen gesucht, warum sie den gewählt haben, und nie etwas gefunden. Daraus schloss ich jeweils, dass sie das "geheim" halten und den andern überlassen, was sie hinein- und herausinterpretieren wollen.

Auf jeden Fall finde ich es gut, dass ihr darauf aufmerksam gemacht und wir die Behauptung jetzt relativiert haben. Wikipedia soll ja nicht eine Interpretation der Welt sein... --Chiccodoro 13:57, 2. Mär. 2009 (CET)

Naja... Branch/Tag Systeme erzeugen jeweils unter einer Version verschiedene Branchs, Tags und Revisionen. Ich bin aber, ehrlichgesagt kein besonderer freund von SVN mir fehlt hier die nötige neutralität ;) --Mullinger 16:34, 3. Mär. 2009 (CET)

SVN-spezifische Begrifflichkeiten

Hallo Thornard (und alle Mitarbeiter an diesem Artikel)

Die von dir kürzlich vorgenommene Änderung [2] ergibt sicher einen Sinn. Trotzdem ist sie für meinen Geschmack eine unbefriedigende Lösung für ein Problem, das mir nun dadurch erst bewusst worden ist. Vielleicht können wir hier eine gute Lösung dafür finden?

Das Problem: Subverison und auch allgemein Versionierungsprogramme verwenden verschiedene Begriffe, die im englischen mit "commit", "tag(ging)", "branch(ing)", "revision", "head", etc. bezeichnet werden. Bislang wurden diese in diesem Artikel an zahlreichenstellen wörtlich und mit Gänsefüsschen umgeben eingesetzt. Du hast dich nun zu jedem dieser Begriffe auf eine deutsche Bezeichnung festgelegt und diese überall eingesetzt.

Ich wage das aber in Frage zu stellen: Sind denn diese Bezeichnungen eingebürgert und werden im Zusammenhang mit Subversion/Versionierung "offiziell" (im deutschen Sprachraum) verwendet? Oder ist das nicht eine abgeschwächte Form von Theoriefindung, wenn wir nun einfach deutsche Bezeichnungen dafür einführen?

Ich muss aber zugeben, dass dieses "quoten" von "terms" in einem "german" "article" auch nicht gerade "beatiful" ist. Das heisst, in letzterem Fall müssten wir uns mal überlegen, wie diese englischen Bezeichnungen am besten eingebaut werden. (Wie machen das andere? Gibt es gar Richtlinien dafür? Im Software-Umfeld stösst man doch immer wieder auf solche Probleme.)

Weitere Fragen:

An den ersten Erwähnungsstellen von ("commit") hast du jeweils die Gänsefüsschen nach aussen gezogen "(commit)". Hierin sehe ich nun tatsächlich keinen Sinn. Diese Schreibweise suggeriert, dass die Klammern Teil der Bezeichnung sind. Oder gibt es eine deutsche Grammatikregel, die das so vorschreibt?

Dann kommt an einer Stelle vor, dass du "tag" nicht wie sonst überall mit "Kennzeichnung", sondern mit "Kopie" übersetztest, ohne dabei nochmals zu erwähnen, dass immer noch von einem "tag" die Rede ist. Gibt es einen speziellen Grund dafür?

Zu guter Letzt: Ein "ü" als Zusammenfassung deiner Änderung ist nicht gerade aussagekräftig. Mit einer etwas ausführlicheren Zusammenfassung hättest du mir vielleicht einige dieser Fragen erspart.

Sorry, ist vielleicht grad etwas viel an Kritik, aber eigtl. gehört ja alles zusammen.

Lieber Gruss, --Chiccodoro 08:35, 13. Mär. 2009 (CET)

Hallo Chiccodoro,

du hast mit allen deine Anführungen recht. Viel Gedanken habe ich mir dabei nicht gemacht und gehofft, dass sich durch meine recht rigorosen Bearbeitungen jemand findet, der da mehr sprachliches Feingefühl mitbringt.

Ich denke, Begriffe wie Übertragen, Aktualisieren, Verzeigen sind durchaus in Ordnung:

„Ich übertrage meine lokalen Änderungen ins gemeinsame Repository“. Repository würde ich jetzt nicht eindeutschen. „…und aktualisieren meine lokale Version, um Konflicke zu bearbeiten.“ Ich denke das geht so gut. Problematisch sind die Begriffe „tag“ und „branch“. Die brauchen meiner Meinung nach eine genauere Erläuterung und lassen sich nicht so einfach ins Deutsche übertragen, ohne für der Fachmann komisch zu klingen. Trotzdem ist ein „tag“ eine Markierung in der Art einer billigen Kopie die schreibgeschütz markiert wird und ein „branch“ eine Verzeigung in der gleichen Art, jedoch mit der Möglichkeit weitere Änderungen vorzunehmen. Ich denke, dass diese so im Artikel beschrieben werden kann.

Das mir (commit) war kein Versehen, hat aber nichts mit Grammatik sondern mit Typografie zu tun. Satzzeichen, Klammern, werden bei Schriftschnitten in der Regel mit ausgezeichnet. Beispiel: Ist dies ein Punkt? Falsch ist: Nein, ein Fragezeichen! Ändere ruhig den Artikel nochmal.

Gruß --Thornard, ^Diskussion, 22:17, 13. Mär. 2009 (CET)

(Sonstiges) Angebliche Probleme mit Umlauten

„Die aktuelle Subversion-Version hat lediglich Probleme auf Mac OS X, da dessen Dateisystem z. B. Umlaute als zwei Zeichen speichert (etwa „a“ + „¨“[5]), während Windows und Linux nur ein Zeichen benutzen (etwa „ä“). Man kann die unter Mac OS X hinzugefügten Dateien zwar unter Windows abrufen, aber die Umlaute bestehen intern dann auch aus zwei Zeichen, werden aber wie „normale“ Umlaute beispielsweise im Explorer angezeigt. Da man trotzdem Dateien mit „normalen“ Ein-Zeichen-Umlauten anlegen kann, ist es so möglich, zwei gleich aussehende, aber intern vom Namen her unterschiedliche Dateien in demselben Verzeichnis unter Windows zu haben.“

– rev. 61522917

... das ist natürlich ein inherentes Problem von Subversion und überhaupt von allen Tools, die so freundlich sind, den Dateinamen nicht einfach so zu ändern, und muss deshalb sofort als Nachteil der Software angeführt werden.

Ich bin dafür, dass es entfernt wird. Was meint der Rest dazu?

(bin übrigens Fan von git, und will hier keineswegs SVN schönreden, aber das hier ist doch irgendwie nur wahlloses Bashing.)S

--93.130.180.135 15:59, 28. Jun. 2009 (CEST)

Wenn es wirklich so ist, dann ist es kein inherentes Problem, sondern ein Bug, weil die Kodierung von Dateinamen nicht plattformunabhängig geschieht. Ich streiche den Absatz trotzdem, weil die Angaben weder belegt sind (Links ins Bugtracking von Subversion?), noch ist ein solches Detailproblem einen ganzen Absatz wert. --Gflohr 07:11, 24. Jul. 2009 (CEST)

kdesvn - In Dateibrowser integriert?

Ich benutze kdesvn und es hat zwar eine Extra Oberfläche ist aber auch in Dolphin (dem Dateibrowser von KDE) integriert. Möglicherweise sollte es bei "Integriert in Dateibrowser" eingeordnet werden? --217.81.85.124 20:51, 26. Okt. 2009 (CET)

NetBeans nun von Oracle?

Bei dem Abschnitt "Integriert in Entwicklungsumgebungen:" wird geschrieben, dass "NetBeans von Sun Microsystems" kommt. Da Oracle jedoch Sun aufgekauft hat, müsste man das doch ändern, oder? --NaitSirch 13:10, 29. Apr. 2011 (CEST)

Pristine?

Was hat es eigentlich mit diesem Namen auf sich? Was und wozu es ist, ist klar, aber warum heißt es pristine und nicht sabine, gaby oder yvonne? F. (nicht signierter Beitrag von 195.81.26.148 (Diskussion) 13:27, 15. Mai 2012 (CEST))

Pristine is Englisch und heisst unverändert (Siehe zum Beispiel: http://dict.leo.org/ende?lp=ende&lang=en&search=pristine). Im Zusammenhang mit svn meint die pristine copy eine unveränderte Kopie des letzten Commits im lokalen Arbeitsverzeichnis. --Boemmels (Diskussion) 14:53, 30. Aug. 2012 (CEST)

Versionsschema

Die Aussage "exakte Version des gesamten Projektes" ist m.E. nicht ganz treffend, denn das Projekt oder Produkt kann eine andere Versionsnummer haben als das Repository. Korrekter wäre "exakte Version des Projektarchivs". Aber Achtung: auch die Kenntnis einer Revisionsnummer kann nicht sicherstellen, dass ein identisches Produkt wieder gebaut werden kann. a) es muss zusätzlich die bekannt sein, ob das Produkt vom trunk oder einem branch gebaut wurde und b) können lokale Änderungen vorgenommen sein, insbesondere dann, wenn das Produkt nicht per Continuous Integration gebaut wird.

Kann diese Information noch geschickt in den Abschnitt integriert werden? 80.254.155.51 13:56, 2. Mär. 2015 (CET)

Stimmt - das wäre korrekter. Habs eingebaut

Das nach "Achtung" würde ich aber nicht einbauen. Hier gehts nicht darum, ob aus einem Repository ein Produkt gebaut werden kann (da gibt es noch viel mehr Möglichkeiten warum sowas nicht funktionieren könnte). --Sebastian.Dietrich ✉ 21:08, 2. Mär. 2015 (CET)