Zusammenfassung Versionsverwaltungen SVN , GIT

[SneakyBagels]

Zitat:

Bleibt doch wieder auf einer sachlichen Ebene. Sonst schaukelt sich das wieder sinnlos auf.

Ich habe SVN und GIT mal versucht, aber kam damit nicht klar.
Ich war einfach zu unsicher, was die Software da genau macht und einige Male war da nur noch Müll in den Versionen.

Sicher lag das an mir, aber mit Zips (incl. Zeitstempel im Dateinamen) komme ich als Einzelentwickler besser klar.

Im Team als Nutzer eines betreuten Kontrollsystems sähe das sicher anders aus.

Endlich mal einer der alt eingesessenen Hasen hier im Forum, der "gegen" Versionskontrollsysteme ist und Zips bevorzugt.

[DeddyH]

Und das sagt genau was aus?

[SneakyBagels]

Das sagt aus, dass es auch professionelle Entwickler gibt denen ihr Code wichtig ist, die trotzdem keine Versionskontrolle benutzen sondern ganz normale Archive.
Somit wäre das Argument, dass den Leuten die Archive nutzen der Code nicht wichtig sei, aus dem Weg geräumt.

[DeddyH]

Man muss ja kein Versionskontrollsystem nutzen, aber wer das einmal getan (und begriffen) hat, der möchte es nicht mehr missen. Ich wüsste zumindest nicht, wie ich in einer Sammlung von Zip-Archiven übersichtlich herausfinden soll, wann ich welches Feature eingeführt habe. Bei einem Versionskontrollsystem schreibe ich das einfach als Kommentar beim Commit hinein und finde das in der Übersicht schnell wieder. Wer ernsthaft in einem Team arbeitet, kommt wohl ohnehin nicht drum herum, sich mit der Materie zu beschäftigen.

[Uwe Raabe]

Zitat von SneakyBagels:

Endlich mal einer der alt eingesessenen Hasen hier im Forum, der "gegen" Versionskontrollsysteme ist und Zips bevorzugt.

Das ist offenbar die übliche Ausnahme von der Regel

Ich habe früher auch ZIPs verwendet - und einfache Kopien von Verzeichnissen. Früher - das heißt: als Turbo Pascal 4 unter DOS gerade aktuell war. Dann kam RCS - Ende von Zip/Copy!

Heute ist Mercurial mein bevorzugtes System. Das Einrichten eines Repos ist eine Sache von Sekunden und das Handling in der Workbench von TortoiseHG ist sowas von simpel und komfortabel, da kommt kein Copy oder Zip mit.

Ich bedauere jeden, der diese Stufe der Erleuchtung noch nicht erreicht hat.

[SneakyBagels]

Es ist ja nicht so, als ob ich nur Kritik übe. Ich habe schon alle möglichen GUI-Clients ausprobiert und bin nun zum Testen bei SourceTree mit Git hängen geblieben.
Was mir sofort aufgefallen ist: ich kann keine Daten in ein Verzeichnis pushen, welches Buchstaben wie é enthält. Daraus macht SourceTree dann é und legt dementsprechend auch ein Verzeichnis an.

Ist der Bug bekannt, dass SourceTree nicht mir speziellen Buchstaben klar kommt?

[Fritzew]

Welche Sourcetree Version, welches Windows und wo pusht Du hin?
Habe seit Jahren keine Probleme damit gesehen

[SneakyBagels]

Aktuellste Version.

Ich pushe einfach nur auf ein Verzeichnis auf meinem Netzlaufwerk N:\GitTest\Dév

[Fritzew]

Ok, auch auf die Gefahr hin pingelig zu wirken, wo siehst Du diese Verzeichnisse? In Souretree? Im Explorer ?
Wenn Du das Repository in ein anderes lokales Verzeichnis auscheckst wie sehen dann die Ordner im Explorer aus?

[SneakyBagels]

Mit dem Fachchinesisch kann ich nix anfangen.

Ich mache einen initialen Commit meines lokalen Quellverzeichnisses.
Das klone ich jetzt auf mein Netzlaufwerk. Im Quellverzeichnis-Repository füge ich als Remote das Repository vom Netzlaufwerk hinzu.

Jetzt füge ich im Quellverzeichnis eine neue Datei ein und commite die Änderungen.
SourceTree zeigt mir nun oben links bei "Push" eine blaue 1 an. Soweit so gut.
Jetzt klicke ich auf Push. Es kommt ein Dialog mit einer Liste. Dort mache ich einen Haken bei meinem master branch oder wie auch immer das heißt.
Ich klick auf OK, es lädt ein bisschen und werkelt rum, und diese eine Datei befindet sich danach nicht auf meinem Netzlaufwerk. Nichts wurde geklont.