Umfrage: Versionsverwaltung

[Requion]

Hi Leute,

die Idee zu der Umfrage kam mir heute spontan.
Privat nutze ich Git und auf arbeit SVN.
Mich würde interessieren welches System ihr benutzt / bevorzugt und wieso.

[Mathias]

Weil Lazarus auch svn ist.

[photor]

Hi Leute,

die Idee zu der Umfrage kam mir heute spontan.
Privat nutze ich Git und auf arbeit SVN.
Mich würde interessieren welches System ihr benutzt / bevorzugt und wieso.

Dito. Und wie stimme ich dann jetzt ab ("du kannst eine Option auswählen")?

Ciao,

Photor

[mse]

Git weil dabei kein zentraler Server notwendig ist und alle lokalen Kopien die gesamte History enthalten, weil es für die meisten Opensource Projekte Git Repositories gibt und ein super praktisches in Free Pascal geschriebenes Frontend existiert.

[corpsman]

Zur Zeit Beruflich und Privat SVN, Einfach weil man mal mit was Anfangen muss

Aber mit Tendenzen zum Wechsel auf GIT.
Für das noch nicht veröffentlichte ctd Projekt von Mir hat mich einer meiner Beta Tester auf GIT genötigt und im Job wird Git besser supported.

Gerade im Job reizt mich die Serverlose Geschichte von GIT, ich müsste mir nur mal Zeit nehmen mich da ein zu arbeiten ..

[Requion]

Ich hab mit gitlab angefangen. Zuerst auf arbeit und dann privat. Auf gitlab.com kann man sowohl private als auch öffentliche Repos kostenlos erstellen.
Mittlerweile bin ich allerdings auf github umgestiegen, da ich aktuell eh nur opensource baue. Bei github gibt es nur die öffentlichen Repos kostenlos.

Zur Zeit Beruflich und Privat SVN, Einfach weil man mal mit was Anfangen muss

Aber mit Tendenzen zum Wechsel auf GIT.
Für das noch nicht veröffentlichte ctd Projekt von Mir hat mich einer meiner Beta Tester auf GIT genötigt und im Job wird Git besser supported.

Gerade im Job reizt mich die Serverlose Geschichte von GIT, ich müsste mir nur mal Zeit nehmen mich da ein zu arbeiten ..

Einarbeiten inwiefern? Git ist eigentlich ziemlich easy. Vielleicht kann ich dir ja schon Fragen beantworten.

[AndreasMR]

Hallo zusammen,

ich nutze eine Eigenentwicklung (war zu faul, mich in irgendeine Versionsverwaltung einzuarbeiten).

Meine Lösung funktioniert so, dass das Programm mit einem Parameter "version=" aufgerufen werden kann. Hinter dem Gleichheitszeichen steht eine Ziffer (1 bis 4), die mir angibt, an welcher Position die Versionsnummer um 1 erhöht werden soll.

Angenommen, die aktuelle Versionsnummer lautet 1.2.3.4 dann bewirkt
- "version=4", dass die neue Versionsnummer 1.2.3.5 lautet,
- "version=3", dass die neue Versionsnummer 1.2.4.0 lautet,
- "version=2", dass die neue Vrsionsnummer 1.3.0.0 lautet,
- "version=1", dass die neue Versionsnummer 2.0.0.0 lautet.

Für jede Ebene habe ich Regeln hinterlegt, was mit dem Code oder Paket geschehen soll. Das geht von der Datensicherung einzelner Dateien bis hin zum Sichern der aktuellen Version des Gesamtpaketes in einer gepackten Datei und Anlegen einer Sicherungskopie auf dem Server. Da ich das Programm erst letztes Wochenende geschrieben habe, wird mir da sicherlich noch einiges dazu einfallen.

Beste Grüße

Andreas

[af0815]

Leider kann man NICHT SVN und GIT zugleich angeben.

Aus der Historie SVN, außerdem habe ich da eine Lösung wie man auf einer Qnap-NAS den SVN-Server einfach installiert.

Andreas

[marcov]

svn zu Hause und Buro. Haben in ein anderes Projekt GIT genutzt, aber basis Features sind mehr aufwendig als SVN, und benutzte nur Kernfunktionalitaet und keine Cloud dienste, also denn ist SVN besser.

[Requion]

Leider kann man NICHT SVN und GIT zugleich angeben.

Aus der Historie SVN, außerdem habe ich da eine Lösung wie man auf einer Qnap-NAS den SVN-Server einfach installiert.

Andreas

Dafür war der Eintrag "Mehrere", das ist bei mir ja auch der Fall.

[delphifreak]

Wir haben kürzlich in der Firma von SVN nach GIT gewechselt.

Und ich muss sagen, SVN ist wohl für die meisten Leute die bessere (einfachere) Wahl.

[mse]

Und ich muss sagen, SVN ist wohl für die meisten Leute die bessere (einfachere) Wahl.

Das liest und hört man immer wieder, aber es ist einfach nicht wahr.
Einfache Sachen sind mit einem geeigneten git-Frontend-Tool mindestens so einfach wie mit SVN und für die meisten Leute reicht das. Die weitergehenden git-Funktionen muss man ja nicht benutzen, wenn man sie nicht braucht.
Der Screenshot zeigt wie eine versehentlich geänderte Datei in MSEgit ausschaut. Rechtsklick-'Restore' stellt sie wieder her. Im rechten Panel unten werden die Änderungen im gewählten Verzeichnis gelistet.
Sobald mehrere Personen zusammenarbeiten müssen, ist git SVN restlos überlegen.
Ich glaube niemand der je mit git gearbeitet hat könnte die Möglichkeit der lokalen branches missen.
In MSEgit muss zum Umschalten zwischen den branches lediglich in die 'C'-Spalte (=Checkout) im rechten Panel geklickt werden und die Dateien werden ausgetauscht, es ist nicht notwendig wie in SVN auf dem Server für jede branch ein eigenes Verzeichnis einzurichten.

[martin_frb]

Und ich muss sagen, SVN ist wohl für die meisten Leute die bessere (einfachere) Wahl.

Das liest und hört man immer wieder, aber es ist einfach nicht wahr.
Einfache Sachen sind mit einem geeigneten git-Frontend-Tool mindestens so einfach wie mit SVN und für die meisten Leute reicht das.

Mal nur auf das "einfacher" (also keine Aussage ob besser):

SVN is einfacher. Das heisst in der Bedienung. Im setup haengt es davon ab, ob man seinen eigenen lokalen Server braucht, falls ja dann ist das eine Huerde. Auch mit frontend.

"svn commit" und alles ist erledigt. Mit Git muss man dann noch Push ausfuehren.

Im nicht automatisch loesbaren Konflikt Fall (svn ubdate / git pull [**]) kriegt man mit SVN immer EIN file mit beiden Versionen, in git hat man dann eine Version, und ein diff/patch file. (Oder is gibt eine Option die ich nach 2 Jahren immer noch nicht gefunden habe....)

[**] oder fetch + merge, oder remote update..... 3 commandos fuer ein svn kommando.

Svn kann man das lernen von Branches auf spaeter verschieben, bei GIT nicht.

Svn kann man jede revisien *einfach* aus-checken, bei git wird dazu ein Branch erstellt. (Bei meiner ersten Nutzung, hatte ich keine Info warum, also hab ich das abgewaehlt, und dann hatte ich den Aerger.)
Man muss also sofort den Unterschied zwischen lokalem und remote Branches lernen.

-------------
Git hat viele Vorteile. Aber Svn ist definitiv schneller zu lernen.

[Requion]

@martin_frb
Bei den meisten deiner Aussagen fällt mir nur das Wort "gewöhnungssache" ein. Ich hab schon mit beidem gearbeitet.

"svn commit" und alles ist erledigt. Mit Git muss man dann noch Push ausfuehren.

Hat seinen Grund, nicht jede kleine Änderung muss sofort ins Repo. Also sehe ich da jetzt nicht das Problem.

Im nicht automatisch loesbaren Konflikt Fall (svn update / git pull [**]) kriegt man mit SVN immer EIN file mit beiden Versionen, in git hat man dann eine Version, und ein diff/patch file.

Das ist auch eher gewöhnungssache. Das hängt aber eher noch von der für das mergen verwendeten Software ab. Und ich für meinen Teil finde das ne so prall das svn den Konflikt einfach so zusammenschmeißt.

Svn kann man das lernen von Branches auf spaeter verschieben, bei GIT nicht.

Warum sollte man? Branches haben schon ihre Daseinsberechtigung. Und wenn du das unbedingt willst kannst du im git auch alles direkt in den master schmeißen (mach ich bei kleinen Projekten an denen nur ich arbeite auch so).

Svn kann man jede revisien *einfach* aus-checken, bei git wird dazu ein Branch erstellt. (Bei meiner ersten Nutzung, hatte ich keine Info warum, also hab ich das abgewaehlt, und dann hatte ich den Aerger.)
Man muss also sofort den Unterschied zwischen lokalem und remote Branches lernen.

Das versteh ich nicht ganz. Beim git kannst du einzelne branches (master oder irgendeinen anderen) und revisionen über den hash auschecken.

Git hat viele Vorteile. Aber Svn ist definitiv schneller zu lernen.

Das kann man so auch nicht pauschalisieren. Die originalen Docs von git sind sehr gut. Die Frage ist nur immer wie man das lernt.
Ich hab komplett in der Console angefangen, ohne irgendwelche gui sw die mir dazwischenpfuscht. Ich will nicht sagen das ich der git-meister bin aber ich verstehe zumindest den Grundgedanken und dessen Vorteile.
Und das ganze war vielleicht eine Sache von wenigen Wochen.

[mse]

SVN is einfacher. Das heisst in der Bedienung.

Darum mein Hinweis auf MSEgit als bequemes Frontend.

"svn commit" und alles ist erledigt. Mit Git muss man dann noch Push ausfuehren.

Bei einem lokalen git repository ist damit auch alles erledigt. Bei einem gemeinsam genutzten Repo finde ich es gar nicht schlecht, wenn man sich nochmals überlegt, ob man die Sache veröffentlichen will.

Im nicht automatisch loesbaren Konflikt Fall (svn ubdate / git pull [**]) kriegt man mit SVN immer EIN file mit beiden Versionen, in git hat man dann eine Version, und ein diff/patch file. (Oder is gibt eine Option die ich nach 2 Jahren immer noch nicht gefunden habe....)

Mit MSEgit macht man RechtsKlick-'Mergetool' und kann dann die Konflikte interaktiv lösen.

Mit RechtsKlick-'Difftool' kann man verschiedene Versionen vergleichen.