Mit mehreren Entwickeln.

[...]

Guten Tag,
ich programmiere schon/erst 1,5 Jahre in Java. Bis jetzt alleine.
Allerdings wollte ich nun zusammen mit einem Freund ein Projekt angehen.
Meine eigentliche Frage ist also, wie man dafür sorgt, dass der Quellcode immer bei beiden synchronisiert ist, bzw. wodrauf man achten sollte, wenn man mit n Leuten zusammenarbeitet. (Fleißig dokumentiert wird schon)

Viele Grüße und ein schönes Wochenende.


p.s. Wir benutzen beide Eclipse.

 

[Fab1]

Evtl. hilft dir der Thread http://www.java-forum.org/ides-tools/129924-mehreren-rechner-projekt-arbeiten-2.html

 

[...]

Jetzt habe ich was zum Googlen.
Leider kann ich als Gast nicht den Danke-Button drücken.


Vielen Dank.

 

[bERt0r]

Dropbox ist dafür nicht wirklich geeignet, besonders paralleles Arbeiten ist damit unmöglich. Mit SVN ist das machbar, jedes mal wenn du deinen code "commitest" wird abgeglichen was du geändert hast und es ist auch alles revidierbar.
Apache Subversion ? Wikipedia

 

[Landei]

Ich würde auch Subversion empfehlen (unter Windows macht sich TortoiseSVN nicht schlecht, aber IDEs haben das auch meist eingebaut). Wenn ihr Open Source machen wollt, legt ein Projekt bei Google Code an, da geht es meiner Meinung nach am einfachsten und ihr habt alles, was ihr braucht: Ein Wiki und ein einfaches Ticket-System ist auch dabei.

 

[...]

Ok,
vielen dank.
Dann wird es wohl auf SVN hinaus laufen.
Vielen dank.

 

[Sym]

Ich würde Git empfehlen.

 

[darekkay]

Wenn sich die Anzahl der Entwickler in Grenzen hält (was bei zwei Leuten wahrscheinlich der Fall ist ^^), so ist Mercurial empfehlenswert(er). Damit hätten wir dann auch schon die "großen drei" (SVN, GIT, Mercurial) durch.

 

[ThreadPool]

Wenn sich die Anzahl der Entwickler in Grenzen hält (was bei zwei Leuten wahrscheinlich der Fall ist ^^), so ist Mercurial empfehlenswert(er). Damit hätten wir dann auch schon die "großen drei" (SVN, GIT, Mercurial) durch.

Ich kann dir versichern das Mercurial auch mehr als 2 Leute bewältigen kann....

 

[Noctarius]

Wenn sich die Anzahl der Entwickler in Grenzen hält (was bei zwei Leuten wahrscheinlich der Fall ist ^^), so ist Mercurial empfehlenswert(er). Damit hätten wir dann auch schon die "großen drei" (SVN, GIT, Mercurial) durch.

Wieso meinst du Mecurial ist nur bei begrenzter Anzahl User zu empfehlen?

Dir ist klar, dass das OpenJDK Team mit Mecurial arbeitet?

 

[darekkay]

"Missversteht mich nicht falsch", wie Johann König sagen würde. Ich sagte nicht, dass Mercurial nur bei geringer Nutzerzahl/bei kleinen Projekten gut ist, sondern dass in dem Fall die Vorteile gegenüber SVN besonders klar sind.

 

[Noctarius]

Naja naja also nach 3 und 4 Mal lesen kann man das auch so in den Satz interpretieren ;-)

 

[ThreadPool]

"Missversteht mich nicht falsch", wie Johann König sagen würde. Ich sagte nicht, dass Mercurial nur bei geringer Nutzerzahl/bei kleinen Projekten gut ist, sondern dass in dem Fall die Vorteile gegenüber SVN besonders klar sind.

Ich finde nicht das die Vorteile so offensichtlich sind. Sind die Beteiligten räumlich sehr weit auseinander wird Mercurial ähnlich wie SVN verwendet. D.h. es gibt irgendwo ein zentrales Repo, das du dir lokal auf die Platte holst um daran zu arbeiten und die Änderungen im Anschluss einchecken oder andere Änderungen auschecken.

Der "Vorteil" von Mercurial liegt nun aber darin das man eben Änderungen auch zu anderen Beteiligten "pushen" kann ohne über das Hauptrepository zu gehen. Dazu müssen die "Anderen" jedoch genauso über das Netz erreichbar sein (dafür gibts den integrierten Webserver). Des Weiteren erlauben einem die dezentralen Systeme natürlich "lokal" zu branchen, commiten, überschreiben, was vorteilhaft für eigene Experimente ist.

 

[Noctarius]

Doch es gibt Vorteile sobald man viele Branches und damit auch viele Merges hat. SVN ist da immer etwas zickig.

 

[TheDarkRose]

Also ich kann Git immer wieder wärmstens empfehlen.

 

[Landei]

Für jemanden, der noch nie mit Coderepositories gearbeitet hat, ist Mercurial oder git meiner Meinung nach Overkill. Mit SVN gibt es genau eine Stelle, von der ich update und zu der ich committe, damit kommt ein Anfänger normalerweise besser zurecht.

 

[Noctarius]

Also Mercurial ist genau so einsteigerfreundlich wie SVN, GIT ist tatsächlich etwas höher angesiedelt und man sollte schon gewisse Vorkenntnisse in Sachen VCS besitzen.

 

[schalentier]

Also Mercurial ist genau so einsteigerfreundlich wie SVN, GIT ist tatsächlich etwas höher angesiedelt und man sollte schon gewisse Vorkenntnisse in Sachen VCS besitzen.

Mh, geb dir zwar Recht, aber Vorkenntnisse mit SVN helfen nicht unbedingt, GIT schneller zu verstehen.

Bei uns auf Arbeit gibts einen Kollegen, der ohne viel VCS-Vorkenntnisse GIT lernen musste. Ich hab den Eindruck, dass er es viel schneller begriffen hat, als ein anderer mit den entsprechenden SVN Kenntnissen. Klar, das liegt vielleicht auch an den Personen selbst, aber wenn man gar nicht erst versucht, sein SVN Wissen irgendwie auf GIT zu uebertragen (was man bei einem Umstieg sicherlich macht), isses imho deutlich einfacher und logischer.

Bin mir da aber nicht sicher, denn auch ich musste durchs "Tal der Traenen" (SVN->GIT) und hab damit keine Ahnung, wie es gewesen waere, haette ich direkt GIT gelernt ;-)

 

[Noctarius]

Das mag tatsächlich sein, ich hatte im ersten Anlauf auch etwas Probleme und bin in HG schneller reingekommen, da auch die Befehle eher denen von SVN nachempfunden sind

 

[...]

Hier hat sich ja nochmal was getan, ich denke aber wir bleiben bei unserer Wahl.


Viele Grüße.