Codeverwaltung bei 2 Arbeitsplätzen

[Berni68]

Hallo zusammen,

wie kann ich einfach ein Projekt verwalten, das ich an 2 Standorten
(zuhause und Arbeisstelle) programmieen will.

Hab mal tortoisesvn angeschaut, aber das löst das Problem nicht wirklich,
da ich keinen svn-Server habe (Oder gibt's den wo umsonst?).
Ich könnte zwar das repository auf einen USB-Stick tun, aber da kann ich letztendlich gleich auf dem USB-Stick die Source-Dateien halten.
Aber dann ist man immer auf den Stick angewiesen.

Gibt es da was einfaches unkompliziertes?

[mkinzler]

Z.B. einen Dienst wie Dropbox, Box.net o.ö.

[Uwe Raabe]

http://www.fogcreek.com/kiln/

Basiert auf Mercurial und ist in der "Student and Startup Edition" bis zwei User frei. Dafür bekommt man dann auch noch den passenden FogBugz-Zugang.

Der Vorteil von Mercurial (eigentlich jedes DVCS) gegenüber Subversion ist, daß man seine Versionsverwaltung mit der ganzen Historie immer auf dem Rechner dabei hat. Branchen und Mergen geht einfach, während gerade das Mergen unter Subversion ein Horror ist.

Einfach mal ausprobieren.

[Berni68]

Erst mal Danke für die Antworten.
Ich denke, ich bin mal 'ne Weile mit probieren und testen zugange.

Gruß
Bernhard

[newbe]

Auf Clound dienste wie Dropbox solltest du nur gut verschlüsselte Daten ablegen (AES256 Bit) mit langem komplexen Schlüssel. Sonst würde ich dir als Arbeitgeber gewaltig vor den karren Scheisen.

sorry das ich das jetz so direkt ausgedrückt habe, aber ich wollt es halt mal anmerken.
Dieser hinweis hat mir im Post von mkinzler den ich normalerweise sehr schätze aber noch gefehlt

mfg newbe

[mkinzler]

Davon bin ich stillschweigend ausgegangen. Dropbox unterstützt und empfielt sogar TrueCrypt zu verwenden.

[himitsu]

Zitat:

Zitat von mkinzler (Beitrag 1111038)

Davon bin ich stillschweigend ausgegangen. Dropbox unterstützt und empfielt sogar TrueCrypt zu verwenden.

Jupp, war auf deren Startseite auch rauszuhören, aber sonst?

> Alle Dateien sind zwar verschlüsselt, allerdingt nur serverseitig und man hat auf den Schlüssel keinen Zugriff. (ist also quasi unverschlüsselt)
> Die Dateiübertragung ist somit schonmal ungeschützt und die Firma selber hat sowieso vollen Zugriff.
> Ein US-Unternehmen, womit mindestens deren Regierung auch Zugriff hat.
> Wie das mit einem sicheren Zugriff aussieht, kann ich nicht sagen, aber wo das System scheinbar eh mehr auf einen FileSharingService ausgelegt ist... (jedenfalls laut dem Video)

Aber scheinbar kann man die Dropbox auch auf einem eigenen Server verwalten und muß nicht unbedingt deren Server nutzen.
Bleibt dann nur noch die Frage, wie das dort mit einem Fremdzugriff ist. ( Redet die Software dennoch mit seiner Heimatfirma? )

[blackfin]

Zitat:

Hab mal tortoisesvn angeschaut, aber das löst das Problem nicht wirklich,
da ich keinen svn-Server habe (Oder gibt's den wo umsonst?).

Sourceforge.net, GoogleCode, Unfuddle, GitHUB und co. kosten nichts und haben Versionsverwaltungen (Sourceforge z.B. SVN).

Die Projekte dort müssen ja nicht öffentlich sein, es gibt auch private Projekte mit nicht-öffentlichem Repository.
Bei manchen glaube ich sind sogar die kostenlos.

Edit:
Habt ihr auf Arbeit keinen Server, der ins Internet "spricht"?
Ein SVN-Server ist nämlich sowohl auf Linux- und auch Windows-Kisten ziemlich schnell installiert.
Und falls da der SysAdmin murren sollte: Man kann das ganze ja über SSH tunneln, das sollte den zufriedenstellen :-)
Was mir auch noch einfällt: Redmine! Da hast du eine komplette Projektverwaltung mit SVN-Server (mit Auth), Ticketing-System usw.
Ist auf Linuxkisten auch schnell installiert, wie ich von meinem Lieblingshoster weiss :-)

Edit II:
Es gibt aber natürlich auch noch eine ganz simple Methode, wenn nur du am Projekt arbeiten solltest:
Du legst den Quellcode einfach auf einem USB-Stick oder einer mobilen Harddisk ab :stupid:

[Meflin]

Zitat:

Zitat von himitsu (Beitrag 1111040)

Aber scheinbar kann man die Dropbox auch auf einem eigenen Server verwalten und muß nicht unbedingt deren Server nutzen.

Seit wann das denn? Also zumindest offiziell gibt es dafür keinerlei Konfigurationsmöglichkeit.

Ich würde noch Git + Github in den Raum werfen. DER Komfort machte sogar mich zum VCS-Benutzer :stupid: Wenn der Code nicht öffentlich zugägnlich sein soll und du nicht den letzten A* als Arbeitgeber hast zahlt der dir sicher auch was, damit du da private Repositories bekommst ;-)

[mkinzler]

Man kann aber einen TrueCrypt-Container dort ablegen, dieser wird dann clientseitig verschlüsselt und trotzdem werden nur Änderiunegn übertragen.

Zitat:

Die Dateiübertragung ist somit schonmal ungeschützt

Die Übertragung erfolgt über SSL, alos verschlüsselt.

Dropbox und Co. sind mehr als eine FileSharing-Service. Es wird ein loakles Verzeichnis mit dem entferneten FileStorage synchronisiert. Das kann man auf mehreren Rechnern einrichten, so dass man dadurch Verzeichnisse auf verschiedenen Rechnern synchron halten kann. Man hat natürlich auch die Möglichkeit Dateien für andere freizugeben, was du wohl mit FileSharing meinst.

[himitsu]

Zitat:

Zitat von Meflin (Beitrag 1111042)

Seit wann das denn? Also zumindest offiziell gibt es dafür keinerlei Konfigurationsmöglichkeit.

Zitat:

Zitat von http://de.wikipedia.org/wiki/Dropbox

Seit der Version 0.7 synchronisiert Dropbox Dateien direkt im lokalen Netzwerk: LAN sync ermöglicht so eine deutlich schnellere Synchronisation der Daten von Rechnern, die bereits lokal miteinander verbunden sind, da der Umweg über die Dropbox-Server ausbleibt.

Vielleicht hab ich's auch nur falsch verstanden, aber zumindestens klingt das für mich so.

[mkinzler]

Seine beiden Rechner, stehen aber nicht in einem Netzwerk. Dann würde auch eine Netzwerkfreigabe oder eine VCS-Server reichen.

[HeZa]

Zitat:

Zitat von Uwe Raabe (Beitrag 1111034)

Der Vorteil von Mercurial (eigentlich jedes DVCS) gegenüber Subversion ist, daß man seine Versionsverwaltung mit der ganzen Historie immer auf dem Rechner dabei hat.

Da ich seit einem Jahr mit einem Notebook zwischen Arbeit und Zuhause hin und her wandere und auch mal unterwegs arbeite, ist mir dieses Problem von SVN auch schon aufgefallen.

Zitat:

Branchen und Mergen geht einfach, während gerade das Mergen unter Subversion ein Horror ist.

Bei uns müssen öfter mal größere Zweige zusammen gemergt werden und ich kann nur bestätigen, dass das mit SVN nicht immer ein Spaß ist. Aber warum ist mergen unter Mercurial einfacher?

[Uwe Raabe]

Zitat:

Zitat von HeZa (Beitrag 1111048)

Bei uns müssen öfter mal größere Zweige zusammen gemergt werden und ich kann nur bestätigen, dass das mit SVN nicht immer ein Spaß ist. Aber warum ist mergen unter Mercurial einfacher?

Ohne das jetzt genauer analysiert zu haben (bitte ggf. um Korrektur): SVN vegleicht beim Merge die Änderungen beider Zweige zur gemeinsamen Stamm-Revision, wobei die jeweiligen inkrementalen Änderungen unberücksichtigt bleiben. Mercurial verwaltet immer die Änderungen zur vorigen Version und wendet diese beim Merge nacheinander an. Damit lassen sich sogar Dinge machen, bei denen Änderungen eines Branches in eine Datei gemerged werden, die in dem anderen Branch umbenannt wurde.

Was einem auch enorm die Arbeit erleichtert: ich bin mit meinem Notebook bei mehreren Kunden (keinen Zugriff aufs Internet oder einen sonstigen SVN-Server) und kann trotzdem die Versionsverwaltung benutzen (vor Ort macht man ja schon manchmal Mist, den man wieder rückgängig machen möchte). Ich kann für jeden Kunden einen Clone anlegen, mit dem ich ein paar Sachen ausprobiere und hinterher dann entscheiden, welche Änderungen ich wie in das zentrale Repository übernehmen möchte.

[HeZa]

Zitat:

Zitat von Uwe Raabe (Beitrag 1111050)

SVN vegleicht beim Merge die Änderungen beider Zweige zur gemeinsamen Stamm-Revision, wobei die jeweiligen inkrementalen Änderungen unberücksichtigt bleiben. Mercurial verwaltet immer die Änderungen zur vorigen Version und wendet diese beim Merge nacheinander
an.

Hmm, ich denke ich sollte das einfach mal aus ausprobieren. :-D

Zitat:

Damit lassen sich sogar Dinge machen, bei denen Änderungen eines Branches in eine Datei gemerged werden, die in dem anderen Branch umbenannt wurde.

Das ist auf jeden Fall schon mal ein Vorteil den ich nachvollziehen kann.

Zitat:

Was einem auch enorm die Arbeit erleichtert: ich bin mit meinem Notebook bei mehreren Kunden (keinen Zugriff aufs Internet oder einen sonstigen SVN-Server) und kann trotzdem die Versionsverwaltung benutzen (vor Ort macht man ja schon manchmal Mist, den man wieder rückgängig machen möchte). Ich kann für jeden Kunden einen Clone anlegen, mit dem ich ein paar Sachen ausprobiere und hinterher dann entscheiden, welche Änderungen ich wie in das zentrale Repository übernehmen möchte.

Diese Funktion habe ich beim SVN auch schon schmerzlich vermisst.

Gibt es denn eine einfache Möglichkeit z.B einen VisualSVN-Server mit mehreren Repositories nach Mercurial umzuziehen?

[Uwe Raabe]

[QUOTE=HeZa;1111717Gibt es denn eine einfache Möglichkeit z.B einen VisualSVN-Server mit mehreren Repositories nach Mercurial umzuziehen?[/QUOTE]

Ganz allgemein: hg convert

Speziell für Kiln gibt es ein spezielles KilnImport Utility, das einem die meiste Arbeit abnimmt. Nur wenn das Repository-Layout nicht dem Standard entspricht oder nur bestimmte Teile importiert werden sollen, muss man selbst Hand anlegen.

[HeZa]

Zitat:

Zitat von Uwe Raabe (Beitrag 1111729)

Ganz allgemein: hg convert

Danke. Schaue ich mir an.

Zitat:

Speziell für Kiln gibt es ein spezielles KilnImport Utility, das einem die meiste Arbeit abnimmt. Nur wenn das Repository-Layout nicht dem Standard entspricht oder nur bestimmte Teile importiert werden sollen, muss man selbst Hand anlegen.

Kiln kenne ich nur aus dem Video mit Spolski. Arbeitest du damit und hast ein erstes Fazit? Das Video fand ich sehr interessant.

[Uwe Raabe]

Zitat:

Zitat von HeZa (Beitrag 1111745)

Kiln kenne ich nur aus dem Video mit Spolski. Arbeitest du damit und hast ein erstes Fazit? Das Video fand ich sehr interessant.

Ja ich arbeite damit und bin sehr zufrieden. Man muss seine Denk- und Arbeitsweise halte erstmal umstellen. Es war immer ein Problem, wenn man unterwegs keinen Zugriff auf seinen SVN-Server hatte. Am Ende hat man dann halt doch wieder eine lokale Kopie auf der Festplatte angelegt und die Versionen von Hand abgeglichen.