Verwendete Unit 'System.ImageList' kann nicht compiliert werden

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

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

[himitsu]

Ach mist ... sekunde ... die hatten da vor Kurzem eine Kranke Nutzerprüfung eingebaut, wo die den Namen, anstatt der Rechte prüfen ... die kann man aber abschalten.

Code:

git config --global --add core.symlinks false
git config --global --add safe.directory "*"

Eventuell auch mal über sowas nachdenken, wie z.B.:

Code:

git config --global --add core.hideDotFiles false
git config --global --add core.ignoreCase true
git config --global --add core.protectNTFS true

https://git-scm.com/docs/git-config

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

[freimatz]

Jetzt bin ich irritiert. Graf Gustav, du bist doch Einzelentwickler. Wieso hast Du dann lose Netzlaufwerke? Arbeitest Du nicht lokal?
Bei meiner Antwort bin ich davon ausgegangen. Und bei git brauchst du keinen Server, kein pull, kein push. Du brauchst zuerst nicht mal branches und merges. Eine reine Versionierung in einem branch wäre schon mal ein Fortschritt zu keiner VCS.
@jaenicke: wenn ich mit TortoiseGit pull und habe noch nicht committete Dateien, dann fragt es ob ich die stashen will. Lokal Dateien bekommt man natürlich schon kaputt. Ich meinte: was mal in git committet ist, bekommt man so einfach nicht kaputt.

[jaenicke]

Zitat von freimatz:

wenn ich mit TortoiseGit pull und habe noch nicht committete Dateien, dann fragt es ob ich die stashen will.

Das ist gut, war damals aber nur bei SVN so. Und ich habe es nie wieder ausprobiert.

[himitsu]

Ich hab es so noch nie erlebt.

Pull geht immer und sagt nichts "Schlimmes", egal ob Dateien lokal geändert sind oder nicht.
OK, es sagt schon was, denn die Modified Dateien werden anschließend aufgelistet.

NUR wenn eine Datei geändert ist, welche beim Pull/Checkout ebenfalls sich ändert, dann gibt es einen Konflikt, da die zu doof sind einen automatischen Merge der Datei hinzubekommen, selbst wenn die Änderungen in den Dateizeilen sich nicht überschneiden.

Entweder der Pull/Checkout bricht mit Fehler sofort ab und man kann noch in Ruhe stashen oder committen
oder der Pull/Checkout steht halb da und man darf mergen.
Hier gibt es noch kein Problem, aber passierte das bei einem Merge, dann hatte ich immer den halben Merge mit den lokal geänderten Dateien und beim anschließenden MergeCommitt passiert es schnell, dass man ausversehn seine lokalen Änderungen mit im Merge drin hat, wo sie logisch aber nicht rein gehören.