# Eclipse - Projekte auf mehreren Computern



## piu58 (28. Dez 2012)

Guten Abend,

ich programmiere zwar schon mehrere Jahrzehnte, bin aber Frischling in Sachen Java. Einiges ist etwas gewöhnungsbedürftig, aber da findet man in jeder Programmiersprache etwas.

Meine Frage: Ich bearbeite Projekte auf mehreren Computer, sogar mit etwas unterschiedlichem Betriebssystem (beides aber Windows). Ich zippe mir meine Quellprogramme zusammen uind mach auf dem anderen Computer ein unzip-Update. Muss ich wirklich jedes Mal in Eclipse das Projekt löschen und neu importieren oder gibt es einen anderen Weg?
--
Uwe


----------



## gman (28. Dez 2012)

Dafür gibt es Versionsverwaltung. Wenn du wirklich schon Jahrzehnte programmierst, solltest du schon
mal darüber gestolpert sein (jedenfalls wenn du beruflich programmiert hast).

Die aktuellste Sau in Sachen Versionsverwaltung ist GIT. Der Klassiker
ist Subversion, der braucht aber einen zentralen Server.


----------



## piu58 (28. Dez 2012)

Danke für den Hinweis. Für mich selbst ist das zu aufwendig. Zentraler Server - da gäbe es auch einfachere Lösungen. Ich möchte einfach eine Applikation unaufwendig auf einem Memorystick von einem Rechner auf den anderen transportieren. Mit C# ist das kein Problem.


----------



## gman (28. Dez 2012)

> Mit C# ist das kein Problem.



Mit C# hast du doch das gleiche Problem oder nicht? Wenn du auf einem Rechner ein ZIP
des Projektes erstellst und auf einem anderen Rechner entpackst wird das vorhandene
alte Projekt überschrieben. Oder meinst du damit etwas anderes?

Man kann seine Projekte übrigens direkt aus Eclipse heraus als ZIP speichern/exportieren.
Aber beim Importieren in einen anderen Workspace darf dieses Projekt dann natürlich
nicht vorhanden sein.

Das (relativ) einfachste wäre mit Git zu arbeiten. Damit könntest du ein lokales Repository
auf einen USB-Stick pushen und dieses dann auf dem anderen Rechner klonen. Änderungen
werden dann immer in das Repository auf dem Stick gepusht und vom anderen Rechner
daraus abgeholt. Aber natürlich musste dich dafür n bischen in Git einarbeiten.


----------



## kama (28. Dez 2012)

Hi,


piu58 hat gesagt.:


> Danke für den Hinweis. Für mich selbst ist das zu aufwendig. Zentraler Server - da gäbe es auch einfachere Lösungen. Ich möchte einfach eine Applikation unaufwendig auf einem Memorystick von einem Rechner auf den anderen transportieren. Mit C# ist das kein Problem.


Sorry aber wenn Du schon lange Programmierst finde ich diese Aussage ein wenig merkwürdig...

Abgesehen davon kann man mit Subversion auch ein Repository auf einem Stick per file Protokoll machen (kein Server Notwendig!)...und dann eben auf den Stick legen...Git ist auch eine Möglichkeit...und selbst mit älteren Vertretern wie CVS geht das auch...

Gruß
Karl-Heinz Marbaise


----------



## Akeshihiro (28. Dez 2012)

Und mit den Tortoise-Clients (TortoiseSVN (Subversion), TortoiseGit (Git) und TortoiseHg (Mercurial)) ist das wirklich kein Ding Repositories zu bedienen und zu verwalten bzw. mit ihnen zu arbeiten. Aber es gibt auch entsprechende Plugins für Eclipse. Git und CVS sind bereits im Standardumfang enthalten und sofort einsatzfähig.


----------



## TheDarkRose (29. Dez 2012)

Wobei hier Git anstatt SVN zu empfehlen ist, denn dann kann man auch Commits machen, wenn man den Stick mal nicht angesteckt hat. Am Ende des Tages pusht man dann alles auf den Stick. 

Gesendet von meinem Nexus 7 mit Tapatalk 2


----------



## Akeshihiro (29. Dez 2012)

TheDarkRose hat gesagt.:


> Wobei hier Git anstatt SVN zu empfehlen ist, denn dann kann man auch Commits machen, wenn man den Stick mal nicht angesteckt hat. Am Ende des Tages pusht man dann alles auf den Stick.
> 
> Gesendet von meinem Nexus 7 mit Tapatalk 2



Genau so würde ich das auch machen.

Wobei ich da noch andere Gründe hätte, weshalb ich im Betrieb trotz SVN-Server die Projekte mit Git klone. Branching mal als Beispiel genannt. Bei SVN hab ich mit Branches miese Erfahrungen gemacht, mit dem Mergen sowieso. Vielleicht bin ich dafür auch zu blöd, aber mit Git klappt das um ein Vielfaches besser. Und vor allem eben, weil ich dann nicht vom Server abhängig bin und auch im "Offline"-Modus arbeiten kann, auch wenn der Server ausfallen sollte (warum auch immer).


----------



## piu58 (29. Dez 2012)

Ich versuche, mich mal klarer auszudrücken.

> in C# wird das vorhandene alte Projekt überschrieben. Oder meinst du damit etwas anderes?

Ja, das will ich ja. Das einzelne Projekt überschreiben. In C# zippe ich den Projektordner zusammen und packe ihn woanders wieder aus. Und kann dann genau an diesem Punkt weiterarbeiten. Direkt von Stick möchte ich übrigens nicht arbeiten.

In C# öffne ich die Solutions-Datei und fertig (z.B. mit Doppelklick). In Eclipse habe ich zumindest noch nichts gefunden, was dieser Solutions-Datei gleichkäme. Ich habe einen src- und einen bin-Ordner, ausßerdem nur noch wenige Dateien, den Klassenpfad, ein paar Einstellungen. Die aktuellen Projekte merkt sich Eclipse irgendwo anders, wahrscheinlich in der Registrierung(?)


----------



## maki (29. Dez 2012)

> In C# öffne ich die Solutions-Datei und fertig (z.B. mit Doppelklick). In Eclipse habe ich zumindest noch nichts gefunden, was dieser Solutions-Datei gleichkäme. Ich habe einen src- und einen bin-Ordner, ausßerdem nur noch wenige Dateien, den Klassenpfad, ein paar Einstellungen. Die aktuellen Projekte merkt sich Eclipse irgendwo anders, wahrscheinlich in der Registrierung(?)


Im Workspace, Eclipse hat nix mit der Registry zu tun.

Kannst ja Projekte importieren, aber dafür muss das alte Projekt vorher verschwinden.
Alles in allem taugt diese Vorgehensweise vielleicht für ein paar Experimente, wenn überhaupt.

SVN ist recht einfach (und eingeschränkt), git kann viel mehr, aber beides geht nicht ohne Einarbeitung.



Akeshihiro hat gesagt.:


> Wobei ich da noch andere Gründe hätte, weshalb ich im Betrieb trotz SVN-Server die Projekte mit Git klone. Branching mal als Beispiel genannt. Bei SVN hab ich mit Branches miese Erfahrungen gemacht, mit dem Mergen sowieso. Vielleicht bin ich dafür auch zu blöd, aber mit Git klappt das um ein Vielfaches besser. Und vor allem eben, weil ich dann nicht vom Server abhängig bin und auch im "Offline"-Modus arbeiten kann, auch wenn der Server ausfallen sollte (warum auch immer).


Werde mich aus deinen genannten Gründen und einem weiteren auch auf git-svn einlassen


----------



## Aldimann (29. Dez 2012)

Naja also natürlich wäre ein Versionsverwaltungssystem das schönste, wenn er aber doch nun nur allein arbeitet und kein Versionsverwaltungssystem haben möchte wäre ja es ja evtl. auch eine Option das Projekt extern auf einen Stick zu packen oder ggf. einfach den ganzen workspace.

Da könnte es zwar zu Problemen mit dem Pfad kommen aber sonst...

Aber nochmal: Der Vorschlag mit git wäre zu favourisieren .


----------



## Gast2 (29. Dez 2012)

piu58 hat gesagt.:
			
		

> Muss ich wirklich jedes Mal in Eclipse das Projekt löschen und neu importieren oder gibt es einen anderen Weg?


Nein, ein Drücken von F5 sollte ausreichen.

Wobei ich dir in deinem Fall auch eher zu nem VCS (git!) raten würde.


----------



## piu58 (29. Dez 2012)

> Nein, ein Drücken von F5 sollte ausreichen.

Danke! Das ist eine Antwort, mit der ich was anfangen kann.

> Wobei ich dir in deinem Fall auch eher zu nem VCS (git!) raten würde. 

Für mich allein, als einzigem Programmierer, überzogen. Das muss ja dann auf allen beteiligten Computern installiert sein und aktuell gehalten werden. Ich bein es gewöhnt, Dateien zu transportieren und habe kaum etwas eingebüßt. Liegt vielleicht an meiner Historie: Zu Beginn meiner Programmierei benutzte man Hexcode, später Assembler - an VCS für zu Hause war damals nicht zu denken. So habe ich mich anders eingerichtet.


----------



## TheDarkRose (29. Dez 2012)

Tja, Git ist kann man auch gut alleine zu nutzen. Die Installation auf den beteiligten Systemen sollte nicht das Problem sein.

Ehrlich ist es auch etwas peinlich, aber 10 Jahre zu programmieren aber mit ZIP Dateien auf einen Stick herumwurschteln. Sry. 

Gesendet von meinem Nexus 7 mit Tapatalk 2


----------



## kama (29. Dez 2012)

Hi,



piu58 hat gesagt.:


> Für mich allein, als einzigem Programmierer, überzogen.


Was hat das mit Überzogen zu tun..Du scheinst die Grundlegenden Ideen etc. eine Versionskontrolle nicht zu verstehen und welche Möglichkeiten eine VCS bietet......Ich mache auch viele Projekt alleine...aber auf keinen Fall OHNE ein VCS (Git;-))..



piu58 hat gesagt.:


> Das muss ja dann auf allen beteiligten Computern installiert sein und aktuell gehalten werden.


Installieren ja...aber wo ist das Problem? Download einmal installieren und gut ist...

Aktuell halten ? Muss nicht unbedingt sein, wenn man einer Versions arbeitet ist das Ok..außer man fällt mal tatsächlich über einen Bug in der Software (ist mir bisher noch nicht passiert).



piu58 hat gesagt.:


> Ich bein es gewöhnt, Dateien zu transportieren und habe kaum etwas eingebüßt.


Hm...Tja wer hat den aktuellen Stand, ist der Fix XY schon drin oder nicht? etc. das sind die Dinge die man mit VCS nachvollziehen kann...auch wenn man alleine arbeitet...Fehleranalyse ist schlicht einfacher mit VCS..(z.B. git bisect....;-))



piu58 hat gesagt.:


> Liegt vielleicht an meiner Historie: Zu Beginn meiner Programmierei benutzte man Hexcode, später Assembler - an VCS für zu Hause war damals nicht zu denken. So habe ich mich anders eingerichtet.


Ja ja vor ca. 30 Jahren habe ich auch so angefangen Hex-Code. Assembler etc. Dateien entsprechend benenn etc. aber das wird irgendwann lästig und vor allem Fehlerträchtig
 und dann stellt man sich die Frage: Das muss besser/einfacher etc. gehen

Abgesehen davon RCS konnte man für umme für Zu Hause haben (1985 ;-))...

Gruß
Karl-Heinz Marbaise


----------



## piu58 (29. Dez 2012)

>  scheinst die Grundlegenden Ideen etc. eine Versionskontrolle nicht zu verstehen 

Kann schon sein. Ich brauche es für meine Arbeit eben nicht, noch nie vermisst.


----------



## Bernd Hohmann (29. Dez 2012)

TheDarkRose hat gesagt.:


> Ehrlich ist es auch etwas peinlich, aber 10 Jahre zu programmieren aber mit ZIP Dateien auf einen Stick herumwurschteln. Sry.



Ich bin da ganz auf der Seite von Uwe.

Wenn man als Entwickler paar Jahrzehnte auf dem Buckel hat und überwiegend alleine (oder mit einem ganz kleinen Team) arbeitet und es mit unterschiedlichen Sprachen und Systemen zu tun hat, dann entwickelt man seine eigene, plattformübergreifende Strategie wie man Projekte von A nach B und natürlich auch in die Datensicherung bringt.

Man kann ein RCS nutzen, man kann da aber auch andere Strategien haben (bei mir werden alle relevanten Verzeichnisse im 15min Takt inkrementell auf eine Backupmaschine gezogen).

Bernd


----------



## Bernd Hohmann (29. Dez 2012)

kama hat gesagt.:


> Installieren ja...aber wo ist das Problem? Download einmal installieren



Ich hab mir jetzt Git installiert (war zum Glück im Linux-Repository), Eclipse gestartet und ein Projekt gelöscht.



kama hat gesagt.:


> und gut ist...



Wie komme ich jetzt wieder an das Projekt ran?

Bernd


----------



## gman (29. Dez 2012)

Och neee. Müssen wir jetzt einen Wie-ich-meinen-Code-speichere-War a la führen?

Dem TO wurde eine Lösung vorgeschlagen die recht gängig ist und sein Problem löst. Da kann man
jetzt nicht hingehen und sagen: "Ich will eine Lösung für mein Problem, die darf aber nicht anders
sein als meine jetzige.".

@piu58: Hilft dir der Hinweis mit dem direkten Export als ZIP-Archiv aus Eclipse heraus weiter? Der Import
dieses Archivs geht natürlich auch über einen Eclipse-Wizard. Natürlich kannste auch einen einfachen
Zipper zum entpacken nehmen, dann musste aber Eclipse mit F5 darauf hinweisen das sich das Projekt
geändert hat. Aber das hat EikeB ja auch schon geschrieben.

@Bernd:



> Wie komme ich jetzt wieder an das Projekt ran?



War das Projekt denn vorher in einem Remote-Repository (Server oder anderes Verzeichnis)?
Git ist kein Backup-System das einfach zauberhaft die Daten sichert, man muss sich schon
mit damit auseinander setzen und es richtig bedienen. Oder wolltest du jetzt einfach nur #
zeigen das Git doof und deine Lösung tausendmal besser ist?


----------



## Bernd Hohmann (29. Dez 2012)

gman hat gesagt.:


> @Bernd: [...]Oder wolltest du jetzt einfach nur #
> zeigen das Git doof und deine Lösung tausendmal besser ist?



"Tausendmal besser" als Multiplikator kenne ich nur von kleinen Kindern.

Karl-Heinz hat gesagt "ich muss nur installieren und gut ist".

Ich wollte damit nur darauf hinweisen, dass es auch bei den RCS nicht mit "mal eben" getan ist sondern man sich darin einarbeiten muss und auch ständig prüfen sollte, ob die Konstruktion so läuft wie gewünscht.

Bernd


----------



## Akeshihiro (29. Dez 2012)

maki hat gesagt.:


> Werde mich aus deinen genannten Gründen und einem weiteren auch auf git-svn einlassen


Darf man fragen, welcher Grund das ist?

@piu58
Es ist ja keine Kritik oder sowas, jedenfalls nicht von mir. Zwingen kann man niemanden, aber es wäre wirklich hilfreich, wenn du dir das anschaust und wirst davon auch sicherlich gut profitieren. Der einzige Aufwand dabei sind eigentlich nur die 2min für das Lesen eines Tutorials mit den Basics, das wars auch schon. Kein Server aufsetzen und nix. Und spätestens, wenn du einen älteren Stand brauchst, weil du dir was verbaut hast, wirst du froh sein, dass du das hast.


----------



## gman (29. Dez 2012)

> Karl-Heinz hat gesagt "ich muss nur installieren und gut ist".



Die Aussage von Karl-Heinz bezog sich auf:



> Das muss ja dann auf allen beteiligten Computern installiert sein und aktuell gehalten werden.



Das eine einfache Installation nicht sofort das Problem löst ist natürlich klar. Die Installation selber
sollte jedoch nicht als Hürde angesehen werden. Hast du ja selbst gesehen: bei Linux ist es im
Repository und für Windows gibt es auch einfache Installationen (z.B. auch TortoiseGIT).


----------



## Akeshihiro (29. Dez 2012)

Über die Installation würde ich mir ehrlich gesagt gar keine Sorgen machen. Die VCS/SCM gibt es alle als portable Variante, kann man also auf den Stick packen. Hab ich mir auch mal eingerichtet mit SVN, Git, Hg, aber auch mit diversen anderen Tools wie Groovy, Scala, Grails, Gradle, Ant, Maven, Java und noch anderes. Da dann natürlich das lokale System nichts davon weiß und es auch keinen Sinn macht den PATH für den Stick zu konfigurieren, hab ich dafür natürlich ein entsprechendes Batch-/Shell-Skript mit auf dem Stick, das die Umgebung für die Session anpasst. Funktioniert super, immer dabei, immer mobil, auf keinen von Admins vernachlässigten Rechner angewiesen.


----------



## Timothy Truckle (29. Dez 2012)

Akeshihiro hat gesagt.:


> Und spätestens, wenn du einen älteren Stand brauchst, weil du dir was verbaut hast, wirst du froh sein, dass du das hast.


Wieso denn? Er hat doch seine Zip-Files auf'm Stick...

bye
TT


----------



## Akeshihiro (29. Dez 2012)

Timothy Truckle hat gesagt.:


> Wieso denn? Er hat doch seine Zip-Files auf'm Stick...
> 
> bye
> TT



Davon war
1. nie die Rede, sondern, dass das Projekt als Zip auf dem Stick transportiert wird und
2. wow, was für eine Änderungshistorie ... Da sitz ich den ganzen Tag an dem Projekt, verbastel mir was und muss auf den Stand vom vorherigen Tag zurückrollen. :autsch:


----------



## Timothy Truckle (30. Dez 2012)

Akeshihiro hat gesagt.:


> Davon war
> 1. nie die Rede,


Nein, liegt aber nahe...



Akeshihiro hat gesagt.:


> 2. wow, was für eine Änderungshistorie ... Da sitz ich den ganzen Tag an dem Projekt, verbastel mir was und muss auf den Stand vom vorherigen Tag zurückrollen. :autsch:


Meine Oma sagte immer: "Was der Bauer nicht kennt das frisst er nicht."
Wer mehrere Jahrzehnte ohne SCM auskam dem wird die tagesgenaue Rückschau wohl auch heute reichen.

Auf jeden Fall hätte ich wohl die Ironietags nicht vergessen dürfen...

bye
TT


----------



## piu58 (30. Dez 2012)

> nie die Rede, sondern, dass das Projekt als Zip auf dem Stick transportiert wird 

Ich wollte hier keinen Streit anzetteln und habe ja auch eine vernünftige Antwort erhalten.

Zip-Files entstehen bei mir praktisch automatisch. Wenn ich mal kurz vom Computer aufstehe, dann lasse ich eine Konsolenapplikation los, die alles zusammenzipt, und wenn möglich auf mehrere Computer schreibt. Diese Sicherung transportiere ich auch. Außerdem lege ich davon immer mal ne Archivversion ab.

Das ersetzt kein VCM, ich weiß, ist aber für mich persönlich eine paktikable Methode. Ich verwende generell so wenig Werkzeuge wie möglich, und setze die bekannten so lange ein, wie es geht. Der Grund ist, dass ich meine Aufmerksamkeit den umzuetzenden Problemen wide und nicht in den Eigenheiten der vielen Werkzeuge verschleißen will. Damit bin ich nunmal gut gefahren.


----------

