Verwendete Unit 'System.ImageList' kann nicht compiliert werden

[Graf Gustav]

Hallo Sebastian,
danke für die schnelle Antwort, es hat erstaunlicherweise geholfen.
In dem Verzeichnis mit den Sourcen lag tatsächlich eine 'System.ImageList.dcu' von 2016.
Bis 10.1 hat das keine Delphi-Version interessiert, erst 10.4 hat darin einen Sinn gesucht.

Mit dem Hinweis auf ein Versionskontrollsystem hast du die zäheste Lücke meines
Delphi-Entwickler-Lebens getroffen. X mal angegangen, immer wieder versandet.
Als ich noch im Team programmiert habe, gab's so etwas noch nicht, und für einen singulären
Privatentwickler sieht das immer so aufwendig aus.

Also vielen Dank nochmnal
Reinhold

[hoika]

Hallo,
hatte früher auch gedacht (als Single-Entwickler).
Aber allein das "Diff" ist Gold wert ..

[jaenicke]

Zitat von Graf Gustav:

und für einen singulären Privatentwickler sieht das immer so aufwendig aus.

Das Gegenteil ist der Fall. Alleine schon manuelle Backups und der Alptraum unterschiedlicher Versionsstände, wenn etwas nicht mehr geht...
Ein höherer Aufwand ist es, wenn man kein Versionskontrollsystem nutzt. Denn mit SVN sind das wirklich nur ganz wenige Schritte. Das lässt sich in Minuten einrichten und ist sehr einfach nutzbar:
https://entwickler-ecke.de/topic_Kur..._112612,0.html
Da habe ich wirklich den ganzen Weg mit Screenshots gepflastert. Da kann wirklich nichts schief gehen, wenn du das ausprobieren möchtest.

[haentschman]

Besser gleich GIT. Das mergen ist besser...
https://entwickler-ecke.de/topic_Kur...it_115462.html

[jaenicke]

Zitat von haentschman:

Besser gleich GIT. Das mergen ist besser...

Dass Git besser ist, ist schon richtig. Zuerst hatte ich auch überlegt, nur die Anleitung für Git zu schreiben. Allerdings kann bei Git viel leichter etwas schief gehen und viele brauchen die Funktionsvielfalt gar nicht. Deshalb rate ich in Fällen wie diesen, wo es möglichst einfach sein soll und insbesondere nur einer am Quelltext arbeitet, zu SVN.

Da kann man nicht viel falsch machen, muss auch nicht viel dafür lernen, und wenn etwas falsch war, kann man dabei nicht gleich alles kaputt machen. Das ist bei Git leider anders.

[freimatz]

Man muss sich bei git schon anstrengen etwas kaputt zu machen.
Ich halte SVN inzwischen für einen Saurier.
Die Bedienung mit TortoiseSVN/TortoiseGit ist eh nahezu identisch.
Und ja: arbeiten ohne VCS ist ... wie Autofahren ohne Ölwechsel, oder ... geht einfach gar nicht.

[Uwe Raabe]

Ich war ja lange Jahre überzeugter Mercurial-Nutzer und ich betrachte es immer noch als das ideale System für Einsteiger und Dummies (nicht abwertend gemeint), die ein einfach zu bedienendes und unkaputtbares System suchen. Durch die schiere Übermacht von Git kommt man da allerdings nicht mehr drum herum. Es hat eine Weile gebraucht, bis ich einen würdigen Nachfolger für die TortoiseHG Workbench gefunden hatte, der mir den Umstieg auf Git deutlich erleichtert hat: Fork. Mittlerweile arbeite ich nur noch mit Git.

[Graf Gustav]

Der Motivation eurer Beiträge kann ich mich nicht entziehen, danke
Beim Versuch gestern, testweise SVN (und auch Git) zu installieren, bin ich bei beiden wieder an dieselbe Mauer gerannt -
diese Systeme mögen nicht die locker verbundenen Windows-Netzlaufwerke.
Gibt es da eine Lösung?

SVN findet das Laufwerk nicht, auch nicht \\Server\...

Der Git-Vorschlag erinnert mich an Unix-Zeiten, die sehr lange zurückliegen

Error in startup script

fatal: detected dubious qwnership in repository at
'//Buck1/homes/DEV10/'
'//Buck1/homes/DEV10/' is owned by:
'S-1-5-21-4101908947-260157542-1980192655-3054'
but the current user is:
'S-1-5-21-222117141 -13130269-41 4274037250-1001'
To add an exception for this directory, call:

git config --global --add safe.directory
‘%(prefix}///Buck1/homes/DEV10/'
while executing
'close Sfd'
(procedure 'git' line 5)
invoked from within
'git rev-parse --show-toplevel'
(file “C:/Program
Files/Git/mingw64/libexec/git-core/git-gui.tcl” line 1348)
invoked from within
'source [file join [file dirname[info script]] git-gui.tcl]'
(file “C:\Program Files\Git\mingw64\libexec\git-core\git-gui”
line 25)

Ich habe keine Probleme mit batch-Systemen, meine ersten Programme
habe ich in 360-Assembler geschrieben, aber das muss ja nicht mehr sein ...

[jaenicke]

Zitat von freimatz:

Man muss sich bei git schon anstrengen etwas kaputt zu machen.

Das geht sogar sehr einfach:
Vergiss vor dem Pull, dass noch lokale Änderungen da waren, dann bekommst du ggf. einen Konflikt. Wenn du den löst, zeigt dir TortoiseGit einen "Special Commit" an. Wenn du dann denkst, dass du doch die Änderungen gar nicht gemacht hast und welche rausnimmst, machst du leider die vorhergehenden Änderungen kaputt.

Klar, wenn man weiß, was man tut, passiert so etwas nicht, aber ich habe das schon erlebt (einige Wochen nach der Einführung von Git) und habe das dann im Repository korrigiert (es war auch niemand sonst da, der das hätte machen können).

Die Arbeitsanweisung, die ich mir dann überlegt habe, lautete, dass jeder zuerst das Staging nutzt, um lokale Änderungen wegzunehmen, dann pullt und dann die lokalen Änderungen wieder zurück holt. Dann gibt es ggf. auch Konflikte, aber die entstehen dann nur lokal und beim Committen sieht man wirklich nur die eigenen Änderungen, so dass das alles unproblematisch ist.

Zitat von Uwe Raabe:

Ich war ja lange Jahre überzeugter Mercurial-Nutzer und ich betrachte es immer noch als das ideale System für Einsteiger und Dummies (nicht abwertend gemeint), die ein einfach zu bedienendes und unkaputtbares System suchen.

Ja, das ist es. Ich persönlich mag Git lieber, aber ich weiß auch, dass es nicht narrensicher ist und man schon aufpassen muss, ob man das tut, was man meinte.

[himitsu]

Zitat von jaenicke:

Vergiss vor dem Pull, dass noch lokale Änderungen da waren

Oder vor dem Commit den Pull vergessen, dann sieht das Log auch schnell pervers aus (wenn man GIT aus Standard stehen hatt, was die Mergemethode betrifft)

Noch schlimmer wird es bei einem Merg und ganz besonders, wenn es da beim Merge zu Konflikten kam.
Da dann die Änderungen wieder auseinander zu bekommen
oder nicht ausversehn das Lokale mit dem Merge vermischt zu committen.

Zitat von freimatz:

Man muss sich bei git schon anstrengen etwas kaputt zu machen.

Bei SVN bekommt man nichts kaputt. (pull und push kann man auch nicht vergessen ... das ist quasi automatisch immer implizit dabei)
Im GIT geht es leichter, als man denkt ... samt löschen/überschreiben der kompletten Historie.

Ist aber immernoch besser, als gar keine Versionierung,
vor allem im Vergleich mit NICHTS, ZIPs oder Verzeichniskopien.