Private Datei-Versionierung auf dem NAS - GIT oder SVN ?

Für deinen Anwendungsfall ist es wohl vollkommen egal. Git ist im Moment 
wohl etwas "hipper".

Elektroniker schrieb:
> Aufgrund einer Abschlussarbeit kommt der dringende Wunsch nach einer
> privaten Datei-Versionierung.
>
> Arbeitsablauf ist so, das ich zu Hause am PC an Programmcode und Doku
> arbeite. Zu Hause und unterwegs arbeite ich auch noch am Laptop und ab
> und zu auch an einem weiteren stationären PC ausserhalb meines LANs.

"Außerhalb meines LANs" interpretiere ich jetzt mal so, daß du von da 
auch keinen Netzzugang (SSH o.ä.) zu deinem NAS hast?

> Da ich zu Hause ein Synology NAS einsetze, habe ich mir GIT und SVN
> näher angeguckt, da Synology da fertige Pakete anbietet.
>
> Die Funktion die ich benötige ist folgende: Datei vom Server holen (hier
> liegt immer die aktuellste Version), bearbeiten und wieder
> zurückschicken.

Du wirst auch noch folgende Funktionen haben wollen:

- prüfen ob die lokalen Files noch aktuell sind
- unterschiede zwischen lokalen Files und dem aktuellenen Stand im 
Repository anzeigen
- lokale und Repository Versionen mergen

> Nun versuche ich herauszufinden welches Versionierungssystem besser
> geeignet wäre.
>
> Den zentralen Unterschied habe ich so verstanden:
> Bei SVN checke ich Dateien aus, bearbeite diese und checke diese wieder
> ein. Bei GIT ziehe ich mir ne Kopie des kompletten Projekts auf den
> lokalen Rechner, bearbeite die Dateien und Synchronisiere es
> anschließend wieder mit dem Server.

Jein. Auch mit Git checkst du lokal aus. Der Unterschied ist, daß bei 
Git zusätzlich noch die gesamte History lokal vorliegt.

> So gesehen wäre SVN die bessere wahl, oder hab ich was entscheidenes
> übersehen?

Hast du. Mit SVN kannst du ohne Netzwerkverbindung nur an lokalen Files 
arbeiten. Es funktioniert weder svn status noch svn diff noch svn 
checkout oder svn checkin. Am meisten wird dir vermutlich das letzte 
fehlen. Denn auch wenn man entfernt von daheim arbeitet, wird man hin 
und wieder Zwischenstände einchecken wollen, damit man im Fall des 
Falles dahin zurückrollen kann.

Mit Git hast du die gesamte History dabei. Die lokal erzeugte immer 
komplett, die von anderen Checkouts erzeugte nur insofern wie du sie 
synchronisiert hast. Du kannst auch immer lokal einchecken, ohne dazu 
Verbindung zum parent Repository zu brauchen.

Langer Rede kurzer Sinn: Git ist für dich besser.

Auch mit SVN holst du dir das ganze Projekt aus dem Repository, und 
checkst es wieder ein.

Ansonsten, wie schon gesagt wurde, ist es Geschmackssache. Die Vorteile 
von Git bei Multi-User-Parallelentwicklung kommen bei dir nicht zum 
tragen, daher nimm, was dir besser gefällt.

Oliver

Git hat meiner Meinung nach nur Vorteile gegenüber SVN. Mit Git kannst 
du auch SVN Repos auschecken. Der große Vorteil ist das lokale Repo, du 
hast quasi überall den gesamten Stand. Raucht dein Server ab, packst du 
deinen GIT Ordner auf einen zweiten Server und weiter gehts ;)
Außerdem kannst du problemlos lokal einchecken, mergen, branchen, ohne 
online sein zu müssen. Das heißt du checkst deine Daten ein ('committen' 
heißt das bei git) und schreibst was kurzes dazu, wann immer du das 
Gefühl hast, dass ein neuer Versionsstand erreicht ist. Und sei es nur 
zu Backupzwecken.
Willst du was großes ausprobieren, erstellst du einen Branch und checkst 
den aus, ohne dass du - wie bei SVN - z.B. neue Ordner oder sowas 
erstellen müsstest.
Das funktioniert alles prächtig mit der Git Bash oder einer grafischen 
Geschichte wie Tortoise GIT oder so.

Und solange du nur alleine auf deinem Repo arbeitest musst du viele 
Sachen die sonst wichtig wären gar nicht beachten (History umschreiben 
und veröffentlichen z.B. ist gar nicht schön)

Schöne Grüße,
Jan

Git ist so eine Fanboy-Sache. Wie man schon an Sprüchen wie

Tom schrieb:
> Git ist (im Softwarebereich) die Zukunft.

sehen kann. Der Weg der Informatik zur Hölle ist mit tausenden von 
Technologie-Leichen gepflastert, die alle mal "die Zukunft" waren.

Das ist irgend so eine Art Gendefekt der Informatik. Auch wenn etwas 
funktioniert muss es unbedingt in ein paar Jahren durch etwas neues 
ersetzt werden. Nicht weil das Neue besser ist (meist ist es nur ein 
Haufen stinkender Müll), sondern weil es neu ist.

Wenn niemandem in der Informatik gerade etwas Neues einfällt, wird was 
altes umbenannt und als neue Sau durchs Dorf getrieben.

SVN funktioniert seit Jahren problemlos und wunderbar. Getreu der 
allgemeinen Philosophie der Informatik muss es daher weg. Git ist geil 
wenn man seinen Quelltext auf zig lokalen Repositorien verbummeln 
möchte, auf denen man den Überblick verliert, wenn man irgendwann nicht 
mehr weiß was an Tree 0dea46e42f0625246c3d06a71d6559eaec5419ca Head 
07f2039(ja, reales Beispiel) denn so besonders war.

Bitbucket bietet unbegrenzt viele private Repos.

Falls gewünscht:
Dazu gibts noch einen super Client (SourceTree) für Win/Mac/(Linux?).

Wenn du ssh-Zugriff auf irgendeinen Server hast, ist git trivial 
einzurichten und zu benutzen. Einfach auf dem Server in /pfad
git init .
und dann auf dem Client
git remote add origin ssh://user@server:/pfad
Fertig.

Kann ich empfehlen, ist sehr praktisch.

Hannes Jaeger schrieb:
> Git ist so eine Fanboy-Sache.

Nein.

> Wie man schon an Sprüchen wie
>> Git ist (im Softwarebereich) die Zukunft.
> sehen kann.

Diese Begründung ist sicher schlecht. Trotzdem ist Git klar besser als 
SVN, insbesondere wenn man offline arbeiten können will.

> SVN funktioniert seit Jahren problemlos und wunderbar.

SVN hat schon immer die Einschränkung, daß man für viele (zu viele) 
Operationen eine Netzwerkverbindung zum zentralen Repository-Server 
braucht. Deswegen wurden schon lange (auch vor Git) Alternativen 
entwickelt, die diese Einschränkung nicht haben. Bekannt sind Bitkeeper, 
Mercurial, Bazaar und eben Git.

Und wenn der TE die Wahl zwischen SVN und Git hat und die Anforderung, 
offline arbeiten zu können, dann ist Git nun mal die bessere Wahl. 
Vollkommen unabhängig davon ob du es magst oder auch nur verstehst.