# Java-Repository für daheim



## Flaming_Ace (15. Jul 2010)

weiß jemand mit welcher software ich am besten ein Repository laufen lass, so dass im lokalen Netzwerk mehrere benutzer ihre entwicklungen ein- und auschecken können? das ganze sollte am besten unter windows laufen und ressourcen sparend sein.
Versionierungsfunktionalitat wäre auch nicht schlecht.
Kennt jemand Tutorials, wo das einrichten einer solchen software beschrieben ist?

danke im vorraus :rtfm:


----------



## maki (15. Jul 2010)

Du meinst wohl ein Source Repository, oder?

Falls ja, bietet sich zB. SVN an, k.A. ob man den Server auch unter Windows laufen lassen kann.


----------



## Flaming_Ace (15. Jul 2010)

ich bin, was dieses thema betrifft, blutiger anfänger..

ich meine so ein server auf den man mit eclipse verbinden kann, eine klasse auschecken, diese bearbeiten und dann wieder einchecken kann. so dass alle den gleichen workspace sehen.

hatte mich in meinem ersten posting wohl etwas unglücklich ausgedrückt


----------



## Landei (15. Jul 2010)

SVN: Subversion Binary Packages
Sehr praktisch, wenn man nicht extra die IDE hochfahren will: tortoisesvn.tigris.org


----------



## OliverKroll (15. Jul 2010)

Ich habe gerade gestern dasgleiche Problem gehabt.
Ich habe mir den VisualSVN-Server geholt: VisualSVN Server | Subversion Server for Windows
Die Einrichtung des Projekts hat geklappt, ich finde aber im Augenblick die Anleitung nicht.
Es ging ungefähr so:
Repository einrichten auf dem Server
Repository bekanntgeben in Eclipse
Projekt beginnen in Eclipse
Projekt bekanntgeben über Team-Commit
Neuesten Stand holen mit Team-Update


----------



## Flaming_Ace (15. Jul 2010)

OliverKroll hat gesagt.:


> Ich habe gerade gestern dasgleiche Problem gehabt.
> Ich habe mir den VisualSVN-Server geholt: VisualSVN Server | Subversion Server for Windows
> Die Einrichtung des Projekts hat geklappt, ich finde aber im Augenblick die Anleitung nicht.
> Es ging ungefähr so:
> ...



werde das mal im laufe der nächsten tage ausprobieren.
für alle die das thema auch interessiert:
SVN-Server installieren und in EClipsePDT einbinden - wiki.tommy-schmidt.de


----------



## homer65 (15. Jul 2010)

Damit Eclipse mit einem SVN Server zusammenarbeiten kann braucht man ein Plugin.
Ich meine es heißt Subclipse.


----------



## OliverKroll (15. Jul 2010)

Stimmt: subclipse: Subclipse Update Site


----------



## maki (15. Jul 2010)

Ich bin der Meinung, dass das offizielle SVN Plugin für Eclipse, nämlich Subversive, das bessere SVN Plugin für Eclipse ist


----------



## JohannisderKaeufer (15. Jul 2010)

Was ich recht cool finde ist git.

Git ist im gegensatz zu SVN und CVS ein verteiltes Versions-System.

Besonders von Vorteil finde ich die Unabhängigkeit von einem Server, da man eine lokales Repository hat auf dem gearbeitet wird.


----------



## Flaming_Ace (15. Jul 2010)

so habs jetzt mal nach anleitung installiert.. hat super geklappt! danke an alle


----------



## MarderFahrer (16. Jul 2010)

JohannisderKaeufer hat gesagt.:


> Was ich recht cool finde ist git.
> 
> Git ist im gegensatz zu SVN und CVS ein verteiltes Versions-System.
> 
> Besonders von Vorteil finde ich die Unabhängigkeit von einem Server, da man eine lokales Repository hat auf dem gearbeitet wird.



Da hätte ich eine Frage. Wie würde man Git benutzen wenn zwei oder mehr Entwickler an der selben Codebase arbeiten sollen? So wie ich das verstehe hat jeder das komplette Repository auf der Festplatte.
Wie werden da die Änderungen von EntwicklerA and EntwicklerB usw propagiert?
Für so etwas braucht man doch einen zentralen Server, der die Master Sourcen hält. Ansonsten arbeitet doch jeder am anderen vorbei. EntwicklerA arbeitet an Interface Itest1.java. EntwicklerB benutzt das Interface bei seiner Entwicklung. Jetzt ändert EntwicklerA das ganze Interface komplett ab. Wie soll das EntwicklerB mitkriegen? Er arbeitet weiter an seiner Entwicklung in der Annahme, dass alles noch so ist wie früher. Bei ihm sind die Sourcen ja auch wie früher.
Da sich beim EntwicklerA aber einiges am Interface geändert hat, kann man doch nicht mehr von einer Codebase sprechen.


----------



## Landei (16. Jul 2010)

Na ja, eine Codebase wird halt als das Hauptrepository angesehen, obwohl formal alle gleichberechtigt sind. 

Anstatt git würde ich übrigens Mercurial nehmen. Es gibt TortoiseHg dafür, und Google Code unterstützt es auch.


----------



## JohannisderKaeufer (16. Jul 2010)

MarderFahrer hat gesagt.:


> Da hätte ich eine Frage. Wie würde man Git benutzen wenn zwei oder mehr Entwickler an der selben Codebase arbeiten sollen? So wie ich das verstehe hat jeder das komplette Repository auf der Festplatte.
> Wie werden da die Änderungen von EntwicklerA and EntwicklerB usw propagiert?
> Für so etwas braucht man doch einen zentralen Server, der die Master Sourcen hält. Ansonsten arbeitet doch jeder am anderen vorbei. EntwicklerA arbeitet an Interface Itest1.java. EntwicklerB benutzt das Interface bei seiner Entwicklung. Jetzt ändert EntwicklerA das ganze Interface komplett ab. Wie soll das EntwicklerB mitkriegen? Er arbeitet weiter an seiner Entwicklung in der Annahme, dass alles noch so ist wie früher. Bei ihm sind die Sourcen ja auch wie früher.
> Da sich beim EntwicklerA aber einiges am Interface geändert hat, kann man doch nicht mehr von einer Codebase sprechen.



Nimm mal an du machst was Richtung MVC. 
Als erstes erweiterst du das Model. Dann würdest du dieses committen.
Als nächstes wäre der Controller dran. Dann würde dieser committet.
Und zum Schluß gehts an die Views. Nun werden diese committet.

Diese Arbeit ist jetzt abgeschlossen und man könnte einen patch erstellen der alle Änderungen beinhaltet oder auf einen zentralen "master" pushen. Der patch ist eine ganz normale Datei, die man auch beispielsweise per email oder usbstick weiterverbreiten kann.

Für A ist es praktisch, einzelne Commits zu haben, für B macht das feingranulare wenig Sinn, da er nur was damit anfangen kann wenn alle 3 Sachen abgeschlossen sind.


----------



## MarderFahrer (16. Jul 2010)

Und was würde passieren, wenn in deinem Szenario A das Model bearbeitet und B für die View zuständig ist?
Bzw. wenn ein Patch von A erstellt wird mit "seinen" Änderungen am MVC. Wer sagt, dass B diesen Patch überhaupt benutzen kann? Vielleicht hat B ebenfalls etwas am Modell geändert wodurch der Patch von A gar nicht mehr funktionieren kann bei ihm oder schlimmer den kompletten MVC zerschiesst?

Mir geht es im Prinzip darum, dass ich nicht verstehe wie man mit mehreren Entwicklern etwas bearbeiten kann wenn jeder eine gleichberechtigte Version von ALLEN Sourcen besitzt die gleichzeitig verändert werden können.
So etwas kann meiner Meinung nach nur mit "Locks" auf Source Files funktionieren. Ansonsten ist keinerlei konsistenz der einzelnen Repositorys der Entwickler gegeben.
Der Entwickler mit dem "Lock" hat das Recht die Datei zu ändern. Sollte ein anderer Entwickler zur gleichen Zeit diese Datei ändern wollen, so muss er dies in seiner lokalen Datei tun. Nachdem der "Lock" aufgehoben wurde, muss er ein Merge durchführen um seine Änderungen ebenfalls zu integrieren.


----------



## JohannisderKaeufer (16. Jul 2010)

Git wird beispielsweise für den linux kernel verwendet.

Jetzt hast du irgendwo linus torvald sitzen.
Dann gibt es ein paar absolute Cracks, denen linus voll vertraut.
Dann gibt es ein paar gute Entwickler.
Und schließlich einige Scriptkiddies.

Alles in allem sehrviele Leute, sehr viele Änderungen, sehr viel Code, die daran arbeiten.

Wenn jetzt ein scriptkiddie etwas coded was nicht ganz so astrein ist und es committet hat er es erstmal lokal. Pusht er es zu einem Entwickler kann der nochmals drübersehen und gegebenenfalls korrigieren bevor er es dann an die cracks und scripter weiterleitet. Einer der Cracks schautnochmals drüber, ändert vielleicht noch kleinigkeiten und verteilt das ganze weiter an seine Homies.

Und letztendlich pullt linus Änderungen aus seinem "Kreis des Vertrauens" bevor er ein neues release rausgibt.

Und das ist das was du mit einem SVN so nicht hinbekommst.

Alle haben gleichberechtigte Versionen, aber ziehst du dir einen Linuxkernel lieber von Linus oder von Heinz Kunz aus Niederdupfingen?

Du kannst einen zentralen Server hernehmen, der ist zwar gleichberechtigt wie alle anderen, per konvention aber kann man festlegen das dies der master ist.

Warum benötigst du unbedingt locks. Du kannst genauso mergen wie mit cvs oder svn.

Ich finde es eher so das bei svn und cvs jeder commit gleichberechtigt ist, bei verteilten Systemen holt man sich die Änderungen aus Quellen denen man vertraut.

Wie funktioniert denn bei SVN das Branchen? 

Und nun stell dir vor das bei SVN der Server schlapp macht. Oder kein Netz zur Verfügung steht.


----------



## slawaweis (16. Jul 2010)

MarderFahrer hat gesagt.:


> Da hätte ich eine Frage. Wie würde man Git benutzen wenn zwei oder mehr Entwickler an der selben Codebase arbeiten sollen? So wie ich das verstehe hat jeder das komplette Repository auf der Festplatte.
> Wie werden da die Änderungen von EntwicklerA and EntwicklerB usw propagiert?
> Für so etwas braucht man doch einen zentralen Server, der die Master Sourcen hält. Ansonsten arbeitet doch jeder am anderen vorbei. EntwicklerA arbeitet an Interface Itest1.java. EntwicklerB benutzt das Interface bei seiner Entwicklung. Jetzt ändert EntwicklerA das ganze Interface komplett ab. Wie soll das EntwicklerB mitkriegen? Er arbeitet weiter an seiner Entwicklung in der Annahme, dass alles noch so ist wie früher. Bei ihm sind die Sourcen ja auch wie früher.
> Da sich beim EntwicklerA aber einiges am Interface geändert hat, kann man doch nicht mehr von einer Codebase sprechen.


Git ersetzt nicht die Kommunikation in Projekt. In jedem größeren Softwareprojekt ist die Zusammenarbeit sowieso das primäre Element, Versionskontrolle ist nur eine Unterstützung. Wichtige Interfaces gehören normalerweise zum globalen Design einer Software und sollten im optimalsten Fall in dem Projektdokument dokumentiert sein. Will man diese nun ändern, sollte man diese Änderung zuerst im Team, Forum, Projektseite, Mailingliste besprechen, das Projektdokument aktualisieren und die Änderungen durchführen. Danach können die anderen Teilnehmer ihre Repositories aktualisieren.

Git zaubert nicht. Es ist nur eine Zeitmaschine für Daten. Was diese Daten aber machen oder machen müssen, muss auf anderen Wegen bekannt und verstanden werden.

Git bietet aber den Vorteil, dass nicht jeder am selben Repository arbeiten muss. Jeder hat seine Kopie und kann nach Lust und Laune daran werkeln, bei Open Source auch eigene Distributionen erstellen und vertreiben, und sein Repository anderen zu Verfügung stellen. Will man aber etwas in das Master-Repository einfügen, muss man entweder Zugang zu diesem bekommen oder es dem Master als Patch schicken, und der Master entscheidet selber, ob es reinkommt. Der Rest ist eine Frage des Mergings, was alles andere als trivial sein kann.

Slawa


----------



## MarderFahrer (19. Jul 2010)

JohannisderKaeufer hat gesagt.:


> Wenn jetzt ein scriptkiddie etwas coded was nicht ganz so astrein ist und es committet hat er es erstmal lokal. Pusht er es zu einem Entwickler kann der nochmals drübersehen und gegebenenfalls korrigieren bevor er es dann an die cracks und scripter weiterleitet. Einer der Cracks schautnochmals drüber, ändert vielleicht noch kleinigkeiten und verteilt das ganze weiter an seine Homies.
> 
> Und letztendlich pullt linus Änderungen aus seinem "Kreis des Vertrauens" bevor er ein neues release rausgibt.
> 
> ...



OK, das hieße aber doch, dass das Scriptkiddie seinen Code in das Repository vom Entwickler draufschiebt. Damit er da nochmal drübergucken kann. Das bedeutet doch, das unzählige Kiddies das machen können. Ich hätte jetzt gesagt, dass einen Entwickler das doch krank machen muss, wenn er jeden Tag, um mit seinem Repo überhaupt arbeiten zu können, zig Änderungen von den Kiddies erst einmal rückgängig machen muss wenn diese nichts taugen. Es sei denn natürlich, es gibt eine spezielles "Dump"-Repo, worauf niemand wirklich arbeitet, sondern das nur dafür da ist zu prüfen ob alle übermittelten Änderungen auch wirklich funktionieren. DAS wäre aber doch dann wieder das Modell des dedizierten Servers.
Als Antwort auf deine Frage, was passiert wenn so ein Server im SVN ausfällt... also wenn das ähnlich ist wie bei MKS, hat jeder Entwickler seine Sandboxes mit den Projekten/Subprojekten, die er bearbeitet und kann ganz normal weiterarbeiten. Nur kann er diese Änderungen noch nicht auf den Server spielen solange er down ist. Er kann aber sicher sein, dass kein andere etwas an diesen Sourcen ändern kann, da ka der Server für alle down ist und er das Lock auf den Files hatte bevor der Server wegfiel. Heißt nur er hat das schreibrecht auf diese Dateien.
Und Branches funktionieren ähnlich. Jeder User, der das System Recht zum branchen hat, kann diese Anlegen. Meistens haben die direkten Vorgesetzten dieses Recht damit nicht jeder User einen neuen Branch aufmachen kann. Das gäb nur Wildwuchs.  

Du sagtest 





> Alle haben gleichberechtigte Versionen, aber ziehst du dir einen Linuxkernel lieber von Linus oder von Heinz Kunz aus Niederdupfingen?


Das finde ich etwas unverständlich. Im ersten Teil des Satzes sagst du, dass ALLE gleichberechtigte Versionen haben. Dann fragst du von wo man lieber nen Linux Kernel ziehen würde. Was hindert denn "Heinz Kunz" daran seine Codechanges nicht einfach direkt auf Linus' Repo zu pushen? Sind diese Changes immer erst in Quarantäne bis der Besitzer des Repos die freischaltet?

Nicht falsch verstehen. Ich würde gerne Git nutzen, gerade da es ohne Server auskommt. Ich fänd es gut mit Freunden ein Hobby Projekt aufzusetzen, die weiter weg wohnen. Man spricht also nicht sehr häufig und daher wär es wichtig, dass jeder auf der selben CodeBase arbeitet. 
Nur irgendwie stelle ich mir das sehr schwierig vor. Mal stelle sich nur einmal ein recht kleines Projekt vor. Sagen wir wirklich mal nur ein Program, welches aus einem MVC besteht. Also, 1 Klasse Model, eine Klasse View, eine Klasse Controller. Wirklich sehr kompakt. Wenn man nun zu dritt daran arbeiten möchte und jeder das volle Repository als gleichberechtigte Version auf der Platte hat, wie genau funktioniert die Change Propagation? So wie ich das verstehe kann jeder bei seiner Entwicklung einzelne Stände für sich committen. Und er kann diese Änderungen zu jemand anderes pushen.
Muss man sich also immer absprechen wer wohin pusht? Also immer "A pusht nach B und C, B pusht nach A und C, C pusht nach A und B"?.
Das müsste dann am Ende jeden Arbeitstages gemacht werden, damit am folgenden Tag jeder die aktuellsten Sourcen auf der Platte hat.
Ich wüsste wie dies mit einem Serversystem wie MKS zu lösen ist. Projekt liegt auf dem Server, jeder erzeugt sich eine Sandbox auf der Festplatte und kann arbeiten. In der MKS GUI sieht man auch sofort, wer welche Datei derzeit in Bearbeitung hat. Und man bekommt ein Delta Icon an den Sourcen angezeigt, sobald man einen veralteten Stand einer Datei auf der Platte hat. Dann weiß man, es gibt etwas neues. Man macht einen snyc und man hat die aktuellste Version. Sollte dann etwas auf einmal nicht mehr funktionieren, stellt man die "Working Revision" von der Head Revision wieder zurück auf die vorherige Version und teilt dem anderen Entwickler mit, dass da in seinen Änderungen etwas nicht passen kann.
Mich würde wirklich interessieren, wie eine Entwicklung mit Git ablaufen würde. Im Internet habe ich bisher immer nur how to's gefunden, die zwar die Mechanik etc behandeln, aber nie etwas beispielhaft beschreiben. z.b wie mehrere Entwickler CodeChanges an einander verteilen und das jeder Entwickler jederzeit einen kosistenten Stand des gemeinsam entwickelten Projektes hat. Vielleicht nicht unbedingt das Linux Beispiel. Das scheint mir mittlerweile so Professionell, dass man daran nicht unbedingt ableiten könnte, wie man das selber mit 3-8 Entwicklern ohne einen "Übervater, der alles absegnet" nachahmen könnte.


----------



## JohannisderKaeufer (19. Jul 2010)

Ich empfehle folgende Lektüre

http://dennisbloete.de/studies/git-vcs.pdf
Was sind die Besonderheiten von Git?
Von einem zentralen Server aus arbeiten

heise online - Git-Pull-Request

http://chemnitzer.linux-tage.de/2008/vortraege/shortpaper/git.pdf
Patchbasierter Workflow
Nullaufwand für Start und Branches
Mit dem passenden Vortrag sicher hilfreich.

Und zuguterletzt
YouTube - Tech Talk: Linus Torvalds on git


----------

