3. Welches Version Control System?

Welches Version Control System?

  • N

    SVN.
    Kenn allerdings auch nur CVS und SVN.

    0
  • A

    Ich könnte mit einer Anti-Empfehlung dienen. 😃

    Telelogic CM Synergy!!! Dreckstool schlecht hin! Wir müssen damit leider seit einem Jahr arbeiten. 😞

    0
  • R

    Ich würde dir git oder Monotone empfehlen (Mercurial soll auch gut sein, aber das habe ich noch nicht ausprobiert).

    SVN/CVS finde ich nicht gut und ich glaube fast, dass die Leute die dir SVN/CVS oder ähnliches empfehlen noch nicht mit einem modernen VCS gearbeitet haben (wie eben git oder Monotone).

    Was mir an SVN/CVS nicht gefällt:
    1. Branching ist schwer. Dabei lohnt es sich für jede neue Arbeit eine eigene Branch anzulegen. So hat man eine stabile Mainline und kann die neuen Features und Bugfixes in ruhe getrennt davon entwickeln und testen und wenn sie fertig sind in die Mainline einfügen. Ständig versuchen die Änderungen zu mergen ist ohnehin Zeitverschwendung.
    2. Mergen ist noch schwerer. Da hat SVN wohl im Vergleich zu CVS etwas am Branching getan, aber Mergen ist immer noch unmöglich.
    3. SVN/CVS schreiben dir in die Dateien (zB die diff-Ausgabe bei einem Konflikt). Das sollte ein VCS niemals tun! Lieber beim update darauf hinweisen und den Konflikt gleich beheben lassen.
    4. SVN hat unmöglich große Repositories. Wenn man SVN mittels git-svn ansteuert, ist das dazu gehörige git-Repository idr. kleiner, als ein einziger SVN-Checkout! (Und dabei bietet git noch mehr Features)

    (Die Einrichtung von SVN empfand ich auch als etwas qualvoll)

    Was mir an git/Monotone gefällt:
    1. Kryptographisch sicher! Wenn jemand auf dem Server einbricht, kann er nicht einen Trojaner oder ähnliches einschmuggeln.
    2. Man kann auch offline commiten. Daher kann man bei jeder kleinen Änderung einen commit machen und bei Problemen einfach zurück rollen. Außerdem funktioniert dann das Log einfach wie ein Entwicklertagebuch. (Und gerade wenn man viel unterwegs ist und nicht immer Internet hat oder darüber keine Geheimnisse verschicken will, ist ein zentralisiertes System wie SVN/CVS eine Qual).
    3. Monotone certs: Man kann für bestimme Branches garantien abgeben. zB in dem der Produktleiter/Qualitätsprüfer die Branch zertifiziert oder die Änderungen nur akzeptiert werden, wenn alle Unit-Tests funktionieren.
    4. git: Änderungen werden nicht auf Dateiebene, sondern für das ganze Projekt verfolgt. So verliert man nicht die Geschichte einer Funktion, weil man sie von Datei A nach Datei B bewegt.
    5. git: Ist schnell und klein. Außerdem gibt es eine Menge netter Tools, zB um Patches per E-Mail zu verwalten.
    6. Monotone/Git garantieren, dass man das raus bekommt, was man reingesteckt hat. (siehe auch 1.)

    Wenn ich mit SVN arbeiten muss, dann benutze ich lieber git-svn. git-svn ist ein git-Tool, mit dem man SVN ansprechen kann.

    0
  • ?

    Artchi schrieb:

    Telelogic CM Synergy!!! Dreckstool schlecht hin! Wir müssen damit leider seit einem Jahr arbeiten.

    dann schafft es doch ab. oder bist du der einzige, dem's nicht zusagt?
    🙂

    0
  • A

    SVN-fan schrieb:

    Artchi schrieb:

    Telelogic CM Synergy!!! Dreckstool schlecht hin! Wir müssen damit leider seit einem Jahr arbeiten.

    dann schafft es doch ab. oder bist du der einzige, dem's nicht zusagt?
    🙂

    Bist du Hobby-Entwickler, oder wie? Es ist Konzernstandard, arbeiten bestimmt ein paar hundert Leute damit. Aber es mögen mehrere Kollegen nicht. Nur ändert das nichts dadran, wenn die Projektverantwortlichen sagen, wir sollen es benutzen.

    0
  • ?

    Artchi schrieb:

    Nur ändert das nichts dadran, wenn die Projektverantwortlichen sagen, wir sollen es benutzen.

    irgendeinen grund werden sie wohl haben. vielleicht ist euer obermuck mit der schwester des toolherstellers verheiratet...
    🙂

    0
  • N

    0
  • B

    wie schon mehrfach erwähnt jetzt, die verteilten versionskontrollsysteme (git, monotone, hg[mercurial]) bieten einfach ein paar vorteile gegenüber ihren vorfahren cvs/svn usw. für ein neues projekt sehe ich eigentlich keinen grund kein verteiltes versionskontrollsystem zu nehmen. ein projekt was schon 3 jahre mit svn arbeitet und wo eigentlich alle zufrieden damit sind lohnt das umsteigen aber imo nicht wirklich. vielleicht irgendwann wenn es eine große umstellung, eine neue major version oder sowas gibt.

    0
  • P

    bazaar

    0
  • B

    Termite schrieb:

    der klient ist hin und wieder etwas träge

    Man könnte auch arschlangsam sagen. Der Server übrigens auch.

    Arbeiten mit bei extrem grossen Projekten ( 1 GB / 10k - 15k files ) ist etwas langsam Checkpoint dauert fast ne ewigkeit in der man die Kolegen blockiert.

    Korrekt.

    - File rename und move bei erhalt der history
    - Teilprojekte als shared subprojeckt in anderen Projekten einbinden ( libs, ... )
    - Changepackages

    Ich kenn mich mit CVS oder SVN gar nicht aus, aber ist es das wert? Ich mein wirklich? Nebenbei gesagt hab ich mir gestern den Vortrag von Linus, den hier jemand verlinkt hat, angesehen, und bin jetzt nicht so ganz überzeugt, dass CVS der Maßstab sein sollte.

    und noch nen vorteil.
    Einen Deutschsprachigen support den man anrufen kann.

    Es würde mich wundern, wenn der Support von denen noch kein Büro bei uns hat 😃

    0
  • ?

    rüdiger schrieb:

    Ich würde dir git oder Monotone empfehlen

    Wer installiert freiwillig ein Versionskontrollsystem das erst in der Version 0.3X ist?

    0
  • R

    xaver02 schrieb:

    rüdiger schrieb:

    Ich würde dir git oder Monotone empfehlen

    Wer installiert freiwillig ein Versionskontrollsystem das erst in der Version 0.3X ist?

    ich 🙄

    "The latest stable Git release is v1.5.3.7"

    0
  • D

    @rüdiger:
    als SVN-Fan dem die Schwächen durchaus bekannt sind: Kannst du in 2, 3 Sätzen skizieren, wie git die Problematik beim Branching und vor allem Merging löst?

    0
  • ?

    Das Problem bei den verteilten VCS ist, dass es keine gute Lösung für Windows gibt. Wenn man einmal Tortoise SVN gewohnt ist, will man nie wieder mit der Konsolen-Version arbeiten. Die restlichen GUIs für bazaar oder git sind schlecht.

    0
  • ?

    xaver02 schrieb:

    Wenn man einmal Tortoise SVN gewohnt ist, will man nie wieder mit der Konsolen-Version arbeiten.

    ich benutze zwar auch tortoise-svn, hätte's aber lieber als separate anwendung und nicht als shell-extension. weiss wer ob es da was gescheites gibt?
    🙂

    0
  • ?

    SVN-Freak schrieb:

    xaver02 schrieb:

    Wenn man einmal Tortoise SVN gewohnt ist, will man nie wieder mit der Konsolen-Version arbeiten.

    ich benutze zwar auch tortoise-svn, hätte's aber lieber als separate anwendung und nicht als shell-extension. weiss wer ob es da was gescheites gibt?
    🙂

    SmartSVN ist in der Foundation Version kostenlos und ganz brauchbar.

    0
  • ?

    xaver02 schrieb:

    SmartSVN ist in der Foundation Version kostenlos und ganz brauchbar.

    danke. sieht gut aus...
    🙂

    0
  • R

    dEUs schrieb:

    @rüdiger:
    als SVN-Fan dem die Schwächen durchaus bekannt sind: Kannst du in 2, 3 Sätzen skizieren, wie git die Problematik beim Branching und vor allem Merging löst?

    noch besser. Ich verweise dich gleich mal auf den Git-Crash-Course für SVN-Fans http://git.or.cz/course/svn.html#merge Branching ist auch nur eine Anweisung. Ähnlich bei Monotone.

    @xaver02
    Da kenne ich mich nicht genau aus, da ich git/monotone Plugins für meine IDE nehme und sonst auch mit der Konsolen-Version glücklich bin. Aber für viele IDEs gibt es entsprechende Plugins.

    0
  • D

    Hi Rüdiger,

    also doch nicht so toll wie es bei dir geklungen hat 😉
    Der einzige Unterschied ist, dass git sich vorherige Merges automatisch merkt was man bei SVN noch manuell machen muss.
    Alles andere ist gleich.
    Auch Branching ist in SVN nur eine einfache Operation: Ein Copy

    0
  • R

    Naja, die History wird halt auch nicht gemergt und du musst dich um Dinge manuell kümmern.

    http://git.or.cz/gitwiki/GitSvnComparsion

    0
Anmelden zum Antworten