Verwendete Unit 'System.ImageList' kann nicht compiliert werden

[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 ...

[himitsu]

Wenn du eh alleine arbeitest:

Für den Anfang braucht du (noch) garkeinen Server.
* GIT und vielleicht noch eine GIT-GUI (VisialStudioCode, GitHubDesktop, Tortoise oder so) installieren
* und dann in deinem Codeverzeichnis auf "create repository here" bzw. git init
* PULL und PUSH hier einfach (erstmal) vergessen
* aber schon hast du COMMIT und das Log zur Verfügung ... und optional auch Branches


Mit git remote add origin //MyWorkPCName/dev/myrepo kann man später immernoch optional in Ruhe ein "lokales" Remote-Repo anhängen
oder eben einen Sever ala git remote add origin [e-mail]:myname/myrepo.git .


Für den Share und auch einen Server ... Den muß man vorher erstellen.
git init --bare bzw. git init --bare deinverzeichnisodersharefolder
und dann kann man davon runterladen (git clone ) oder es dem Lokalen Repo hinzufügen (git remote add ).

Auch für SVN braucht es keinen Server (gut, denn kann man auch einfach nur lokal installiert haben),
aber da kann man ebenfalls direkt mit einem lokalen Verzeichnis oder einem Share arbeiten.

[Graf Gustav]

Genau das dachte ich ja auch.
Die Git-Meldung kommt beim Versuch, mit Git-GUI ein Repository anzulegen.
Es sind diese merkwürdigen Benutzerkennungen, die da zuschlagen....

[jaenicke]

Zitat von Graf Gustav:

diese Systeme mögen nicht die locker verbundenen Windows-Netzlaufwerke.
Gibt es da eine Lösung?

Keine Netzlaufwerke verwenden.
Ein Rechner stellt den Server zur Verfügung, alle anderen greifen auf diesen Server zu. Die SVN-/Git-Daten auf dem Server-PC werden (z.B. mit Veeam) regelmäßig automatisch gesichert, z.B. auf ein Netzlaufwerk.

[Uwe Raabe]

Zitat von jaenicke:

Keine Netzlaufwerke verwenden.

Das ist auch unabhängig von der Versionskontrolle zu empfehlen. Vor sehr langer Zeit, als SVN noch richtig neu war, haben wir unsere gemeinsam genutzten Libraries vom Netzlaufwerk auf den lokalen PC verschoben und die Turnaround-Zeiten (Compile, Build) in der IDE um mindestens den Faktor 10 verbessert. Seitdem sind Netzlaufwerke in der Entwicklungsumgebung tabu. Mittlerweile geht die Synchronisierung über Git auch deutlich schneller als früher das manuelle Kopieren ganzer Verzeichnisstrukturen.

[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.