compilteroptionen getIt

[TurboMagic]

Zitat von rwb:

Moin TurboMagic,
danke für Deine Anregung, bislang schreckte ich vor Git und seiner Komplexität zurück, aber ich werde es noch mal mit einem der beiden Versuchen.
MgG
Rolf

SVN dürfte für den Anfang einfacher zu verstehen sein. VisualSVN Server isntallieren und von dem das Zertifikat generieren lassen.
Ist ganz einfach, ist ja ein GUI Installer. Dann mit dem Verwaltungstool ein Repository und einen benutzer anlegen. Danach
Tortoise SVN installieren, integriert sich ins Explorer Kontext Menü und starten. Die Doku von Tortoise SVN ist recht gut!

Grüße
TurboMagic

[himitsu]

Explorer > leeres Verzeichnis erstellen > TortoiseSvn > create repository here
das Selbe geht auch mit TortoiseGit (als Bare-Repo erstellen) ... bei uns mal genutzt, um auf einem Share ein lokales Repo für Alle zu haben, weil es zu groß für GitHub war

und dann in anderem Verzeichnis den file://-Pfad (welchen man beim Erstellen angezeigt bekommt) beim Checkout benutzen

Bei GitHub kann man auch mit SVN auschecken (GitHub hat bei sich was eingebaut)
oder andersrum kann man auch mit GIT bei einem SVN-Server auschecken/clonen (GIT hat da was eingebaut)
und dann lokal mit dem Anderen arbeiten, als wie der Server ist.
(pervers wird es nur, wenn man mit Git bei der Svn-Bridge von GitHub sich einen runterholt)

[Uwe Raabe]

Zitat von TurboMagic:

SVN dürfte für den Anfang einfacher zu verstehen sein.

Das höre ich aber immer nur von Leuten die schon mit SVN arbeiten oder bis vor nicht allzu langer Zeit gearbeitet haben. Jede Umstellung ist erstmal ein Umstieg auf etwas anderes. Einen Einstieg in SVN als Vorbereitung für einen späteren Einsatz von Git halte ich eher für kontraproduktiv.

Da man sich gerade als Anfänger mit der Konsole manchmal etwas schwer tut, hängt die Akzeptanz in hohem Maße von der verwendeten GUI ab. Mein persönlicher Favorit ist da schon seit einer Weile (und vielen Fehlversuchen mit Alternativen):Fork

[himitsu]

Beim Merge geht Einiges mit Git besser, aber Anderes wird schlimmer.

Aber gerade wenn im Git mal was quer steht, dann wird es schlimm, weil Git einfach so viel kann, dass das nichtmal die Profis mit 200 Jahren Erfahrung sich noch auskennen.
Außerdem ist es bei SVN unmöglich die Historie zu zerstören. Was einmal eingecheckt ist, dass bleibt auch drin, während man in GIT ALLES vernichten kann, wenn man will oder zu doof rumklickt.


Also ja, SVN ist einfacher, auch wenn Git schon ein paar Vorteile hat.

[Uwe Raabe]

Zitat von himitsu:

Also ja, SVN ist einfacher

Aus den Argumenten kann man allenfalls folgern, dass SVN sicherer gegen Fehlbedienung ist als Git. Aber auch das ist eher eine Frage der GUI und deren intuitiven Bedienung.

Zitat von himitsu:

Aber gerade wenn im Git mal was quer steht, dann wird es schlimm, weil Git einfach so viel kann, dass das nichtmal die Profis mit 200 Jahren Erfahrung sich noch auskennen.

Das fällt meiner Meinung nach eher in den Bereich der Urban Myths und wird ebenfalls gern von SVN-Anwendern als Umstiegsverhinderungsargument verwendet.

[himitsu]

Zumindestens hatten wir es mehrmals geschafft, dass garnichts mehr ging und brauchten dann 'ne Weile, um eine passende Lösung zu googlen.
Teilweise bestand die Lösung dann darin das lokale Repo zu löschen und neu zu clonen.

Natürlich kann man sowohl in SVN, als auch Git viel mist bauen,
aber standardmäßig gibt es keinen Weg, um einmal committetes zu löschen, also lässt sich immer Alles wiederherstellen (außer Backup, die Historie umschreiben und Restore des Servers)

In Git kannst mit einem Force-Push alles auf dem Server löschen/überschreiben. (wobei im TortoiseGit die Checkbox für Force fehlt und man es über die Console machen muß ... z.B. wenn man den/die letzten Commits löschen will)
Das Einzige, was man bei SVN standardmäßig nachträglich ändern kann, ist die Commit-Message.

Aber ja, genauso wie im SVN, kann man im Git durch Hooks so Einiges verbieten.