Portablen SVN-Server ?

[stho]

Halli hallo...
Ich suche nach einem Portablen SVN-Server.
Sprich:
Ich habe einen USB-Stick auf dem ich gerne immer meine aktuellen Sourcen haben möchte.
So, nun arbeite ich aber zuhause am Computer an einem Projekt, unterwegs auf dem Laptop und wenn
ich meine Familie besuch auch dort an einem 3ten Rechner.
Diese befinden sich alle 3 weder in einem LAN noch in einem VLAN.
Ich möchte meine Sourcen NICHT im Internet auf irgend einer Seite oder einem Server ablegen, da ich nicht immer
Netz-zugang habe.

Auf den Arbeits-Systemen darf auch gerne ein SVN-Client wie TortoiseSVN installiert werden...


Welche Möglichkeiten habe ich da?
Kennt ihr vielleicht einen Tipp oder ein Programm nach welchem ich mal schauen kann?

Vielen Dank schonmal :thumb:

[Die Muhkuh]

Für Dich scheint eher ein DSCM interessant zu sein, wie Git.

[stho]

DSCM?
Ich vermute mal "Data SourCe Management"... oder?
Wenn diese Lösung den Abgleich von Quellcode beherrscht und Portable benutzt werden kann gerne ;)
Es ist halt mühselig jedes mal den kompletten Quellcode rüber und nüber zu kopieren, nur weil man 1 Datei verändert hat :|

[schlecki]

wenn du nur alleine auf dem Projekt arbeitest, brauchst du nicht zwingend einen Server, du kannst die Reps auch lokal verwenden...

Beispiel:

Ordner anlegen, Rechtsklick drauf, "TortoiseSV/Create repository here", dann erzeugt er dir ein lokales Rep. Den Ordner wieder mit Rechts anklicken "TortoiseSVN/Repo-Browser" und schon kannst du von hier aus anlegen, importieren und auch auschecken...

[Uwe Raabe]

Zitat:

Zitat von stho (Beitrag 1068926)

DSCM?
Ich vermute mal "Data SourCe Management"... oder?

"Distributed Source Code Management"

Kurz: Jeder Rechner hat sein eigenes Repository, die untereinander abgeglichen werden.

Neben Git sollte man sich auch Mercurial ansehen.

[s.h.a.r.k]

Git wäre hier voll und ganz ausreichend. Da brauch man keinen Server, um was pushen. Leg ein Repo auf dem Stick an und das reicht schon voll und ganz für die Versionskontroller aus :) Mehr brauch man gar nicht.

Wüsste grad gar nicht mal mehr, ob SVN das auch kann :gruebel:

[Lemmy]

Hi,

Zitat:

Zitat von s.h.a.r.k (Beitrag 1068991)

Wüsste grad gar nicht mal mehr, ob SVN das auch kann :gruebel:

warum soll svn das nicht können? dem ist doch auch wurscht wo das Repository liegt...
[edit] lediglich wechselnde Laufwerksbuchstaben des Sticks könnten nervig sein...[/edit]

kleine Frage zu git: Ich müsste hier aber immer 2x commiten - oder habe ich da was übersehen?
Stick: portables Repository, lokale HDD Arbeitsrepository. Wenn ich dann im Code Änderungen vornehme, dann muss ich das erst mal ins lokale ArbeitsRep commiten und von dort auf den Stick commiten. Richtig oder aheb ich da was übersehen?

GRüße

[s.h.a.r.k]

Jo, das stimmt. Beim ersten Mal (Commit) übernimmst du die Änderungen ins lokale Repository und beim zweiten Mal (Push) übernimmst du die Änderungen in den das Remote Repository (oder wie sich das Ding nennt). So hast eben den Vorteil, dass du lokal mehrmals committen und diese Änderungen später auf einmal übernehmen kannst.

[Assarbad]

Zitat:

Zitat von Lemmy (Beitrag 1068996)

kleine Frage zu git: Ich müsste hier aber immer 2x commiten - oder habe ich da was übersehen?

Ähem nein?! Wieso?

Und das nicht nur, weil Commit und Push/Pull zwei komplett unabhängige Befehle sind.

Zitat:

Zitat von Lemmy (Beitrag 1068996)

Stick: portables Repository, lokale HDD Arbeitsrepository. Wenn ich dann im Code Änderungen vornehme, dann muss ich das erst mal ins lokale ArbeitsRep commiten und von dort auf den Stick commiten. Richtig oder aheb ich da was übersehen?

Warum nicht direkt vom Stick arbeiten? Klar, wenn man bspw. als Konvention innerhalb eines Teams über ein zentrales Repo arbeitet, ist das was anderes. Auch wenn man lokale Klone einer Branch bevorzugt (was bei Git aber nicht wirklich "notwendig" ist, bei Hg fand ich Branches zu unkomfortabel gelöst in TortoiseHg) dann auch. Aber man muß doch deswegen zwischen Stick und Platte nix push/pull-en!?

Nachtrag: Übrigens scheint SCM eher der alte Name zu sein, der von kommerziellen Anbietern bevorzugt wurde und (D)VCS ((Distributed) Version Control System) scheint sich immer mehr zu verbreiten, Ich stütze das mal ganz frech auf die Lektüre des Hg- und des Git-Buches.

[Lemmy]

@Shark: Danke!

Zitat:

Zitat von Assarbad (Beitrag 1069012)

Zitat:

Zitat von Lemmy (Beitrag 1068996)

kleine Frage zu git: Ich müsste hier aber immer 2x commiten - oder habe ich da was übersehen?

Ähem nein?! Wieso?

Und das nicht nur, weil Commit und Push/Pull zwei komplett unabhängige Befehle sind.

Sorry, ich habe die letzten Jahre mit SVN gearbeitet und kenne halt nur von dort die Bezeichnungen. Es bleibt aber dabei: Wenn ich eine Änderung mache, muss ich die zuerst ins lokale Repository speichern und dann erst ins "Server"-Repository.

Der GRund warum ich darauf rumreite: wenn ich alleine arbeite, dann ist mir SVN lieber, weil ich das dort auch als Backup einsetze, d.h. ich habe einen Server auf dem die Repositories liegen. und ich kann mit einem Befehl das Zeug versionieren und auf einem anderen PC speichern....

Bei einem Team würde ich heute definitiv Mercurial oder git einsetzen

Zitat:

Zitat von Assarbad (Beitrag 1069012)

Warum nicht direkt vom Stick arbeiten?

Frag mich nicht. WÜrde ich in dem Fall vermutlich auch machen - außer es wäre ein großes Projekt und ein langsamer Stick....

GRüße

[s.h.a.r.k]

[OT] Da hab ich neulich einen Stick für USB 3.0 gesehen mit bis zu 130MB/s schreiben :mrgreen: Selbst wenn es nur ein viertel davon wäre, reicht das voll und ganz aus [/OT]

[himitsu]

Das Problem ist, daß selbst USB 2.0 nicht voll ausgenutzt wird ... viele USB-Sticks würden mit dem 3.0er nicht mehr hinbekommen, da die Speicherchips und nicht die Datenleitung den Engpaß darstellen :?

PS: portable SVN, oder gleich direkt zu den Portable Apps

[mleyen]

Das ist aber kein portable Server, sondern der Client.

[himitsu]

ups :oops:

Aber notfalls kann man sich soeine portable App ja selber erstellen. :stupid:

[Assarbad]

Zitat:

Zitat von Lemmy (Beitrag 1069022)

Es bleibt aber dabei: Wenn ich eine Änderung mache, muss ich die zuerst ins lokale Repository speichern und dann erst ins "Server"-Repository.

Git oder Mercurial zwingen dich nicht dazu. Wenn das aber dein Arbeitsmodus ist, ja du mußt erst ins lokale Repo committen und dann zwischen dem entfernten und dem lokalen synchronisieren. Aber mit ein paar Skripten wäre auch eine Automatisierung kein Problem. Allerdings ist ja der Vorteil von DVCS gerade, daß sie nicht erfordern, daß du ständig "online" bist.

Zitat:

Zitat von Lemmy (Beitrag 1069022)

Der GRund warum ich darauf rumreite: wenn ich alleine arbeite, dann ist mir SVN lieber, weil ich das dort auch als Backup einsetze, d.h. ich habe einen Server auf dem die Repositories liegen. und ich kann mit einem Befehl das Zeug versionieren und auf einem anderen PC speichern....

Hier würde ich widersprechen. Ein volles Backup hast du bei SVN eben nur auf der Serverseite (egal wo die ist und wie diese aussieht). Bei Git & Co. hättest du mindestens soviele Backups wie Teammitglieder. Bzw. bei der Konvention es auf einen Server zu schieben sogar (Teammitglieder + 1). Vergiß nicht, bei SVN ist deine Arbeitskopie keinesfalls ein vollständiges Backup der Versionshistorie.

Zitat:

Zitat von Lemmy (Beitrag 1069022)

Frag mich nicht. WÜrde ich in dem Fall vermutlich auch machen - außer es wäre ein großes Projekt und ein langsamer Stick....

Hmm, stimmt auch wieder. Die können recht langsam sein.

Gruß zurück.

[Lemmy]

Zitat:

Zitat von Assarbad (Beitrag 1069059)

Zitat:

Zitat von Lemmy (Beitrag 1069022)

Der GRund warum ich darauf rumreite: wenn ich alleine arbeite, dann ist mir SVN lieber, weil ich das dort auch als Backup einsetze, d.h. ich habe einen Server auf dem die Repositories liegen. und ich kann mit einem Befehl das Zeug versionieren und auf einem anderen PC speichern....

Hier würde ich widersprechen. Ein volles Backup hast du bei SVN eben nur auf der Serverseite (egal wo die ist und wie diese aussieht). Bei Git & Co. hättest du mindestens soviele Backups wie Teammitglieder. Bzw. bei der Konvention es auf einen Server zu schieben sogar (Teammitglieder + 1). Vergiß nicht, bei SVN ist deine Arbeitskopie keinesfalls ein vollständiges Backup der Versionshistorie.

LOL Sorry Asserbad. Nochmal: SVN nutze ich wenn ich alleine bin. In einem Team würde ich definitv zu Mercurial oder Git wechseln, weil ich dort genau diese Vorteile sehe...

Wenn ich alleine entwickle, dann bringt mir ein lokales Repository nichts, weil das bei Ausfall einer HDD weg ist. Zudem möchte ich (wenn ich alleine entwickle) kein Repo lokal rumliegen, weil cih in einer VMWare entwickle. Und die will ich hin und wieder auch sichern, was bei einem lokalen Repo nur mehr Zeit und mehr Platz wegnehmen würde aber kaum mehr Sicherheit bietet (in meinem Fall, weil die auch auf den Server kommt...)

Klar habe ich bei SVN lokal kein Backup der Versionshistorie, aber das ist schließlich Aufgabe meines Serverbackups.....


GRüße

[Assarbad]

Zitat:

Zitat von Lemmy (Beitrag 1069062)

LOL Sorry Asserbad. Nochmal: SVN nutze ich wenn ich alleine bin. In einem Team würde ich definitv zu Mercurial oder Git wechseln, weil ich dort genau diese Vorteile sehe...

Okay okay.

[phXql]

Schau dir mal Bazaar an, das ist ähnlich wie Git/Mercurial, und es unterstützt den SVN-ähnlichen Workflow mit nem zentralen Server (schau in die Doku, da sind verschiedene Workflows drin).

Das committen sieht dann so aus:

bzr commit

Damit wird alles in das Server-Repository geschickt. Davon kannst du dann ein Backup ziehen.

[Assarbad]

Zitat:

Zitat von phXql (Beitrag 1069107)

Schau dir mal Bazaar an, das ist ähnlich wie Git/Mercurial, und es unterstützt den SVN-ähnlichen Workflow mit nem zentralen Server (schau in die Doku, da sind verschiedene Workflows drin).

Funktioniert das, wie man es bei Mercurial machen würde, über Hooks?

[phXql]

Hooks? Weiß ich nich, du musst nur:

Server> bzr init-repo --no-trees

Client> bzr checkout [url]

machen, und dann kannste damit wie bei svn arbeiten, bei einem commit wird das alles automatisch an den server gepusht.

[Assarbad]

Ah, jetzt verstehe ich. Dann hatte ich dich nur falsch verstanden.