Das deutsche Python-Forum

Nun hab ich mal ein neues Sammel SVN Repository eingerichtet: http://code.google.com/p/small-py-utils/

Ich hab bisher vieles im PyLucid SVN Abgelegt: http://trac.pylucid.net/browser/CodeSnippets

Nun möchte ich gern die CodeSnippets Geschichten in small-py-utils transferieren.

Am besten wäre es natürlich, wenn die History dabei mit verschoben werden würde!

Ist das möglich???

jens hat geschrieben:Am besten wäre es natürlich, wenn die History dabei mit verschoben werden würde!

Du kopierst das PyLucid-Repo und löscht alles andere Raus und verschiebst deine Snippets in root.

Aber eigentlich finde ich, dass ein Repo für alle Projekte ein ziemliches Antipattern ist (hier klicken um Rant über SVN hinzuzufügen). Wenn ich mir ansehe was KDE und die ASF da macht, dann muss ich mir immer an den Kopf fassen. Habe mit ein kleines Sandbox-Repo für Snippets gemacht und meine SVN-Projekte aus einem Repo in verschiedene Mercurial-Repositories konvertiert (unter Beibehaltung der jeweiligen History).

Leonidas hat geschrieben:Aber eigentlich finde ich, dass ein Repo für alle Projekte ein ziemliches Antipattern ist (hier klicken um Rant über SVN hinzuzufügen).

Für Git, Mercurial und Konsorten ist das richtig, aber warum sollte man bei Subversion nicht mehrere Projekte in einem Repository hosten? Schließlich ist ein Subversion-Repository nicht gleichzusetzen mit einem Git oder Mercurial-Repository.

lunar hat geschrieben:Für Git, Mercurial und Konsorten ist das richtig, aber warum sollte man bei Subversion nicht mehrere Projekte in einem Repository hosten? Schließlich ist ein Subversion-Repository nicht gleichzusetzen mit einem Git oder Mercurial-Repository.

Zum Beispiel größere Datensicherheit (wenn einer das Repo aus versehen kaputtmacht müssen nicht alle dran glauben) oder auch Revisionsnummern die etwas mehr Aussagekraft haben (zwischen Revision 1000 und 2000 liegen in einem Projekt recht viele Änderungen, bei SVN kann das auch genau null sein).

Leonidas hat geschrieben:

lunar hat geschrieben:Für Git, Mercurial und Konsorten ist das richtig, aber warum sollte man bei Subversion nicht mehrere Projekte in einem Repository hosten? Schließlich ist ein Subversion-Repository nicht gleichzusetzen mit einem Git oder Mercurial-Repository.

Zum Beispiel größere Datensicherheit (wenn einer das Repo aus versehen kaputtmacht müssen nicht alle dran glauben)

Abgesehen davon, dass man das Repo vom Client aus nicht unbrauchbar machen, sondern höchstens einen Commit verbocken kann (wozu man dann halt auch stehen sollte): Dafür gibt es Backups (die muss man so oder so durchführen).

oder auch Revisionsnummern die etwas mehr Aussagekraft haben (zwischen Revision 1000 und 2000 liegen in einem Projekt recht viele Änderungen, bei SVN kann das auch genau null sein).

Die Revisionsnummer selbst hat keine Aussagekraft. Eine spezifische Datei oder eine spezifische Änderung ist nicht an eine sequentielle Abfolge zweier Revisionsnummern gebunden.

Daher sind Lücken zwischen Revisionsnummern auch dann möglich und auch üblich, wenn ein Projekt ein eigenes Repo hat. Muss man also so oder so ins Log schauen, um die spezielle Änderung zu identifizieren, an der man interessiert ist. Und da sich svn log wie alle anderen SVN-Kommandos nur auf den geklonten Teil des Repos beschränkt, sieht man auch nur die Änderungen des eigenen Projekts.

Deswegen hat Subversion ja auch die Möglichkeit, Änderungen anhand des Änderungszeitpunkts zu identifizieren. Man kann sich also problemlos das Log der letzten zwei Wochen ansehen, um zu sehen, was sich während des eigenen Urlaubs alles geändert hat.

Imho ist diese "ein Repo pro Projekt" Einstellung völlig richtig bei Git oder Mercurial. Subversion verfolgt aber einen anderen Ansatz. Letztlich ist ein Subversion-Repo ja kaum mehr als versioniertes Dateisystem. Und du verteilst deine Datei ja auch nicht thematisch auf verschiedene Dateisysteme, oder?

Wenn es um verschiedene kleine Codeschnipsel geht, könnte vielleicht auch http://gist.github.com interessant sein. Das ist einerseits eines dieser üblichen Paste-Bins. Andererseits kann man die auch per git auschecken und dann ändern. Sogar mehrere Dateien lassen sich zu einem "gist" zusammenfassen. Quasi eine Art Mini-Repository ohne des Aufwand, sie formal aufzusetzen.

Stefan

@Leonidas: Vielleicht etwas Offtopic (in einem Offtopic-Thema ), aber womit hast Du denn von SVN nach Mercurial konvertiert? Mit `tailor`?

BlackJack hat geschrieben:@Leonidas: Vielleicht etwas Offtopic (in einem Offtopic-Thema ), aber womit hast Du denn von SVN nach Mercurial konvertiert? Mit `tailor`?

Ursprünglich ja, aber ``tailor`` ist ein ziemlich kaputter Krampf, so dass ich eher zu ``hg convert`` raten würde (Konversion von CVS und Bazaar funktioniert perfekt, bei SVN hatte ich auch keine Probleme).

@BlackJack
FWIW, birkenfeld hat "hg convert" genutzt, um das SVN-Repository von Sphinx nach HG zu überführen.

@Leonidas & Lunar: Danke! Dann werde ich mir das Installieren von ``tailor`` sparen.

Ich möchte gern mehrere kleine Codeschnipsel in ein SVN zusammen fassen, weil 1.) ich diese in verschiedenen Projekten verwenden will und man sie einfach über svn:externals einbinden kann. 2.) kann man bei google nur max 10 Projekte pro Account anlegen. Außerdem ist es IMHO zu aufwendig für ein paar Kleinigkeiten ein komplett neues Projekt zu eröffnen.
Die Idee mit dem import und löschen von PyLucid ist schon nicht schlecht. Aber ich weiß nicht ob das bei google code überhaupt geht.

Es geht so: http://code.google.com/p/support/wiki/FAQ#Subversion Punkt How do I import an existing Subversion repository?