Am 13.02.2011 13:28, schrieb Martin Schmitt: > Am 13.02.11 11:35, schrieb Silvério Santos: > >> kennst sich jemand mit SourceForge aus? Ich möchte gerne mein SF-Projekt >> http://kfz.sf.net/ per git statt früher Subversion aktualisieren. Dafür >> habe ich das git Modul aktiviert und erwartet, daß der früher per SVN >> commitete Code jetzt per git verfügbar ist, aber bei einem git pull >> erhalte ich einen leeren Ordner. Muß ich den gleichen Code nochmals per >> git committen? Divergieren die Stände zwischen SVN und git dann nicht >> unweigerlich? > > SF meint sicher nicht, daß Du SVN und git parallel nutzen sollst. Mir würde das gefallen.
> Du könntest aber das SF-SVN in ein lokales git bei Dir klonen und dann > Changes immer parallel ins SF-SVN dcommitten und ins SF-git pushen, um > die Versionsstände synchron zu halten. Solche manuellen Dreiecksmethoden führen über kurz oder lang zu Inkonsistenzen: schlecht. Besser wäre natürlich über unterschiedliche Methoden auf den gleichen Datenbestand zugreifen zu können. Das könnte evtl. Probleme wie locking zwischen den Applikationen verhindern. > Ob es einen Grund gibt, das zu tun, statt das SVN wegzuwerfen und in > Zukunft einfach ausschließlich auf git weiterzuentwickeln, müßtest Du > dann aber selbst wissen. ;-) Ja, weiß ich, aber es muß kein Geheimnis bleiben: ich möchte einerseits die Vorzüge von git als verteiltes System mit lokalen Commits nutzen. Andererseits aber konnte ich beim besten Willen das git-Modul von Jenkins nicht zum laufen bringen. Außerdem läuft auf Eclipse das EGit nicht, da werde ich wohl erst den SVN-Client entfernen müssen. Ich hasse es, laufende gegen neue Verfahren umzustellen, ohne die neuen getestet zu haben. Gruß Silvério -- ---------------------------------------------------------------------------- PUG - Penguin User Group Wiesbaden - http://www.pug.org
