Projekt auf ein anderes Laufwerk kopieren

[HPB]

Guten Tag Delphianer,
ich habe ein Projekt das vorher auf der Festplatte (D:\Projektname) entwickelt wurde
auf eine andere externe Festplatte (F:\Projektname) kopiert.
Nun möchte ich das Projekt auf der Platte (F:\Projektname) weiter entwickeln.
Beim Compilieren bekomme ich aber Fehlermeldungen das verschiedene
DCU-Dateien von selbst entwickelten Units fehlen.
Die DCU's sind aber im Verzeichnis vorhanden.
Was muss ich einstellen damit ich am Projekt weiter arbeiten kann?
Mit Gruß HPB

[braunbaer]

Du musst vermutlich die Bibliothekspfade im Delphi an das Laufwerk F: anpassen.
- Tool - Optionen - Bibliothek...

Gruß
Gebhard

[HPB]

Danke für die Antwort braunbaer.
Wenn ich die Bibliothekspfade für dieses eine Projekt ändere, dann muss ich
diese wieder ändern, wenn ich ein anderes Projekt bearbeite?
Das wäre sehr unglücklich!
Gibt es hier für keine andere Lösung?
Mit Gruß HPB

[Erdbär]

Klar und ganz einfach, im neuen Projektordner alle Dateien löschen, die den Pfad zum alten Projektordner enthalten :oops:

*.dof ist nicht doof, sondern reaktionär wie die AfD :evil:

[Jumpy]

Zitat:

Wenn ich die Bibliothekspfade für dieses eine Projekt ändere, dann muss ich
diese wieder ändern, wenn ich ein anderes Projekt bearbeite?

Die Pfade beziehen sich doch nur auf das gerade aktive Projekt.
Solltest also dieses Problem nicht bekommen.

[uligerhardt]

Zitat:

Zitat von Erdbär (Beitrag 1342070)

Klar und ganz einfach, im neuen Projektordner alle Dateien löschen, die den Pfad zum alten Projektordner enthalten :oops:

Die *.dproj würde ich schon übriglassen und sie in einem Texteditor bearbeiten. Alle D: durch F: ersetzen sollte reichen.

Auf Dauer würde ich außerdem alle absoluten Pfadangaben durch relative ersetzen, dann gibt's das Problem beim nächsten Umzug nicht mehr.

[Aviator]

Zitat:

Zitat von Jumpy (Beitrag 1342071)

Zitat:

Wenn ich die Bibliothekspfade für dieses eine Projekt ändere, dann muss ich
diese wieder ändern, wenn ich ein anderes Projekt bearbeite?

Die Pfade beziehen sich doch nur auf das gerade aktive Projekt.
Solltest also dieses Problem nicht bekommen.

Nur wenn die Pfade über die Projektoptionen geändert bzw. hinzugefügt werden. Über das Tools -> Optionen Menü sind die gloabel Pfade für alle Projekte hinterlegt.

[jaenicke]

Die Frage ist doch wie diese Units eingebunden sind. Stehen die absoluten Pfade in der .dpr Datei drin?

[Erdbär]

Zitat:

Zitat von uligerhardt (Beitrag 1342073)

Zitat:

Zitat von Erdbär (Beitrag 1342070)

Klar und ganz einfach, im neuen Projektordner alle Dateien löschen, die den Pfad zum alten Projektordner enthalten :oops:

Die *.dproj würde ich schon übriglassen und sie in einem Texteditor bearbeiten. Alle D: durch F: ersetzen sollte reichen.

Auf Dauer würde ich außerdem alle absoluten Pfadangaben durch relative ersetzen, dann gibt's das Problem beim nächsten Umzug nicht mehr.

Und den alten Ordner des Projekts "MeinProjekt" umbenennen zu "_MeinProjekt". Dann mault Delphi beim Öffnen des umkopierten _neuen_ Projekts schon recht heftig herum, weil es manche Pfade nicht mehr findet. :oops:

[Sherlock]

Welche Delphiversion speichert denn noch absolute Pfade in der dproj? XE2 hat das jedenfalls nicht mehr gemacht. 2007 IIRC auch nicht.

Sherlock

[Erdbär]

Zitat:

Zitat von Sherlock (Beitrag 1342086)

Welche Delphiversion speichert denn noch absolute Pfade in der dproj? XE2 hat das jedenfalls nicht mehr gemacht. 2007 IIRC auch nicht.

Sherlock

Welche Delphiversionen speichern denn/seit wann in *.dpro* statt in *.dpr ?

D7 und Lazarus kennt man bereits/noch, Mr. Holmes? :-D

[mm1256]

Zitat:

Zitat von Sherlock (Beitrag 1342086)

Welche Delphiversion speichert denn noch absolute Pfade in der dproj? XE2 hat das jedenfalls nicht mehr gemacht. 2007 IIRC auch nicht.

Sherlock

Du meinst wahrscheinlich die ".dpr". Delphi speichert meines Wissens schon immer absolute Pfade in der .dpr wenn die Unit nicht in einem Sub-Ordner des Projektverzeichnisses (der Ordner der .dpr Datei) oder auf einem anderen Laufwerk liegt.

BTW in der ".dsk", der ".identcache" und auch in der ".dproj" sind absolute Pfade zu finden. In der ".dproj" z.B. wenn Units explizid includiert werden. Beispiel aus einer meiner ".dproj" =>

Code:

<DCCReference Include="D:\Package\Jedi\JCL\source\windows\JclMapi.pas"/>

[HPB]

Zitat:

Zitat von jaenicke (Beitrag 1342083)

Die Frage ist doch wie diese Units eingebunden sind. Stehen die absoluten Pfade in der .dpr Datei drin?

Guten Tag jaenicke,
vielen Dank für Deine Antwort.
Die absoluten Pfade stehen in der .dpr drin.
hier ein Auszug:

Delphi-Quellcode:

  unVSTEinstellungen in 'G:\BPSObjektAblage\VST\unVSTEinstellungen.pas',
  AES in 'G:\BPSObjektAblage\Verschlüsselung\AES\AES.pas',
  ElAES in 'G:\BPSObjektAblage\Verschlüsselung\AES\ElAES.pas',

wie und wo kann in Delphi eingestellt werden, das immer nur relative Pfade genommen werden?
Mit Gruß
HPB

[mm1256]

Zitat:

Zitat von HPB (Beitrag 1342127)

wie und wo kann in Delphi eingestellt werden, das immer nur relative Pfade genommen werden?

Das geht nicht. Wenn die Projektdatei auf G: liegt dann könntest du zwar aus der ".dpr" die Pfadangaben raus nehmen, aber in den anderen zum Projekt gehörenden Dateien würden von Delphi trotzdem die absoluten Pfade eingetragen werden.

[Uwe Raabe]

Ich kann jetzt nicht sagen, ob das für alle Delphi-Versionen gilt, aber meine Beobachtung ist, daß Delphi immer relative Pfade nimmt, wenn die Units im selben Laufwerk zu finden sind, wie die DPR-Datei. Das kann schon mal in regelrechte Punktorgien ausarten. Nur wenn die Laufwerke nicht passen, wird der Laufwerksbuchstabe verwendet (geht ja auch nicht anders).

Wenn also solche Referenzen auf G:\ vorkommen, genügt es, das Projekt über Speichern unter ebenfalls auf G abzulegen - sinnvollerweise gleich in einem geeigneten Verzeichnis - um die relativen Pfade zu erhalten. Danach kann man dann das Projekt an eine andere Stelle verlagern, solange die Verzeichnisstruktur erhalten bleibt.

Das funktioniert in der Regel problemlos. Ich kopiere öfter mal ein komplettes Projektverzeichnis oder benenne es um, ohne daß dies die Funktionsfähigkeit beeinträchtigt.

[mm1256]

@Uwe Ich hab das soeben interessehalber nochmal getestet. Es macht offensichtlich einen Unterschied ob man eine Unit dem Projekt hinzufügt, oder ob man im Projekt eine Unit erzeugt. Bei Letzterem nimmt Delphi die "Punkte-Orgie" und bei Ersterem den absoluten Pfad. Aber komischerweise auch nicht immer.

In meinen Projekten befinden sich jedenfalls fast ausschließlich absolute Pfadangaben weil ich neue Units/Formulare in der Regel mit einem Testprogramm erstelle und teste, und dann erst dem Projekt hinzufüge (Zeitersparnis beim compilieren und testen).

[Uwe Raabe]

Zitat:

Zitat von mm1256 (Beitrag 1342137)

In meinen Projekten befinden sich jedenfalls fast ausschließlich absolute Pfadangaben weil ich neue Units/Formulare in der Regel mit einem Testprogramm erstelle und teste, und dann erst dem Projekt hinzufüge (Zeitersparnis beim compilieren und testen).

Interessant. Ich habe bei mir ausschließlich relative Pfade, weil ich meine Projekte immer so anlege, daß die verwendeten Units in Verzeichnissen unterhalb der Projekt-Datei liegen. Lediglich die Suchpfade dürfen schon mal eine Ebene höher referenzieren, wenn es eine übergeordnete Struktur gibt, in der die verwendeten Libraries verwaltet werden. Absolute Pfade gibt es projektbezogen gar nicht. Damit kann ich die Projektstruktur beliebig irgendwo ablegen. Das ist auch für die Versionsverwaltung und das Build-System unerlässlich. Absolute Pfade sind da ein absolutes Tabu.

[HPB]

@Uwe,
bei mir sieht die Struktur immer so aus:
LW:\ProjektOrdner (hier liegt die .dpr)
alles andere liegt in Unterordnern:
LW:\ProjektOrdner

Ordner-1
Ordner-2
Ordner-3
Ordnern ...

In den Unterordnern Ordner-1 bis Ordner-n liegen immer nur
die Formulare. Jeder der Unterordnern hat immer auch einen Ordner für
die Units die das jeweilieg Formular benötigt.

Mit Gruß HPB

[mm1256]

Zitat:

Zitat von Uwe Raabe (Beitrag 1342142)

Ich habe bei mir ausschließlich relative Pfade, weil ich meine Projekte immer so anlege, daß die verwendeten Units in Verzeichnissen unterhalb der Projekt-Datei liegen.

So hat eben jeder seine eigenen individuellen Vorgehensweisen. So wie du es handhabst würde es bei mir gar nicht gehen, weil ich dann die von mehreren Projekten gemeinsam verwendeten Dialoge und Helper-Units (z.B. Stringbearbeitung) bei jedem Projekt duplizieren müsste. Darum liegen diese Units auf einem anderen Laufwerk.

Wie dem auch sei, ich werde das Verhalten von Delphi in dieser Hinsicht mal etwas genauer beobachten.

[jaenicke]

Zitat:

Zitat von mm1256 (Beitrag 1342149)

So wie du es handhabst würde es bei mir gar nicht gehen, weil ich dann die von mehreren Projekten gemeinsam verwendeten Dialoge und Helper-Units (z.B. Stringbearbeitung) bei jedem Projekt duplizieren müsste. Darum liegen diese Units auf einem anderen Laufwerk.

Bei uns liegen die auch in einem anderen Verzeichnis. Die werden aber nur per Buildskript einmal erzeugt und nicht bei jedem Kompilieren eines Projekts :shock:.
Der Bibliothekspfad zeigt einfach auf die .dcu Dateien und das war es. In den Projekten werden die nur in die uses geschrieben, aber nicht in dem Projekt hinzugefügt.

[Uwe Raabe]

Zitat:

Zitat von jaenicke (Beitrag 1342408)

Bei uns liegen die auch in einem anderen Verzeichnis. Die werden aber nur per Buildskript einmal erzeugt und nicht bei jedem Kompilieren eines Projekts :shock:.
Der Bibliothekspfad zeigt einfach auf die .dcu Dateien und das war es. In den Projekten werden die nur in die uses geschrieben, aber nicht in dem Projekt hinzugefügt.

Bibliotheks-Units nehme ich auch nicht direkt in die Projekte auf, sondern binde die über die Suchpfade ein. Ob man dazu die Sourcen oder nur die DCUs nimmt, hängt sicher vom eigenen Umfeld ab.

Bei mir sind aber alle Bibliotheken in dem Projekt oder im Über-Projekt eingebunden (als SubRepos), da ich in den verschiedenen Projekten halt oft unterschiedliche Versionen der Bibliotheken verwenden muss. Ich kämpfe heute noch mit den alten Projekt-Versionen, bei denen das noch über globale Pfade gelöst wurde, wenn ich die mal wieder anfassen muss. Da muss man nach dem Auschecken der Version erst seine Entwicklungsumgebung passend einrichten - häufig mit Laufwerksbuchstaben, die heute auf ganz was anderes zeigen als damals und somit auch nicht einfach geSUBST werden können.

[mm1256]

Zitat:

Zitat von Uwe Raabe (Beitrag 1342415)

Bibliotheks-Units nehme ich auch nicht direkt in die Projekte auf, sondern binde die über die Suchpfade ein.

Das habe ich bis vor ca. einem Jahr auch so gemacht und mich manchmal über Seiteneffekte gewundert. Das Problem kann sein, wenn man so wie ich überwiegend an einem einzigen großen Projekt arbeitet, ein größeres Update vor hat, und in diesem Zug noch Änderungen an den gemeinsam benutzten Units vornehmen muss.

Während dieser Umbauarbeiten möchte/muss ich aber auch Zugriff auf die alten Version (sowohl Projekt als auch alle Units) haben (benutze keine Versionsverwaltung) und dann schraubt man ständig an den Suchpfaden rum, was ich persönlich als lästig und fehleranfällig empfunden habe. Seit ich generell alle Units über absolute Pfade in die .dpr einbinde (Delphi macht das ja automatisch wenn die Units auf einem anderen Laufwerk oder nicht in einem Subordner des Projektes liegen) hab ich diesen Stress nicht mehr.

Aber, wie schon gesagt, das macht jeder auf die Art und Weise wie er am besten damit klar kommt. Hat alles seine Vor- und Nachteile.

[Uwe Raabe]

Zitat:

Zitat von mm1256 (Beitrag 1342421)

Aber, wie schon gesagt, das macht jeder auf die Art und Weise wie er am besten damit klar kommt. Hat alles seine Vor- und Nachteile.

Richtig! Hier geht es ja auch gar nicht darum, wer was richtig oder falsch macht. Ich finde es sehr aufschlussreich hier verschiedene Arbeitsweisen und deren Gründe kennenzulernen. Das spart einem in manchen Fällen vielleicht selbst einen suboptimalen Weg einzuschlagen. Nur fürchte ich, daß wir dafür bald einen eigenen Thread aufmachen sollten.

[mm1256]

Ich glaube nicht, dass wir dafür von Daniel eines auf die Finger bekommen, denn es gehört doch irgendwie zum Thema. Denn, wenn man ein Projekt auf ein anderes Laufwerk umzieht, oder gar auf einen anderen Rechner, und die .dpr enthält z.B. ausnahmsweise absolute Pfadangaben, dann kann sich das ganz anders auswirken als bei Suchpfaden. Hat also doch irgendwas mit dem Thema zu tun. Abgesehen davon, wir bleiben ja anständig und sachlich :thumb:

[jaenicke]

Zitat:

Zitat von mm1256 (Beitrag 1342421)

Während dieser Umbauarbeiten möchte/muss ich aber auch Zugriff auf die alten Version (sowohl Projekt als auch alle Units) haben (benutze keine Versionsverwaltung) und dann schraubt man ständig an den Suchpfaden rum, was ich persönlich als lästig und fehleranfällig empfunden habe.

Keine Versionsverwaltung würde ich schon als unzumutbar empfinden. Ich verstehe ehrlich gesagt nicht wie man so ernsthaft arbeiten kann.
Dagegen ist die Fehleranfälligkeit von Suchpfaden noch die reinste Wonne. ;-)
Aber jedem das seine...

[mm1256]

sorry für OT

Zitat:

Zitat von jaenicke (Beitrag 1342427)

Keine Versionsverwaltung würde ich schon als unzumutbar empfinden. Ich verstehe ehrlich gesagt nicht wie man so ernsthaft arbeiten kann.

Ich ziehe bei jedem Master-Release (erscheint i.d.R. zum Jahreswechsel) die Ordner um, und gut isses. Abgesehen davon, wenn man bei einem Master-Release auch die Delphi-Version wechselt, was bei mir ja regelmäßig vorkommt, macht das die Versionsverwaltung auch stressfrei mit? In diesem Zug müssen ja sowieso die Suchpfade, Packages usw. geändert werden.

[Uwe Raabe]

Zitat:

Zitat von mm1256 (Beitrag 1342438)

Abgesehen davon, wenn man bei einem Master-Release auch die Delphi-Version wechselt, was bei mir ja regelmäßig vorkommt, macht das die Versionsverwaltung auch stressfrei mit? In diesem Zug müssen ja sowieso die Suchpfade, Packages usw. geändert werden.

Nein, das muss nicht so sein. Natürlich müssen die verwendeten Packages in der neuen Version vorhanden sein, aber das ist ja eigentlich Part der Delphi-Installation. Das gilt auch für die globalen Suchpfade. Die projekt-eigenen Suchpfade sind ja eh relativ und somit unabhängig von der Delphi-Version. In der Regel kann ich nach der Installation eines neuen Delphi mitsamt Design-Packages meine Projekte einfach darin öffnen und gut. Die Migration aller Projekte ist dann eine Sache von wenigen Minuten.

Bei den Dritthersteller-Komponenten habe ich meistens die Projektdateien und Projektgruppen so angepasst und Build-Gruppen erstellt, daß sie sich mit wenigen Klicks öffnen, compilieren und installieren lassen. Dann muss ich auch nicht erst auf die neue Version des Herstellers warten, was ja auch schon mal länger dauern kann.

In der Vergangenheit hatte ich immer wieder Schwierigkeiten mit Packages, die zu der Projektgruppe gehören und ausschließlich innerhalb dieser Gruppe benutzt werden. Dort war es mitunter sehr lästig, die Versionsabhängigkeit durchzuziehen. Aber da gibt es ja jetzt auch Abhilfe :)

[jaenicke]

Zitat:

Zitat von mm1256 (Beitrag 1342438)

Abgesehen davon, wenn man bei einem Master-Release auch die Delphi-Version wechselt, was bei mir ja regelmäßig vorkommt, macht das die Versionsverwaltung auch stressfrei mit? In diesem Zug müssen ja sowieso die Suchpfade, Packages usw. geändert werden.

Dafür gibt es bei uns eine Textdatei, in der festgehalten ist was installiert und eingestellt werden soll und gut ist es. Dann sind die ganzen Packages, JEDIs usw. installiert und die Projekte können einfach geöffnet und kompiliert werden.
Die passe ich bei einem neuen Release einmal an, in der Regel eine Sache von einer Stunde max. sobald die JEDIs da sind für die Version.

Will ich jetzt nachschauen was in einer Version von vor einem halben Jahr schief gegangen ist, kann ich einfach diese Version auschecken, per Batch die gemeinsamen Units neu erstellen und in der Version debuggen. So lässt sich dann ggf. ein Workaround oder Hotfix anbieten ohne auf die aktuelle Version aktualisieren zu müssen.

Dazu kommt, dass man ohne Versionsverwaltung nicht einmal sehen kann wann und warum eine bestimmte Zeile eigentlich zuletzt geändert wurde. Man kann einen Fehler also nur ggf. feststellen, kann aber nicht sehen, ob ein Fix evtl. an einer anderen Stelle Probleme macht, da man eine Änderung wieder zurücknehmen muss oder ähnliches. Man sieht ja nicht welche Änderungen mit anderen zusammenhängen.
Bei einer Versionsverwaltung kannst du einfach nachschauen warum jemand die Stelle geändert hat und was mit der Änderung noch zusammenhängt.

[mm1256]

Zitat:

Zitat von jaenicke (Beitrag 1342470)

Bei einer Versionsverwaltung kannst du einfach nachschauen warum jemand die Stelle geändert hat und was mit der Änderung noch zusammenhängt.

Für Teamarbeit und Gruppen ist natürlich eine Versionsverwaltung unerlässlich, da gibt es keine zwei Meinungen. Da ich seit etwa 13 Jahren Einzelkämpfer bin (seitdem beschäftige ich keine Programmierer mehr und erledige alles selber), ist also dieser "jemand der eine Stelle geändert hat" immer die selbe Person. Das ist wohl der Hauptgrund, warum mich die Versionsverwaltung bisher wenig interessiert hat.

[Sherlock]

Ich bin einer von der schusseligen Sorte. Wenn ich also mal wieder so unglücklich mit der Stirn auf die Tastatur geknallt bin, das der Code zwar compiliert, aber zur Laufzeit seltsame Dinge geschehen, die sich erst nach zwei Tagen offenbaren (*), bin ich ohne Versionsverwaltung aufgeschmissen.

Sherlock

(*) Das ist die einzige Fehlerquelle in meinen Programmen, ehrlich!

[jaenicke]

Zitat:

Zitat von mm1256 (Beitrag 1342477)

ist also dieser "jemand der eine Stelle geändert hat" immer die selbe Person. Das ist wohl der Hauptgrund, warum mich die Versionsverwaltung bisher wenig interessiert hat.

Darum geht es ja gar nicht. Ich arbeite zu Hause auch alleine an meinen Projekten. Ich weiß aber nach einem Jahr trotzdem nicht mehr warum ich etwas geändert hatte usw.
Genau das sagt mir aber die Versionsverwaltung.

Und wie ich an anderer Stelle schon einmal geschrieben habe gibt es ja noch einige andere Vorteile, die man auch als Einzelperson hat:

• Du siehst welche Änderungen du gemacht hast, wenn z.B. plötzlich etwas nicht mehr funktioniert
• Du siehst beim Abschicken der Änderungen, ob du unbeabsichtigte Änderungen drin hast (z.B. Debugausgaben, ...)
• Du hast alle Dateien an genau einer definierten Stelle und brauchst nicht (wie es leider viele ohne Versionsverwaltung machen) Kopien anlegen, die dann evtl. aus Versehen benutzt werden usw.
  Kopien, bei denen man dann wiederum nicht weiß was da eigentlich mittlerweile geändert wurde. Dann kehrt man zu einer Version zurück, nur um zu bemerken, dass eine andere Änderung weg ist, ...
• Du kannst mehrere Entwicklungen parallel machen, zwischen beiden hin- und herschalten und am Ende beide zusammenführen
• Du kannst einfach zu einer älteren Version zurückgehen und testen, ob ein Fehler dort schon drin war oder ob etwas dort anders funktioniert hat
• Du kannst jederzeit im Quelltext etwas komplett ändern oder auch löschen um z.B. einen Fehler zu finden, da du die Version ja jederzeit wiederherstellen kannst

[Aviator]

Zitat:

Zitat von jaenicke (Beitrag 1342479)

Und wie ich an anderer Stelle schon einmal geschrieben habe gibt es ja noch einige andere Vorteile, die man auch als Einzelperson hat: [...]

Wie oft commitest du denn so deine Änderungen? Hast du dafür eine Regel? Ich benutze zwar eine Versionsverwaltung, habe aber auch oft das Problem, dass ich entweder nicht dran denke zu commiten oder einige Änderungen nicht protokolliere, da ich beim Text schreiben nicht mehr daran denke.

[Sherlock]

Ich committiere wenigstens einmal am Tag. Eigentlich aber mit jedem abgeschlossenen Thema. Das macht es einfacher griffige Commit-Kommentare anzugeben. Man sollte eigentlich auch in der Lage sein, Problemstellungen granular genug zu formulieren, so daß man schöne Häppchen abarbeiten und committetenentete... übergeben kann.

Ich bin neulich mit unversioniertem Python-Code mächtig auffe Schnauze gefallen. Da hatte sich die Einrückung...ähm...verrückt und schon ändert sich da ja bekanntlich etwas. Die Fehlersuche war nicht lustig. Dann hab ich das eigentlich kleine Projekt ins Mercurial geschoben. Das will ich nicht nochmal erleben.

Sherlock

[Uwe Raabe]

Zitat:

Zitat von Aviator (Beitrag 1342480)

Wie oft commitest du denn so deine Änderungen? Hast du dafür eine Regel?

Bei jeder Änderung, die sachlich zusammenhängt. Das kann ein einfacher Bugfix sein oder bei einem größeren Feature ein überschaubarer Teilbereich (dann in einem Branch). Wenn ich viele kleine Bugs fixe, dann können schon mal nur wenige Minuten zwischen den Commits liegen (manchmal dauert das Schreiben der Commit-Message am längsten).

Commits müssen auch nicht zwangsläufig compilieren oder auch die Tests bestehen. Das sollte in der Regel dann gelten, wenn man die ChangeSets pusht (ich rede hier über Mercurial).

Mir ist klar, daß das bei einem Subversion-System schon mal anders aussehen kann, weil man dann eventuell bei jedem Commit mergen muss oder das CI-System meckert. Deswegen verwende ich ja auch ein DVCS wie Mercurial, bei dem ich diese Möglichkeit der kleinen Commits habe, ohne daß Andere davon beeinflusst werden.

Es hat allerdings auch eine Weile gedauert, bis ich diese Art zu arbeiten verinnerlicht hatte.

[jaenicke]

Zitat:

Zitat von Aviator (Beitrag 1342480)

Zitat:

Zitat von jaenicke (Beitrag 1342479)

Und wie ich an anderer Stelle schon einmal geschrieben habe gibt es ja noch einige andere Vorteile, die man auch als Einzelperson hat: [...]

Wie oft commitest du denn so deine Änderungen? Hast du dafür eine Regel? Ich benutze zwar eine Versionsverwaltung, habe aber auch oft das Problem, dass ich entweder nicht dran denke zu commiten oder einige Änderungen nicht protokolliere, da ich beim Text schreiben nicht mehr daran denke.

Ich überprüfe beim Committen generell jede einzelne Änderung (auch etwas, was ohne Versionsverwaltung unmöglich ist). Dabei trenne ich dann ggf. jede logisch zusammenhängende Änderung und committe diese mit passenden Kommentaren einzeln. Ggf. übernehme ich auch einzelne Änderungen einer Datei nacheinander (entweder indem das VCS das unterstützt oder indem ich schlicht alles andere im Vergleichstool rückgängig mache, speichere aber das Tool offen lasse, committe und dann wieder alle Änderungen zurücknehme).

Auf diese Weise weiß ich immer genau was zu welcher Änderung gehörte und warum ich etwas geändert habe.

Insbesondere weiß ich ganz genau, dass keine Änderung unbeabsichtigt in den Produktivcode im Repository gelangt, da ich diese ja prüfe.

[Codehunter]

Ich wünschte, ich hätte die Kapazitäten frei, ein VCS einzuführen und mich einzuarbeiten. Im Moment könnte ich gut sowas wie "Softtime" (Analogie zum legendären SoftRAM) gebrauchen :-(

So ein VCS, egal welches, führt man ja nicht im Handstreich ein und integriert seine eigenen Projekte. Ich habe zwar ab und zu mit Subversion zu tun, allerdings nur bei freien Projekten wo ich gelegentlich kleinere Commits mache. Da unser eigener Projekt-Source aber nicht außer Haus darf, könnte ich nicht auf gehostete VCS zurückgreifen sondern müsste das auch noch selbst aufsetzen. No Chance derzeit, leider.

[Sherlock]

Also "aufsetzen" ist ein großes Wort. Zum reinschnüffeln reicht doch ein "installieren" und "benutzen" ;)
Ein extrem freundlicher Einstieg wäre zum Beispiel mit SourceTree von Atlassian möglich. Einfach installieren und benutzen. Musst Dir dabei nichtmal Gedanken machen, ob Du da jetzt eigentlich ein Git oder ein Mercurial benutzt.

Sherlock

[jaenicke]

Ich habe hier eine kleine Anleitung geschrieben:
http://www.entwickler-ecke.de/viewtopic.php?p=683811

Das sollte, insbesondere weil du ja SVN schon ein wenig kennst, in einer halben Stunde locker laufen und deine Projekte kannst du ja an der Stelle einchecken wo sie aktuell liegen. Dann musst du auch nichts weiter umstellen, hast aber trotzdem den Vorteil der Versionierung usw.

Die einfachste Variante dafür ist, den Ordner mit den Quelltexten umzubenennen, in den Ordner mit dem Namen das Repository auszuchecken und dann die Dateien alle wieder in den Ordner zu schieben. Dann einmal Add auf alles, Commit und es ist alles im Repository.