Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
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
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.
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.
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.
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...
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.
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.
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.
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).
> 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(?)
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.
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).
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 .
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.
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;-))..
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).
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....;-))
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 ;-))...
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).
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.
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?
"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.
@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.
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).
Ü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.
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:
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...
> 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.
