Dom: Krücke oder Powertool mit auferlegtem Keuschheitsgürtel

0 68

Krücke oder Powertool mit auferlegtem Keuschheitsgürtel

Dom
  • meinung
  1. 0
    zehbaeh
    1. 0

      Welche Tools verwendet Ihr?

      Tom
      • software
      1. 0
        Felix Riesterer
        1. 0
          niklaskamenisch
          1. 0
            Tom
            1. 0
              Felix Riesterer
              1. 0
                Tom
            2. 0
              ulli_1956_
      2. 0
        hotti
      3. 0
        niklaskamenisch
      4. 0
        Jeena Paradies
        1. 0
          Jeena Paradies
          1. 0

            Microsoft Frontpage

            Hans
            1. 0
              Multi
              1. 0
                Alexander (HH)
        2. 0
          Multi
      5. 0
        Alexander (HH)
        1. 0
          Alexander (HH)
        2. 0
          Jeena Paradies
          1. 0
            Tom
            1. 0
              Jeena Paradies
              1. 0
                Alexander (HH)
                1. 0
                  Jeena Paradies
                  1. 0
                    Der Martin
                    1. 1
                      Jeena Paradies
                    2. 0
                      Alexander (HH)
                      1. 0
                        Tom
                      2. 0
                        Der Martin
                        1. 0
                          Jeena Paradies
                        2. 0
                          Alexander (HH)
                          1. 0

                            Welche Tools verwendet Ihr? Ist ein Wiki-Artikel möglich?

                            Tom
                            1. 0
                              Jeena Paradies
                              1. 2
                                Alexander (HH)
                          2. 0
                            Der Martin
                            1. 3
                              Jeena Paradies
                              1. 1
                                Detlef G.
                              2. 0
                                Der Martin
                                1. 0
                                  Jeena Paradies
                                  1. 0
                                    Der Martin
                                    1. 0
                                      Mitleser
                                    2. 0
                                      Jeena Paradies
                                      1. 0
                                        Jeena Paradies
                                      2. 0
                                        Der Martin
                                        1. 0
                                          Jeena Paradies
                                        2. 0
                                          Tom
                                        3. 0
                                          Matti Mäkitalo
                                    3. 3
                                      Alexander (HH)
                                      1. 1
                                        Christian Kruse
                                      2. 0
                                        Der Martin
                                        1. 4
                                          Alexander (HH)
                                          1. 0

                                            Welche Tools verwendet Ihr? NIH-Syndrom

                                            tami
                                          2. 4

                                            Überzeugungsarbeit

                                            Kai345
                                            • menschelei
                                            1. 0
                                              Alexander (HH)
                                              1. 1
                                                Alexander (HH)
                                                1. 0
                                                  tami
                                          3. 0
                                            Der Martin
                    3. 0
                      Anon Nymous
                  2. 0
                    Multi
                    1. 0
                      Christian Kruse
                      1. 0
                        Multi
            2. 0
              Alexander (HH)
          2. 0
            Alexander (HH)
      6. 0
        luti
      7. 0
        Der Martin
      8. 0
        tami
      9. 0
        seth
  2. 0
    Ole.

Hi,
haben auf der Arbeit die Creative Suite 5 und da ist Dreamweaver mit dabei.
Daher nutze ich das Tool für meine Projekte in PHP/Mysql und HTMl/CSS.
Aber ich werkel immer nur im Code-Fenster herum und habe noch nie irgendetwas anderes benutzt. Habe mal aus Spaß in die Menüs geschaut und gesehen, dass ich mir die Styles bspw. zusammenklicken kann und dass ich einen Formular-Editor oder Tabelleneditor nutzen könnte.
Aber da bin ich zu Fuß - also einfach runtergetippt 3-Mal schneller und es ist sauberer.
Meine Frage: Fahr ich da einen Ferrari betankt mit Biodiesel? Ist das Tool mächtig und kann viel mehr, als ich weiß?
Oder ratet Ihr zur Nutzung ganz anderer Tools/COde-Editoren?

Viele Grüße
Dom

  1. Wenn Du eh schon Markup selbst schreibst, sind für das verbleibende Programmieren/Debuggen/Testen IMHO eher andere Werkzeuge wie Netbeans, PhpStorm oder Eclipse geeignet.

    1. Hello,

      Wenn Du eh schon Markup selbst schreibst, sind für das verbleibende Programmieren/Debuggen/Testen IMHO eher andere Werkzeuge wie Netbeans, PhpStorm oder Eclipse geeignet.

      Da hänge ich mich jetzt mal dran.

      Welche Werkzeuge benutzt Ihr überhaupt?

      Ich hänge immer noch auf Textpad und Heidi rum. Für die Grafikbearbeitung habe ich inzwischen glücklicherweise wieder meinen geliebten Micrografx Picturepublisher. Aber alles kann man damit auch nicht machen.

      Liebe Grüße aus dem schönen Oberharz

      Tom vom Berg

      --
       ☻_
      /▌
      / \ Nur selber lernen macht schlau
      http://bergpost.annerschbarrich.de
      1. Lieber Tom,

        Welche Werkzeuge benutzt Ihr überhaupt?

        Geany@Ubuntu / Notepad++@Windoof, Firefox mit Firebug, The GIMP, phpMyAdmin

        Liebe Grüße,

        Felix Riesterer.

        --
        ie:% br:> fl:| va:) ls:[ fo:) rl:| n4:? de:> ss:| ch:? js:) mo:} zu:)
        1. hi,

          wusste ichs doch, dass ich 2 sachen vergessen habe:
          Firefox mit Firebug und phpMyAdmin ^^

          Gruß Niklas

          --
          Man muss nicht alles wissen, man sollte aber wissen, wo das nicht gewusste zu finden ist.
          1. Hello,

            wusste ichs doch, dass ich 2 sachen vergessen habe:
            Firefox mit Firebug und phpMyAdmin ^^

            Klar, ich auch.

            Browser:
                Firefox, zwei Versionen auf zwei Windows-Hosts und eine auf dem Linux-Lappi
                IE in zwei Versionen auf zwei Windows-Hosts
            Plug-Ins für Firefox:
                Web Developer Toolbar,
                Live HTTP Headers,
                ExifViewer,
                Screengrab (wird leider nicht mehr unterstützt)

            Webserver:
                Lokal Xampp mit Apache, MySQL, PHP

            Transfer und Konsole:
                Filezilla Client über SSH (bzw. internes scp)
                PuTTY

            MySQL-Frontend:
                "Heidi".

            Auf den Linux-Hosts:
                mc als Filebrowser und Editor für schnelle Sachen

            Ich wollte immer mal Eclipse für PHP benutzen, weil das dann auf WinDOS und auf Linux laufen könnte. Aber irgendwie stell ich mich wohl zu blöd an bei der Einrichtung.

            Liebe Grüße aus dem schönen Oberharz

            Tom vom Berg

            --
             ☻_
            /▌
            / \ Nur selber lernen macht schlau
            http://bergpost.annerschbarrich.de
            1. Lieber Tom,

              Webserver:
                  Lokal Xampp mit Apache, MySQL, PHP

              das sind für mich keine Tools, sondern Infrastruktur. Deine Frage nach Tools muss ich da wohl missverstanden haben.

              Liebe Grüße,

              Felix Riesterer.

              --
              ie:% br:> fl:| va:) ls:[ fo:) rl:| n4:? de:> ss:| ch:? js:) mo:} zu:)
              1. Hello liebert Felix,

                Webserver:
                    Lokal Xampp mit Apache, MySQL, PHP

                das sind für mich keine Tools, sondern Infrastruktur. Deine Frage nach Tools muss ich da wohl missverstanden haben.

                Nun sei mal nicht so pingelig :-P

                Liebe Grüße aus dem schönen Oberharz

                Tom vom Berg

                --
                 ☻_
                /▌
                / \ Nur selber lernen macht schlau
                http://bergpost.annerschbarrich.de
            2. Hallo,

              MySQL-Frontend:
                  "Heidi".

              wer um alles in der Welt ist Heidi???
              ...und warum macht die in Datenbanken???

              Ulli

      2. hi,

        Welche Werkzeuge benutzt Ihr überhaupt?

        Ich hänge immer noch auf Textpad

        Klasse Teil TextPad: Clips, Makros, Code ausführen...

        Und noch einer: Komodo, der kann u.a. autocomplete und den SourceTree anzeigen... Komodo kann auch mit einem Klick ganze Blöcke in Kommentare umwandeln und erkennt dazu selbst das Kommentatorzeichen (PHP, Perl, HTML, JS)

        FTP, SCP können Beide, Server eintragen, fertig.

        Hotti

        --
        Mobben ist nicht mein Ding, aber wenn ich das mal machen muss, dann fachgerecht.
      3. hi,

        da häng ich mich doch an.
        DW ist anfangs und für reine HTML sachen ganz ok.
        Ich nutze seit einiger Zeit aber auch nur noch NetBeans.
        Die Projektverwaltung ist bei vielen Kundenaufträgen einfach supper um innerhalb des Programms an alle nötigen Daten zu kommen.
        Da es auch gleich noch einige Versionen behält, kannst du so noch mal paar schritte zurück gehen (mehrere Tage im besten Fall).

        Zudem ist die Unterstützung für andere Sprachen vorhanden und die Doku relativ vollständig! (ich programmiere selber viel in PHP und vorallem auch JAVA. Grade der Java GUI-Builder von NB ist einer der einfachsten und mächtigsten. Klar auch da kann man von Hand schreiben, für kurze tests ist es aber am schnellsten.

        JS, HTML, CSS wird auch toll unterstützt. Seit ich NB verwende, sind die Fehler die man erst beim Ausführen merkt zudem auf kleinigkeiten gesunken (das was der kompiler eben nicht sehen kann).

        Für einzelne dateien anderer Projekte, nutze ich PSPad bzw. UltraEdit (auf der Arbeit vorinstalliert gewesen).

        Für Grafiken natürlich die Adobe reihe CS5.
        (Mit Putty, WinSCP, Office und einem FTP-Prog ist der ArbeitsPC ausreichend präpariert ;) )

        Gruß Niklas

        --
        Man muss nicht alles wissen, man sollte aber wissen, wo das nicht gewusste zu finden ist.
      4. Hallo,

        Welche Werkzeuge benutzt Ihr überhaupt?

        Für Web-Zeug als Texteditor Sublime Text 2 der ja zur Zeit, meiner Meinung nach völlig zurecht, hochgehyped. Für grafiken, wobei ich eigentlich nur aus fertigen Designs Sachen ausschneide, Photoshop.

        Für normales Programmieren nutze ich vor allem XCode.

        Bei beiden nutze ich git (auf der Konsole) als backup und versionierung.

        Hm, irgendwie ganz schön wenig Handwerkszeug :)

        Jeena

        1. Hallo,

          Ach ja für alles andere wie zeug auf den Server schaufeln, oder an der Datenbank rumschrauben nutze ich die normale Konsole.

          Jeena

          1. Hallo,

            ich bin Fan vom guten alten Frontpage. Die integrierten Gimmicks wie Gästebücher oder Hoverbilder via Java-Appletts erinnern mich gerne an meine Anfänge als Internetbastler. Bei entprechender Servererweiterung funktionieren  die Frontpage-Gimmicks einwandfrei.

            Gruß Hans

            1. ich bin Fan vom guten alten Frontpage.

              Du frisst auch kleine Kinder und Hundewelpen,oder? >;-)

              1. Moin Moin!

                ich bin Fan vom guten alten Frontpage.

                Du frisst auch kleine Kinder und Hundewelpen,oder? >;-)

                Ich vermute eher modernes Flagellantentum. Oder sehr viel schlechtes Karma in einem früheren Leben.

                Alexander

                --
                Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".
        2. Für Web-Zeug als Texteditor Sublime Text 2 der ja zur Zeit, meiner Meinung nach völlig zurecht, hochgehyped.

          Wenn es eine Möglichkeit gäbe, das Teil per DBus, Dcop o.ä. fernzusteuern, wäre das Teil perfekt für mich. Dazu hab ich aber noch nichts gefunden.

          Ansonsten geniales Programm

      5. Moin Moin!

        Welche Werkzeuge benutzt Ihr überhaupt?

        Editoren: Ultraedit, joe, Notepad++, notfalls Notepad oder irgendeinen vi

        Browser: Firefox mit Web Deveoloper und Firebug, IE

        Validator: validator.w3.org via Web Developer

        Automatisierung: GNU make, dmake, Perl (Strawberry auf Windows), find, xargs, grep, bash, sed

        Grafik: GIMP, Perl

        Kommunikation: OpenSSH, PuTTY, WinSCP, WinFTP

        Versionsverwaltung: Subversion, TortoiseSVN

        Dateisystem-Visualsierung: Explorer, Midnight Commander

        Packer: tar, gzip, bzip2, xz, 7zip

        Virtualisierung: VirtualBox, notfalls VMware

        Datenbank: PostgreSQL

        Issue-Tracking: Bugzilla

        Tastatur-Shortcuts: Winkey bzw. AutoHotkey

        ... und sonst so ziemlich alles, was mir nicht im Weg steht und idealerweise FOSS ist. Kostenpflichtige Software nutze ich eher selten, abgesehen vom mitgekauften Windoof und Ultraedit. Es sei denn, mein Auftraggeber / Arbeitgeber hat besondere Anforderungen und stellt mir die entsprechende Software zur Verfügung (z.B. Oracle, MS SQL Server, Spezial-Software).

        Hardware: 2x Eizo F55 oder F56, Fujitsu-Siemens-Nixdorff KBPC S oder KBPC H EU, Logitech "Leuchtmaus" mit Scrollrad, ohne Schnickschnack.

        Ja, das sind alte Röhrenmonitore, die mir 100x besser gefallen als jedes LCD, auf das ich bislang sehen mußte. Schnell, farbstabil, und an jeder Grafikkarte seit Einführung des AGP flimmerfrei. Mit den mitleidigen Blicken der unwissenden LCD-Jünger kann ich gut leben.

        Die Tastatur, die man zumindest im Norden aus vielen Sparkassen und Behörden kennt, hat das genialste Layout aller Zeiten, mit einem sehr guten Anschlagverhalten. Im Prinzip ist das eine klassische 101/102-Tasten-Tastatur, in die Lücken zwischen Ctrl und Alt bzw. AltGr und Ctrl hat man je eine Logo-Taste gesetzt, und von der breiten rechten Shift-Taste hat man rechts eine normal breite Menü-Taste abgezwackt. Ergebnis: Die Space-Taste ist so breit, wie es sich gehört, AltGr liegt dort, wo es seit Urzeiten sitzt, und die Menü-Taste liegt an einer Stelle, wo man sie nicht versehentlich trifft. Die H-Variante hat außerdem noch eine Power-Taste über den LEDs, die man mit einem einzigen auf das Mainboard gelöteten Draht oder einem Zwischenstecker außen und einer Leitung nach innen für alle ATX-kompatiblen Mainboards aktivieren kann. Der Komfort der alten Macs für moderne PCs: Ein- und Ausschalten von der Tastatur aus, ohne unter den Tisch greifen zu müssen. Multimedia-Tasten (Laut, Leise, Stumm, Browser starten, Rechner starten) brauche ich nicht, die ersetze ich durch Hotkey-Kombinationen mit der Logo-Taste (über Winkey und ein selbstgeschriebenes Programm oder AutoHotkey), damit habe ich so ca. 90 Multimedia-Tasten, von denen ich so etwa 20 wirklich nutze.

        Alexander

        --
        Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".
        1. Ach, den alten Indianer hab ich völlig vergessen. Windows hab ich genannt, GNU/Linux schimmert zwischen den Zeilen durch, da dann am liebsten die Slackware; Solaris und BSDs hatte ich auch schon unter den Fingern.

          iTunes ist auch ein Werkzeug. Das versorgt meinen Kopfhörer mit genug Pegel, damit mich die ganzen Idi-äh... Kollegen, die durch mein Büro rennen MÜSSEN[1], nicht stören und gar nicht erst auf die Idee kommen, mich wegen irgendwelchem Unsinn anzusprechen.

          Alexander

          [1] Ja, mein Chef hat das so entschieden. Nicht fragen, macht nur noch mehr Kopfschmerzen. In sofern ist ein RUHIGES, abgeschiedenes Büro auch ein Werkzeug, dass ich schmerzlich vermisse. Ein Durchgangszimmer ist kein Platz für einen Entwickler, ebenso wenig wie ein Großraumbüro.

          --
          Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".
        2. Hallo,

          Versionsverwaltung: Subversion, TortoiseSVN

          Oh Gott, wäre es nicht langsam höchste Zeit mal auf Git oder Mercurial umzusteigen?

          Jeena

          1. Hello Jeena,

            Versionsverwaltung: Subversion, TortoiseSVN
            Oh Gott, wäre es nicht langsam höchste Zeit mal auf Git oder Mercurial umzusteigen?

            Könntest Du bitte mal die Funktionsweise und die Vorteile von Git schildern?

            Und wo wir schon mal bei Versionsverwaltung sind: Welches System lässt denn genügend Raum für die Gedanken, die zu Versionsänderungen geführt haben. Begründungen gehören immer zum Projekt, aber nicht unbedingt als Kommentar in den Quelltext.

            Liebe Grüße aus dem schönen Oberharz

            Tom vom Berg

            --
             ☻_
            /▌
            / \ Nur selber lernen macht schlau
            http://bergpost.annerschbarrich.de
            1. Hallo,

              Könntest Du bitte mal die Funktionsweise und die Vorteile von Git schildern?

              Es funktioniert wie SVN nur dezentrall, so dass man keinen zentralen Server braucht (aber haben kann wenn man möchte). Jeder hat die ganze Repository komplett lokal als kopie. Dadurch (und weil es auch direkt in C geschrieben ist) ist alles erstens viel schneller und zweitens auch ohne Internetzugang benutzbar, d.h. ich kann auch von unterwegs aus die Sachen committen an denen ich arbeite.

              Und wo wir schon mal bei Versionsverwaltung sind: Welches System lässt denn genügend Raum für die Gedanken, die zu Versionsänderungen geführt haben. Begründungen gehören immer zum Projekt, aber nicht unbedingt als Kommentar in den Quelltext.

              Naja das kann man sowohl in SVN (so weit ich mich erinnere) wie auch in Git und Mercurial beim erstellen eines Tags machen, da kann man auch ne message mit dranhängen.

              Jeena

              1. Moin Moin!

                Könntest Du bitte mal die Funktionsweise und die Vorteile von Git schildern?
                Es funktioniert wie SVN nur dezentrall, so dass man keinen zentralen Server braucht (aber haben kann wenn man möchte).

                Also erstmal kein Gewinn gegenüber SVN für Einzelkämpfer oder ein kleines, überwiegend ortsfestes Team.

                Jeder hat die ganze Repository komplett lokal als kopie.

                Erstens stimmt das nicht ganz, denn es gibt in dem Sinne nicht "das" Repository, sondern jeder hat sein eigenes Repository, dass zwar viele Gemeinsamkeiten mit den anderen Repositories hat, aber nicht zwingend identisch ist.

                Zweitens muß ich so viel mehr Daten auf dem Client rumliegen haben. Bei Subversion muß ich mir nur den Teil holen, an dem ich gerade arbeite.

                In Zeiten von Terabyte-Platten ist das kein großes Problem. Problematisch ist schon eher, dass gerade im Firmenumfeld nicht jeder alle Sources haben soll. Insbesondere nicht, wenn derjenige mit dem Laptop auf Reisen geht, sollen so wenig wie möglich vertrauliche Daten auf dem Laptop liegen.

                Dadurch (und weil es auch direkt in C geschrieben ist) ist alles erstens viel schneller

                als was?

                C impliziert rasende Geschwindigkeit allein dadurch, dass man Sources durch den C-Compiler jagt statt z.B. einen Pascal- oder Fortran-Compiler zu benutzen? Geil! Das solltest Du unbedingt mal den Leuten erzählen, die sich mit C++, ObjectiveC und Java herumschlagen müssen. Und erst recht den armen Wichten, die sich immer noch mit Assembler-Optimierung quälen.

                Was glaubst Du denn, in welcher Sprache Subversion geschrieben ist? Schau mal nach! Kleiner Tipp: Die weitaus häufigsten Dateiendungen im Source-Archiv sind .c (425) und .h (210).

                und zweitens auch ohne Internetzugang benutzbar, d.h. ich kann auch von unterwegs aus die Sachen committen an denen ich arbeite.

                Aber nur in dein kleines Repository, die Kollegen sehen davon nichts, bis Du dich wieder ins Netz einklingst UND Deine Änderungen in alle anderen Repositories verteilst bzw. abholen läßt.

                Subversion kann ich durch SSH tunneln, das ist bei mir normale Betriebsart auch im LAN, und alles, was ich von unterwegs per DSL oder UMTS committe, sehen die Kollegen auch. Notfalls geht das auch über HTTP, das ist aber oft unerwünscht, weil die Projekte eben nicht Open Source sein sollen und der HTTP-Zugang wesentlich umständlicher zu verrammeln ist als SSH. VPN geht natürlich auch, aber auch dann gilt: SSH ist einfacher abzudichten als HTTP, denn Böses kommt nicht nur von außen, sondern auch von frustrierten oder schlicht gelangweilten Kollegen. Und mit SSH scheitern die meistens schon am nicht vorhandenen Key für den SSH-Zugang.

                Naja das kann man sowohl in SVN (so weit ich mich erinnere) wie auch in Git und Mercurial beim erstellen eines Tags machen, da kann man auch ne message mit dranhängen.

                Korrekt. Wobei Subversion Tags schlicht durch Umkopieren in ein Unterverzeichnis unter dem tags-Verzeichnis erschlägt. Nur weil Subversion ein sich die Kopiervorgänge merkt, wächst dabei das Repository eben nicht um das gesamte Volumen der kopierten Daten, wie man zunächst vermuten könnte, sondern nur um die Differenz zur Quelle (genau Null) plus Meta-Daten.

                Alexander

                --
                Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".
                1. Hallo,

                  Also erstmal kein Gewinn gegenüber SVN für Einzelkämpfer oder ein kleines, überwiegend ortsfestes Team.

                  Du scheinst dich schon so auf SVN eingeschworen zu haben dass du gar nichts anderes sehen willst, denn trotz dessen dass ich eindeutige Vorteile aufgezählt habe konstatierst du dass es keine gibt. Ich denke nicht dass eine weitere Diskussion wirklich sinn macht.

                  Erstens stimmt das nicht ganz, denn es gibt in dem Sinne nicht "das" Repository, sondern jeder hat sein eigenes Repository

                  "das" Repository ist dein eigenes Repository, das ganze ist wie gesagt dezentral

                  Dadurch (und weil es auch direkt in C geschrieben ist) ist alles erstens viel schneller
                  als was?

                  Als SVN. Und dass du dich auf den Nebensatz der in Klammern steht so einschießt aber das Hauptargument dass alles Lokal ist und es deshalb schneller ist völlig ignorierst verstehe ich nicht.

                  Aber nur in dein kleines Repository,

                  Was meinst du mit klein? Es ist das komplette Repository.

                  die Kollegen sehen davon nichts, bis Du dich wieder ins Netz einklingst UND Deine Änderungen in alle anderen Repositories verteilst bzw. abholen läßt.

                  Ja, genauso wie bei SVN nur dass ich dazwischen jeden meiner Schritte committen kann, ich verstehe nicht wie du darin keinen Vorteil sehen kannst. Ist nicht das selektive committen der zentrale Sinn jeder Versionsverwaltung?

                  Subversion kann ich durch SSH tunneln

                  Ich verstehe nicht was du mir damit sagen möchtest, das ganze scheint mir völlig irrelevant. Solange du kein Internet hast kannst du nichts kommitten, und das ist der mega Nachteil von SVN. Du kannst dann zwar weiter am code arbeiten aber zum schluss committest du einen mega klumpen den man nur als großen klumpen wieder zurückspulen kann, man kann nicht einen kleinen Teilbereich zurückspulen weil du ja wenn du den ganzen Tag kein Internet hast auch nichts committen kannst.

                  Ich sehe ja schon dass du nur auf der Arbeit arbeitest und da immer an einem fest installiertem Rechner der mit Kabel am Internet angeschlossen ist. Es gibt aber extrem viele wie mich die sehr viel Unterwegs sind und auch im Zug arbeiten, oder im Hotell oder mal draußen an der Sonne oder im Ausland. Oder wie oft fange ich ein kleineres Projekt an und weiß noch gar nicht ob das was sinnvolles wird so dass die Einrichtung einer Repository auf dem Firmen-Server nur wenig Sinn macht ich aber dennoch Versionierung haben möchte? "git init" und schon bin ich am versionieren und kann committen und wieder zurückspulen, taggen, branchen, mergen, etc. Später wenn sich herausstellt dass auch andere dran Teil haben wollen wird es halt mit auf den Server gepackt und hat gleich die ganze History mit dabei.

                  Es kann eigentlich jedem sehr schnell passieren dass er mal in die Situation kommt wo er mal ohne ständigen Zugang zum Internet was arbeiten muss und wenn man sich erst da nach Lösungen umschauen muss dann ist es etwas spät. Da git/mercurial alles kann was SVN kann und einem noch die Freiheiten gibt alles Dezentral zu haben gibt es außer dass man mal was neues lernen muss, keine Nachteile. Wer aber davor Angst hat hat glaube ich in der IT nur wenig verloren.

                  Nun habe ich mich doch auf eine Diskussion eingelassen, aber was soll's kann sich ja vielleicht doch noch interessant entwickeln.

                  Jeena

                  1. Hi,

                    Nun habe ich mich doch auf eine Diskussion eingelassen, aber was soll's kann sich ja vielleicht doch noch interessant entwickeln.

                    vielleicht entdecke ich ja im Zuge dieser Diskussion endlich mal, was an so einer Versionsverwaltung so toll ist. Ich mein, wenn man als großes Team an einem Projekt arbeitet, ohne dass es eine klare Zuordnung der einzelnen Module zu einem Bearbeiter gibt, mag das Sinn machen. Aber dann hat man IMO schon in der Planung was falsch gemacht.

                    Der Normalfall dürfte doch sein, dass jeder Entwickler seinen abgegrenzten Teilbereich des Projekts mit klar definierten Schnittstellen bearbeitet, in den ihm kein anderer reinzupfuschen hat. Und dieser ihm zugewiesene Teilbereich ist dann wieder genauso zu sehen, als ob er allein irgendein Mini-Projekt bearbeitet. Das heißt, er hält stabile Versionen, Testversionen und wilde Experimente in verschiedenen Verzeichnissen vor und stellt seinen Kollegen jeweils das zur Verfügung, was er im Moment für "final" oder "ausgereift" hält (und behält die Testversionen unter Verschluss).

                    Ganz ehrlich, ich habe den Sinn eines Versionskontrollsystems bisher noch nicht verstanden. Wenn ich eine Version als "Milestone" konservieren will, dann archiviere ich den aktuellen Zwischenstand, und fertig. Das ist eine simple Kopieraktion (meinetwegen zusätzlich eine Komprimierung).

                    So long,
                     Martin

                    --
                    Finanztipp:
                    Leihen Sie sich Geld von einem Pessimisten.
                    Er rechnet sowieso nicht damit, dass er es zurückbekommt.
                    Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
                    1. Hallo,

                      Das heißt, er hält stabile Versionen, Testversionen und wilde Experimente in

                      Ganz genau, man kann in SVN/Git/Mercurial verschiedene Versionen eines codes gleichzeitig haben und teile dazwischen hin und her verschieben ohne angst haben zu müssen was kaputt zu machen denn jeder Schritt ist durch ein "Undo" rückgängig machbar.

                      verschiedenen Verzeichnissen vor

                      Oh nein, das hat zu viele Nachteile, der größte, es gibt keine "Undo" Möglichkeit fals man merkt dass der code den man in der Nacht zuvor geschrieben hat mehr kaputt macht als dass er weiterhilft kann man einfach ein paar mal "Undo" machen und ist zurück beim letzten Stand wo es noch gut funktioniert hat.

                      und stellt seinen Kollegen jeweils das zur Verfügung

                      Ja dazu gibt es diese Zentralen Server von denen man sich dann den jeweiligen code und die jeweiligen Versionen holen kann. Sehr vorteilhaft falls mal einer der Kolegen krank wird und jemand anderes was dringendes fixen muss. Man sieht bei jeder Zeile code auch wer sie verbrochen hat und wann und kann gegebenenfalls mal nachfragen was sich dieser dabei gedacht hat.

                      was er im Moment für "final" oder "ausgereift" hält (und behält die Testversionen unter Verschluss).

                      Jo viele haben einen master-branch in den nur ausgereifter code reinkommt der dann auch überall hin in production deployed wird und nebendran noch diverse development und test branches. Warum er aber die anderen Versionen unter Verschluss halten sollte leuchtet mir nicht ein. Wir arbeiten sehr oft zusammen und helfen uns gegenseitig aus. Dazu muss mir keiner irgendwelche Verzeichnisse per E-Mail schicken und bei jeder kleinen Veränderung wieder all den code noch mal schicken und ich dann meine Änderungen von hand in die neuere Version übertragen muss, das macht alles das merge kommando der Versionsverwaltung (zur Not fragt es mich was es machen soll, wenn es die beiden Versionen nicht selbst automatisch zusammenfügen kann).

                      Ganz ehrlich, ich habe den Sinn eines Versionskontrollsystems bisher noch nicht verstanden.

                      Ich hoffe ich konnte es dir hiermit etwas näherbringen, stell dir es vor wie ein unabhängiges Undo-System wo bei jedem Schritt auch beschrieben wird was gemacht wurde. Man kann auch selektiv Undo machen und zwischenschritte überspringen die doch funktionieren. Außerdem bekommt man ein großes log mit all den Veränderungen wer was wo wann und warum gemacht hat. Und man hat auch nur eine Kopie des codes sichtbar auf der Fesplatte, aber dennoch alle verschiedenen Versionen zugänglich, das spart Platz und ist vor allem Aufgeräumt. Außerdem ist standardisiert wie neue Versionen abgespeichert werden und man sieht nicht mehr so Listen auf der Fesplatte wie:

                      MyProject.1
                      MyProject.2
                      MyProject.3
                      MyProject.2008-08-11.4
                      MyProject.2008-08-11.5
                      MyProject.2008-08-12
                      MyProject.2008-08-12.1

                      bei denen man erst mal das Prinzip dessen der sich das System ausgedacht hat verstehen muss.

                      Wenn ich eine Version als "Milestone" konservieren will, dann archiviere ich den aktuellen Zwischenstand, und fertig. Das ist eine simple Kopieraktion (meinetwegen zusätzlich eine Komprimierung).

                      Im Versionssystem ist es nur ein Tag oder ein Label, der als String abgespeichert wird. Verbraucht nicht gleich den doppelten Platz, denn zwischen den Versionen werden immer nur die Veränderungen gespeichert, nicht der komplette Code.

                      Jeena

                    2. Moin Moin!

                      Nun habe ich mich doch auf eine Diskussion eingelassen, aber was soll's kann sich ja vielleicht doch noch interessant entwickeln.

                      vielleicht entdecke ich ja im Zuge dieser Diskussion endlich mal, was an so einer Versionsverwaltung so toll ist.

                      Undo.

                      Entwicklungsprozess nachvollziehbar machen.

                      "Wer zum Geier hat den Scheiß eingebaut?"

                      "Was hab ich in den letzten zwei Stunden eigentlich alles verändert?"

                      "Wann haben wir das Problem eingebaut, und welche Workarounds haben wir seitdem darum herum gebaut?"

                      Entwicklungsprozess in kleine Häppchen aufteilen.

                      Nach jedem kleinen Arbeitsschritt teste ich, was ich gebaut habe, wenn es funktioniert, committe ich es ins Repository. Der Stand ist sicher und gut, und von da aus kann ich weiter arbeiten. Wenn ich Mist gebaut habe, mache ich einen Revert, notfalls auch auf einen früheren Schritt.

                      Ich mein, wenn man als großes Team an einem Projekt arbeitet, ohne dass es eine klare Zuordnung der einzelnen Module zu einem Bearbeiter gibt, mag das Sinn machen. Aber dann hat man IMO schon in der Planung was falsch gemacht.

                      Was machst Du in Deinem Modell, wenn ein Kollege ausfällt? Warten, bis der Kollege wieder kommt?

                      Mit einer Versionsverwaltung kannst Du stumpf seinen letzten Stand forken und dort weiter entwickeln. Wenn der Kollege wieder auftaucht, kann er Deine Weiterentwicklung mergen und weiter arbeiten.

                      Der Normalfall dürfte doch sein, dass jeder Entwickler seinen abgegrenzten Teilbereich des Projekts mit klar definierten Schnittstellen bearbeitet, in den ihm kein anderer reinzupfuschen hat.

                      Das ist der akademische Traumfall. Die Realität sieht deutlich hässlicher aus. Du hast Tonnen von Legacy-Code, von denen niemand so recht weiß, was darin passiert, jeder hat mal drin herumgefummelt, und eigentlich hofft man immer, das einem das Zeug nicht um die Ohren fliegt.

                      Längst nicht jeder, der an Software rumbastelt, ist dafür auch qualifiziert. Leider. Das führt zu sehr gruseligen Konstruktionen. Siehe oben.

                      Und dieser ihm zugewiesene Teilbereich ist dann wieder genauso zu sehen, als ob er allein irgendein Mini-Projekt bearbeitet. Das heißt, er hält stabile Versionen, Testversionen und wilde Experimente in verschiedenen Verzeichnissen vor und stellt seinen Kollegen jeweils das zur Verfügung, was er im Moment für "final" oder "ausgereift" hält (und behält die Testversionen unter Verschluss).

                      Genauso entstanden diese Legacy-Monster, und sie entstehen noch immer. Irgendwo verstreut auf 30 alten Workstations, drei Fileservern, drei Generationen Mailservern, ein paar elektrisch und/oder mechanisch defekten Platten, und ein paar Umzugskartons voll Aktenordnern, Schnellheftern und losen Blättern liegen die Projektsources, niemand hat eine Idee, wie sie zusammenhängen und auseinander entwickelt wurden, niemand hat eine Idee, wie die Abhängigkeiten sind.

                      Das Equivalent zu diesen Verzeichnisbasteleien sind Revisionen und Branches, sauber nachvollziehbar mit Historie.

                      Ganz ehrlich, ich habe den Sinn eines Versionskontrollsystems bisher noch nicht verstanden. Wenn ich eine Version als "Milestone" konservieren will, dann archiviere ich den aktuellen Zwischenstand, und fertig. Das ist eine simple Kopieraktion (meinetwegen zusätzlich eine Komprimierung).

                      Das ist tagging, und mit Deiner Methode eine sehr teure Operation. Bei Versionsverwaltungen ist tagging fast kostenlos. Subversion braucht dafür, wie schon erwähnt, nur ein paar Meta-Daten zu speichern.

                      Wie viele Zwischenstände hältst Du für sichernswert? Bei mir sind es am Tag durchaus mal 10, 20 oder 30. Das kostet mich in SVN fast nichts, weil SVN nur für die Diffferenzen Platz braucht. Du würdest bei gleicher Arbeitsweise jeden Tag das 10fache, 20fache oder 30fache Deines Projektvolumens an Platz benötigen, und um Änderungen nachvollziehen zu können, müßtest Du jedes Mal wieder die Differenzen berechnen. Vom Aufwand des Packens und Entpackens will ich gar nicht anfangen. Und commit-Kommentare hast Du mit den Verzeichniskopien auch noch nicht.

                      Alexander

                      --
                      Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".
                      1. Hello,

                        Das Equivalent zu diesen Verzeichnisbasteleien sind Revisionen und Branches, sauber nachvollziehbar mit Historie.

                        Meinst Du "Komplement"? Dann würde ich den Satz noch einigermaßen verstehen.
                        Aber vermutlich meinst Du sogar "das Konträre", also das Gegenteil? :-)

                        Liebe Grüße aus dem schönen Oberharz

                        Tom vom Berg

                        --
                         ☻_
                        /▌
                        / \ Nur selber lernen macht schlau
                        http://bergpost.annerschbarrich.de
                      2. Hi,

                        vielleicht entdecke ich ja im Zuge dieser Diskussion endlich mal, was an so einer Versionsverwaltung so toll ist.
                        Undo.

                        kann ich jederzeit und ebensogut auch mit der Methode "Snapshot als Verzeichniskopie".

                        Entwicklungsprozess nachvollziehbar machen.
                          "Wer zum Geier hat den Scheiß eingebaut?"
                          "Was hab ich in den letzten zwei Stunden eigentlich alles verändert?"
                          "Wann haben wir das Problem eingebaut, und welche Workarounds haben wir seitdem darum herum gebaut?"

                        Kann ich jederzeit und ebensogut auch mit der Methode "Snapshot als Verzeichniskopie". Das "Wer" ergibt sich aus der Zuordnung der Projektbereiche zum jeweiligen Bearbeiter.

                        Entwicklungsprozess in kleine Häppchen aufteilen.

                        Kann ich ... ach, du weißt schon.

                        Nach jedem kleinen Arbeitsschritt teste ich, was ich gebaut habe, wenn es funktioniert, committe ich es ins Repository. Der Stand ist sicher und gut, und von da aus kann ich weiter arbeiten. Wenn ich Mist gebaut habe, mache ich einen Revert, notfalls auch auf einen früheren Schritt.

                        Mit der Snapshot-Methode ebenso.

                        Ich mein, wenn man als großes Team an einem Projekt arbeitet, ohne dass es eine klare Zuordnung der einzelnen Module zu einem Bearbeiter gibt, mag das Sinn machen. Aber dann hat man IMO schon in der Planung was falsch gemacht.
                        Was machst Du in Deinem Modell, wenn ein Kollege ausfällt? Warten, bis der Kollege wieder kommt?

                        Wenn es eine absehbar kurze Ausfallzeit ist (ein Tag, zwei Tage), dann ja. Sonst muss eben jemand anders einspringen und diesen Teil vorübergehend übernehmen. Das ist aber grundsätzlich problematisch, denn das Einarbeiten in fremde Software dauert auch unter günstigsten Umständen eine gewisse Zeit.

                        Mit einer Versionsverwaltung kannst Du stumpf seinen letzten Stand forken und dort weiter entwickeln. Wenn der Kollege wieder auftaucht, kann er Deine Weiterentwicklung mergen und weiter arbeiten.

                        Also kein Unterschied zu "meiner" Methode".

                        Der Normalfall dürfte doch sein, dass jeder Entwickler seinen abgegrenzten Teilbereich des Projekts mit klar definierten Schnittstellen bearbeitet, in den ihm kein anderer reinzupfuschen hat.
                        Das ist der akademische Traumfall. Die Realität sieht deutlich hässlicher aus. Du hast Tonnen von Legacy-Code, von denen niemand so recht weiß, was darin passiert, jeder hat mal drin herumgefummelt, und eigentlich hofft man immer, das einem das Zeug nicht um die Ohren fliegt.

                        Das ist wohl wahr, aber ein ganz anderes Problem, das mit dem Topic hier nichts zu tun hat.

                        Längst nicht jeder, der an Software rumbastelt, ist dafür auch qualifiziert. Leider. Das führt zu sehr gruseligen Konstruktionen. Siehe oben.

                        Klar. Das passiert dann aber auch mit dem ausgefeiltesten Versionskontrollsystem.

                        Und dieser ihm zugewiesene Teilbereich ist dann wieder genauso zu sehen, als ob er allein irgendein Mini-Projekt bearbeitet. Das heißt, er hält stabile Versionen, Testversionen und wilde Experimente in verschiedenen Verzeichnissen vor und stellt seinen Kollegen jeweils das zur Verfügung, was er im Moment für "final" oder "ausgereift" hält (und behält die Testversionen unter Verschluss).
                        Genauso entstanden diese Legacy-Monster, und sie entstehen noch immer.

                        Den Zusammenhang sehe ich nicht.

                        Ganz ehrlich, ich habe den Sinn eines Versionskontrollsystems bisher noch nicht verstanden. Wenn ich eine Version als "Milestone" konservieren will, dann archiviere ich den aktuellen Zwischenstand, und fertig. Das ist eine simple Kopieraktion (meinetwegen zusätzlich eine Komprimierung).
                        Das ist tagging, und mit Deiner Methode eine sehr teure Operation.

                        Ich bitte dich - im Zeitalter von Giga- und Terabyte-Platten? Es hat aber vor allem den Vorteil, dass auch jemand ohne dieses Versionskontrolldingsbums mal eben den kompletten aktuellen Projektstand vom Server ziehen kann. Man macht sich eben nicht von *noch einem* Tool abhängig.

                        Das ist nämlich ein Punkt, der *mich* oft stört, wenn Repos irgendwelcher Software im Internet angeboten werden: Man sucht meistens vergeblich nach einem Komplett-Download, sondern muss sich die Dateien einzeln ziehen und dabei auf die Hierarchie achten. Bei einem kompletten Snapshot als zip- oder sonstiges Archiv ergibt sich das von allein.

                        Wie viele Zwischenstände hältst Du für sichernswert? Bei mir sind es am Tag durchaus mal 10, 20 oder 30.

                        Oh. Bei mir variiert es zwischen einmal in drei Tagen und dreimal am Tag, je nachdem, wie ich vorankomme und welche Schritte ich für sicherungswürdig halte.

                        Ich ziehe also das Fazit, dass so ein Versionskontrollsystem die Chance für viel Bürokratie eröffnet, von der ich noch nie den Eindruck hatte, dass ich sie bräuchte. Weder für mich, noch für ein Team mit bis zu fünf Leuten. Die zusätzlichen Meta-Informationen, wie etwa den Grund für die neue Version und die Änderung in Stichworten, werden sowieso als Kommentar im Quelltext notiert - oder als zusätzliches Dokument.

                        So long,
                         Martin

                        --
                        Lieber Blödeleien als blöde Laien.
                        Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
                        1. Hallo,

                          Hehe irgendwie musste ich bei deinem Beitrag sehr schmunzeln, wenn ich dich nicht doch schon ein paar Jahre lesen und dadurch kennen würde hätte ich gesagt du bist ein Troll weil du Alexander auf exakt die gleiche Weise geantwortet hast wie er mir mit "Das alles geht doch mit meiner Methode auch also bringt es keinerlei Vorteile."

                          Jeena

                        2. Moin Moin!

                          Hi,

                          vielleicht entdecke ich ja im Zuge dieser Diskussion endlich mal, was an so einer Versionsverwaltung so toll ist.
                          Undo.

                          kann ich jederzeit und ebensogut auch mit der Methode "Snapshot als Verzeichniskopie".

                          Klar, aber Rechtsklick -> Commit, Kommentar, Enter bzw. svn commit -m "Kommentar" macht weniger Arbeit als mir erstmal wieder einen neuen Snapshot-Namen auszudenken, das ganze Zeugs zu kopieren, und den Commit-Kommentar in irgendeine Datei einzupflegen.

                          Das "Wer" ergibt sich aus der Zuordnung der Projektbereiche zum jeweiligen Bearbeiter.

                          Nicht bei Krankheitsvertretungen etc. Nicht, wenn mehrere Leute an einem Stück SW arbeiten.

                          Was machst Du in Deinem Modell, wenn ein Kollege ausfällt? Warten, bis der Kollege wieder kommt?

                          Wenn es eine absehbar kurze Ausfallzeit ist (ein Tag, zwei Tage), dann ja. Sonst muss eben jemand anders einspringen und diesen Teil vorübergehend übernehmen. Das ist aber grundsätzlich problematisch, denn das Einarbeiten in fremde Software dauert auch unter günstigsten Umständen eine gewisse Zeit.

                          Richtig. Die kann, wenn man eng zusammenarbeitet, aber recht kurz sein. Und wenn Du die Arbeit eben nicht nach Source-Dateien aufteilst, sondern nach anfallenden Änderungen, dann faßt jeder irgendwann mal alle Dateien an.

                          Mit einer Versionsverwaltung kannst Du stumpf seinen letzten Stand forken und dort weiter entwickeln. Wenn der Kollege wieder auftaucht, kann er Deine Weiterentwicklung mergen und weiter arbeiten.

                          Also kein Unterschied zu "meiner" Methode".

                          Außer, dass Du viel mehr manuell erledigen mußt.

                          Der Normalfall dürfte doch sein, dass jeder Entwickler seinen abgegrenzten Teilbereich des Projekts mit klar definierten Schnittstellen bearbeitet, in den ihm kein anderer reinzupfuschen hat.
                          Das ist der akademische Traumfall. Die Realität sieht deutlich hässlicher aus. Du hast Tonnen von Legacy-Code, von denen niemand so recht weiß, was darin passiert, jeder hat mal drin herumgefummelt, und eigentlich hofft man immer, das einem das Zeug nicht um die Ohren fliegt.

                          Das ist wohl wahr, aber ein ganz anderes Problem, das mit dem Topic hier nichts zu tun hat.

                          Doch. Mit einer Versionsverwaltung kannst Du zum letzten bekannt guten Zustand zurück, OHNE dich durch Tonnen von verteilt herumliegenden Snapshots kämpfen zu müssen.

                          Längst nicht jeder, der an Software rumbastelt, ist dafür auch qualifiziert. Leider. Das führt zu sehr gruseligen Konstruktionen. Siehe oben.

                          Klar. Das passiert dann aber auch mit dem ausgefeiltesten Versionskontrollsystem.

                          Richtig. Aber da merken die fähigeren Kollegen, die sich gelegentlich die Commits und Diffs ansehen, dass jemand Schrott baut, und können gegensteuern.

                          Ganz ehrlich, ich habe den Sinn eines Versionskontrollsystems bisher noch nicht verstanden. Wenn ich eine Version als "Milestone" konservieren will, dann archiviere ich den aktuellen Zwischenstand, und fertig. Das ist eine simple Kopieraktion (meinetwegen zusätzlich eine Komprimierung).
                          Das ist tagging, und mit Deiner Methode eine sehr teure Operation.

                          Ich bitte dich - im Zeitalter von Giga- und Terabyte-Platten?

                          Mal sehen:

                          SVN-Verzeichnis auf dem $WORK-Server belegt rund 500 MByte, das dürfte angesichts der großen Menge von Altlasten auch so in etwa die Größe eines vollständigen Exports sein, auf dem Du Snapshots aufsetzen würdest. Die ursprüngliche Größe liegt einige KByte drunter, aber nicht sehr viel, weil der Code hauptsächlich umgebaut wird, aber selten größere Mengen neuen Codes dazu kommen.

                          Die aktuelle Revisionsnummer ist 1037.

                          Du hättest jetzt etwas über 1000 Snapshots à 500 MByte herumliegen und damit eine 500 GByte-Platte komplett gefüllt.

                          Die aktuelle Revisionsnummer von Python, als Beispiel für ein Projekt mit mehr Entwicklern und mehr Entwicklungszeit ist irgendwas knapp unter 90.000. SVN selbst liegt, dank der Integration in Apaches Repository, mittlerweile bei über 1.300.000.

                          Es hat aber vor allem den Vorteil, dass auch jemand ohne dieses Versionskontrolldingsbums mal eben den kompletten aktuellen Projektstand vom Server ziehen kann.

                          Nächtlicher automatischer Export.

                          Man macht sich eben nicht von *noch einem* Tool abhängig.

                          Echte Programmierer kommen ohne alle Tools aus.

                          SVN kommt (wie auch andere Systeme) mit guten Betriebssystemen gleich mit, für den Rest gibt's die Software-Verteil-Software, die jedem User, der in der Gruppe der Entwickler ist, die Software installiert. Und in kleinen Läden, die keine automatische Software-Verteilung haben, muß sich der Entwickler seine Kiste ohnehin meistens selbst installieren.

                          SVN-Clients sind auch in diverse IDEs integriert, allen voran Eclipse. Microsoft hat mit VSS ähnliches für Visual Studio gestrickt.

                          Das ist nämlich ein Punkt, der *mich* oft stört, wenn Repos irgendwelcher Software im Internet angeboten werden: Man sucht meistens vergeblich nach einem Komplett-Download, sondern muss sich die Dateien einzeln ziehen und dabei auf die Hierarchie achten. Bei einem kompletten Snapshot als zip- oder sonstiges Archiv ergibt sich das von allein.

                          Äh, wie?

                          svn checkout svn://svn.example.com/svn/foo/bar/trunk, wenn Du basteln willst, svn export svn://svn.example.com/svn/foo/bar/trunk, wenn nicht.

                          Viele Projekte erzeugen auch automatisch Archive vom trunk und vom HEAD.

                          Ich ziehe also das Fazit, dass so ein Versionskontrollsystem die Chance für viel Bürokratie eröffnet, von der ich noch nie den Eindruck hatte, dass ich sie bräuchte. Weder für mich, noch für ein Team mit bis zu fünf Leuten.

                          Die *CHANCE* für viel Bürokrate. Out of the Box sind VCS aber sehr unbürokratisch. Du kannst - wenigstens bei SVN - jede Menge Hooks installieren, die Dir jede Menge Bürokratie bringen, angefangen bei automatischen Tests auf korrekten Coding Style. So einen Quatsch machen aber nur Bürokraten, denen man erlaubt, den Entwicklern reinzupfuschen.

                          Die zusätzlichen Meta-Informationen, wie etwa den Grund für die neue Version und die Änderung in Stichworten, werden sowieso als Kommentar im Quelltext notiert - oder als zusätzliches Dokument.

                          *DAS* artet in Bürokratie aus. Ich bin hier ($WORK) wortwörtlich von Tonnen von Papier umgeben, auf dem Amateure ihre historischen Programmversionen und Änderungsdokumentationen ausgedruckt haben. Versionsverwaltung komplett auf Papier. Kein Witz. Und die Idee mit "Ich schreib Änderungen in Kommentare" treibt sich hier auch rum. Mit dem Ergebnis, das ungefähr die Hälfte der Änderungen versehentlich oder aus Faulheit eben NICHT als Änderungen mit einem Kommentar gekennzeichnet sind, und ebenso nur ungefähr die Hälfte der Änderungen tatsächlich dokumentiert sind. Die bürokratischen Richtlinien dafür (von denen es hier reichlich gibt), geben etwas anderes vor, aber Richtlinie und Realität haben eben oft nur sehr wenig gemeinsam.

                          Wie kommentierst Du übrigens gelöschte Zeilen? ;-)

                          Alexander

                          --
                          Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".
                          1. Hello und Sorry Jungs,
                            (die Mädels diskutieren ja derzeit nicht mit, oder?)

                            Man macht sich eben nicht von *noch einem* Tool abhängig.

                            Echte Programmierer kommen ohne alle Tools aus.

                            Da habe ich jetzt wohl eine Philosphie-Diskussion ausgelöst mit meinem "Dranhänger"?

                            Meint Ihr, dass wir die Erkenntnisse aus dem Gesamt-Thread nachher gemeinsam zu einem WIKI-Artikel weiterentwickeln könnten, in dem dann jeder "seine" Vorteile nochmal zusammengefasst schildert?

                            Ich muss jedenfalls jedesmal, wenn ich für Freunde einen "Webworking-Arbeitsplatz" aufsetzen soll, erstmal nachdenken, was die dann alles gebrauchen und _verstehen_ können. Da bin ich mit SVN oder ähnlichen Techniken dann jua auch erstmal überfordert, den Nutzen zu erklären.

                            Wenn ich Aufträge in Firmen bekomme, dann schreiben die mir das sowieso vor. Da gibt es noch gaaaaanz andere Systeme.

                            Liebe Grüße aus dem schönen Oberharz

                            Tom vom Berg

                            --
                             ☻_
                            /▌
                            / \ Nur selber lernen macht schlau
                            http://bergpost.annerschbarrich.de
                            1. Hallo,

                              in dem dann jeder "seine" Vorteile nochmal zusammengefasst schildert?

                              Ich denke nicht dass es sinnvoll ist dass wir "jeder Seite" dort als gleichwertig darstellen. Auf der einen Seite gibt es Martin und auf der anderen Seite eigentlich fast alle anderen professionellen Entwickler, das ist kein 50:50 Ding. Wenn man denn die Wirklichkeit abbilden möchte dann schreibt man einen Artikel über Versionssysteme, zeigt ein paar Beispiele auf von RCS/CSV/SVN/Git/Mercurial (die meisten über SVN und Git weil das die meistbenutzten sind obwohl SVN stark abgenommen und Git stark zugenommen hat), zeigt da die Unterschiede auf und die Vorteile der einzelnen gegenüber den anderen und schreibt in einem Satz noch dazu dass es auch möglich ist wie vor RCS zu arbeiten, wie Martin es noch macht.

                              Jeena

                              1. Moin Moin!

                                in dem dann jeder "seine" Vorteile nochmal zusammengefasst schildert?
                                Ich denke nicht dass es sinnvoll ist dass wir "jeder Seite" dort als gleichwertig darstellen. Auf der einen Seite gibt es Martin und auf der anderen Seite eigentlich fast alle anderen professionellen Entwickler, das ist kein 50:50 Ding.

                                Vollkommen richtig.

                                Wenn man denn die Wirklichkeit abbilden möchte dann schreibt man einen Artikel über Versionssysteme, zeigt ein paar Beispiele auf von RCS/CSV/SVN/Git/Mercurial (die meisten über SVN und Git weil das die meistbenutzten sind obwohl SVN stark abgenommen und Git stark zugenommen hat), zeigt da die Unterschiede auf und die Vorteile der einzelnen gegenüber den anderen und schreibt in einem Satz noch dazu dass es auch möglich ist wie vor RCS zu arbeiten, wie Martin es noch macht.

                                Du meinst: Vor dem mitterweile 40 Jahre alten SCCS. RCS ist 10 Jahre jünger.

                                CVS ist immer noch in Gebrauch, z.B. liegen sämtliche OpenBSD-Sources nach wie vor in einem CVS-Repository, und anscheinend hat niemand die Absicht, das zu ändern. Gleiches gilt für FreeBSD und [http://cvsweb.netbsd.org/@title=NetBSD].

                                Für neue Projekte wird aber typischerweise empfohlen, SVN oder neuer zu benutzen. Außer man arbeitet in einem MS-verseuchten Laden, da wird man vermutlich zu VSS oder TFS "überredet".

                                Perl wurde 2008 mit sehr viel Aufwand von Perforce und alten Archiven auf Git migriert, mit der gesamten Historie bis zu Perl 1.0 von 1987.

                                Wie man mit Git im allgemeinen und mit dem Perl-Repository im besonderen umgeht, ist z.B. in perlrepository nachzulesen, das wäre zuindest eine Grundlage für einen SelfWiki-Artikel. Noch schlauer wäre es natürlich, vorher mal zu recherchieren, was es bereits an deutschsprachigen Artikeln zum Thema gibt. Man muß das Rad ja nicht das millionste Mal neu erfinden.

                                Alexander

                                --
                                Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".
                          2. Hallo,

                            kann ich jederzeit und ebensogut auch mit der Methode "Snapshot als Verzeichniskopie".
                            Klar, aber Rechtsklick -> Commit, Kommentar, Enter bzw. svn commit -m "Kommentar" macht weniger Arbeit als mir erstmal wieder einen neuen Snapshot-Namen auszudenken, das ganze Zeugs zu kopieren, und den Commit-Kommentar in irgendeine Datei einzupflegen.

                            streiche "ausdenken". Verzeichnisname ergibt sich bei mir gewöhnlich aus Projektname, Bindestrich, ISO-Datum, Bindestrich, Uhrzeit.

                            Also kein Unterschied zu "meiner" Methode".
                            Außer, dass Du viel mehr manuell erledigen mußt.

                            Sehe ich als Vorteil. Manuell erledigen heißt, ich *weiß* genau, was passiert und kann es jederzeit den Erfordernissen anpassen.

                            Das ist wohl wahr, aber ein ganz anderes Problem, das mit dem Topic hier nichts zu tun hat.
                            Doch. Mit einer Versionsverwaltung kannst Du zum letzten bekannt guten Zustand zurück, OHNE dich durch Tonnen von verteilt herumliegenden Snapshots kämpfen zu müssen.

                            Wer spricht von verteilt herumliegenden Sachen? Selbstverständlich gehe ich von einem geordneten Verzeichnis auf einem zentralen Server aus.

                            Ich bitte dich - im Zeitalter von Giga- und Terabyte-Platten?
                            Mal sehen:
                            SVN-Verzeichnis auf dem $WORK-Server belegt rund 500 MByte, ...

                            Erstens: Ich gehe von kleineren Dimensionen aus. Die Projekte, an denen ich bisher beteiligt war, lagen allerhöchstens bei 15..20MB Sourcen.

                            Zweitens: Vollständige Snapshots bewahre ich nur maximal zwei bis drei Known-Good-Stände zurück auf. Ältere Zwischenstände werden gelöscht, und nur noch wesentliche Milestones aufbewahrt. Das macht also insgesamt vielleicht 20..30 Einzelstände. Und auch die verschwinden (mit Ausnahme des letzten), wenn das Projekt einen Status erreicht, den man im weitesten Sinn als "abgeschlossen" bezeichnen will.

                            Es hat aber vor allem den Vorteil, dass auch jemand ohne dieses Versionskontrolldingsbums mal eben den kompletten aktuellen Projektstand vom Server ziehen kann.
                            Nächtlicher automatischer Export.

                            Wird aber anscheinend selten gemacht. Was habe ich neulich noch gesucht? ... Hmm, vergessen. Jedenfalls gab's für dieses Projekt auch ein Online-Repository, und ich hab mir'n Wolf gesucht, aber nirgends eine Möglichkeit für einen Komplett-Download gefunden. Sowas ist dann frustrierend.

                            Das ist nämlich ein Punkt, der *mich* oft stört, wenn Repos irgendwelcher Software im Internet angeboten werden: Man sucht meistens vergeblich nach einem Komplett-Download, sondern muss sich die Dateien einzeln ziehen und dabei auf die Hierarchie achten. Bei einem kompletten Snapshot als zip- oder sonstiges Archiv ergibt sich das von allein.
                            Äh, wie?
                            svn checkout svn://svn.example.com/svn/foo/bar/trunk, wenn Du basteln willst, svn export svn://svn.example.com/svn/foo/bar/trunk, wenn nicht.

                            Ich sprach von einer Zugriffsmöglichkeit *ohne* VCS, also beispielsweise ein direkter HTTP- oder FTP-Download. Oder eben ein Zugriff übers Dateisystem.

                            Die zusätzlichen Meta-Informationen, wie etwa den Grund für die neue Version und die Änderung in Stichworten, werden sowieso als Kommentar im Quelltext notiert - oder als zusätzliches Dokument.
                            *DAS* artet in Bürokratie aus.

                            Empfinde ich nicht so.

                            Ich bin hier ($WORK) wortwörtlich von Tonnen von Papier umgeben, auf dem Amateure ihre historischen Programmversionen und Änderungsdokumentationen ausgedruckt haben. Versionsverwaltung komplett auf Papier. Kein Witz.

                            Ich halte große Stücke auf gedruckte Dokumentation, aber *nur* auf Papier ist Murks.

                            Wie kommentierst Du übrigens gelöschte Zeilen? ;-)

                            Wozu? Ich will ja nicht jeden Bearbeitungsschritt dokumentieren, sondern nur die Idee, das Ziel und das Ergebnis der Überarbeitung. Und das Verfahren da, wo der entsprechende Code steht. Nur im Ausnahmefall steht da mal ein Hinweis auf eine konkrete Anweisung, die aus einem ganz bestimmten Grund entfallen ist.

                            Ciao,
                             Martin

                            --
                            Die letzten Worte des Neandertalers:
                            Möchte doch zu gern wissen, was in der Höhle ist ...
                            Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
                            1. Hallo,

                              streiche "ausdenken". Verzeichnisname ergibt sich bei mir gewöhnlich aus Projektname, Bindestrich, ISO-Datum, Bindestrich, Uhrzeit.
                              Sehe ich als Vorteil. Manuell erledigen heißt, ich *weiß* genau, was passiert und kann es jederzeit den Erfordernissen anpassen.

                              Beim Versionssystem weißt du das genauso. Nicht nur das, jeder kann genau nachvollziehen was du konkret gemacht hast. Ich gebe dir mal ein Beispiel. Ich und mein Bruder schreiben ein kleines Multiplayer Spiel. Jetzt haben wir gemerkt dass es doch cool wäre zentral Kontanten zu haben die dann von verschiedenen Modulen benutzt werden können anstatt dass alle nur Strings oder magic-numbers nutzen. Wir haben dafür ein Issue im Bugtracker erstellt und ein paar Tage später hat er sich dieses Issue zugewiesen und gefixt, d.h. er hat so ein Modul gebaut und überall verteilt im Code die strings und magic-numbers queer im ganzen Projekt ersetzt. Am ende hat er es committet. Wenn ich jetzt sehen möchte was genau er verändert hat kann ich mir einfach das eine commit angucken:


                              added Constants module. fixes #4

                              Wer spricht von verteilt herumliegenden Sachen? Selbstverständlich gehe ich von einem geordneten Verzeichnis auf einem zentralen Server aus.

                              Dann kann man ja gleich ein Versionssystem nutzen, das macht das ganze viel einfacher da alle eh schon wissen wie man das benutzt und es dadurch einheitlich wird.

                              Zweitens: Vollständige Snapshots bewahre ich nur maximal

                              Mit einem Versionssystem bekommst du von jedem Schritt einen vollständigen Snapshot ohne signifikante Nachteile.

                              Wird aber anscheinend selten gemacht. Was habe ich neulich noch gesucht? ... Hmm, vergessen. Jedenfalls gab's für dieses Projekt auch ein Online-Repository, und ich hab mir'n Wolf gesucht, aber nirgends eine Möglichkeit für einen Komplett-Download gefunden. Sowas ist dann frustrierend.

                              Das liegt daran dass

                              git clone http://example.com/my-repo.git

                              oder

                              svn checkout http://example.com/my-repo/trunk

                              das ganze ohne die ganzen Nachteile anbieten. (Und falls die aktuelle Version nicht funktioniert kann sich derjenige der das runterladen will auch genauso einfach eine frühere revision runterladen.)

                              Ich sprach von einer Zugriffsmöglichkeit *ohne* VCS, also beispielsweise ein direkter HTTP- oder FTP-Download. Oder eben ein Zugriff übers Dateisystem.

                              Um zugriff über HTTP zu bekommen musst du auch ein Programm haben das das kann, also einen Browser oder wget, etc., für FTP genauso. Du handelst dir mit SVN oder Git aber nicht die ganzen Nachteile ein. Darüber hinaus werden z.b. von Git Abhängigkeiten, mit Hilfe von git submodule, automatisch aufgelöst. Das alles von Hand zu machen ist eigentlich grundsätzlich ein k(r)ampf.

                              Ich halte große Stücke auf gedruckte Dokumentation, aber *nur* auf Papier ist Murks.

                              Naja Dokumentation und commits haben aber miteinander kaum etwas zu tun. Ein commit ist die Beschreibung einer Änderung während des Entwickelns. Eine Dokumentation ist die Beschreibung wie man das Programm benutzt.
                              Ich weise da noch einmal auf das commit-Beispiel von weiter Oben hin. Wenn ich jetzt als Chef-Programmierer oder Mitentwickler sehen möchte was die anderen gemacht haben kann ich mir einfach das commit Log angucken und sehe dann dort dass der Bug #4 gefixt wurde, von web, wann und wie. So etwas geht mit deiner Methode halt gar nicht ohne stundenlangen Aufwand und schulungen wie man das jetzt bei euerer firma macht. Und jeder neue Mitarbeiter muss das komplett neu lernen. Git und SVN können eigentlich alle professionellen Entwickler, und falls nicht dann würde ich ehrlicherweise davon abraten sie einzustellen.

                              Jeena

                              1. Hallo Jeena

                                … Git und SVN können eigentlich alle professionellen Entwickler, und falls nicht dann …

                                … ist das innerhalb von ein paar Stunden gelernt (zumindest soweit, wie es zum Benutzen des Systems nötig ist).

                                Ich kann mich nicht daran erinnern irgendwelche Probleme damit gehabt zu haben, als ich damals begann an der Dokumentation mitzuarbeiten. (Ich hatte vorher noch nie mit SVN oder anderen Versionsverwaltungssystemen zu tun.)

                                Auf Wiederlesen
                                Detlef

                                --
                                - Wissen ist gut
                                - Können ist besser
                                - aber das Beste und Interessanteste ist der Weg dahin!
                              2. Hi,

                                Wer spricht von verteilt herumliegenden Sachen? Selbstverständlich gehe ich von einem geordneten Verzeichnis auf einem zentralen Server aus.
                                Dann kann man ja gleich ein Versionssystem nutzen, das macht das ganze viel einfacher da alle eh schon wissen wie man das benutzt ...

                                nein, *manche* wissen es. Bei weitem nicht alle.

                                Wird aber anscheinend selten gemacht. Was habe ich neulich noch gesucht? ... Hmm, vergessen.

                                Doch, jetzt weiß ich's wieder: Ich suchte Dragonfly zur festen lokalen Installation.

                                Jedenfalls gab's für dieses Projekt auch ein Online-Repository, und ich hab mir'n Wolf gesucht, aber nirgends eine Möglichkeit für einen Komplett-Download gefunden. Sowas ist dann frustrierend.

                                Ich sprach von einer Zugriffsmöglichkeit *ohne* VCS, also beispielsweise ein direkter HTTP- oder FTP-Download. Oder eben ein Zugriff übers Dateisystem.
                                Um zugriff über HTTP zu bekommen musst du auch ein Programm haben das das kann, also einen Browser oder wget, etc., für FTP genauso.

                                Ja klar. Hab ich. Haben wohl auch die meisten. Und das wird wohl auch der meistverwendete Weg sein, um Software runterzuladen. Scheitert eben nur dann, wenn die "Macher" nur ein Repo mit Sources zur Verfügung stellen, aber nichts Fertiges. Wobei ein zip-Archiv mit dem kompletten Source-Code und einem Makefile (oder Build-Anleitungen für gängige Compiler) ja auch schon fast etwas Fertiges wäre.

                                Du handelst dir mit SVN oder Git aber nicht die ganzen Nachteile ein.

                                Doch, angefangen damit, dass ich mir *noch ein weiteres* Tool installieren, mich in dessen Handhabung einarbeiten und meine gewohnte Arbeitsweise umstellen muss. Das ist es doch, was ich nach Möglichkeit vermeide.

                                Ich halte große Stücke auf gedruckte Dokumentation, aber *nur* auf Papier ist Murks.
                                Naja Dokumentation und commits haben aber miteinander kaum etwas zu tun. Ein commit ist die Beschreibung einer Änderung während des Entwickelns. Eine Dokumentation ist die Beschreibung wie man das Programm benutzt.

                                Nein. Das ist zwar ein Teil der Dokumentation (nämlich die Bedienungsanleitung oder User's Manual). Unter Dokumentation von Software verstehe ich aber vor allem eine ausführliche Beschreibung der Struktur, der inneren Zusammenhänge, der prinzipiellen Funktion und der Schnittstellen. Die Dokumentation einer Software ist das, was mir das nötige Wissen vermittelt, um an dieser Software mitzuentwickeln. Der Endanwender kriegt diese Dokumentation normalerweise nie zu Gesicht.
                                Und diese Dokumentation entsteht zum Großteil, bevor die Softwareentwickler und Programmierer überhaupt loslegen, zu einem kleinen Teil noch während der Entstehung des Projekts. Manchmal auch erst hinterher, das sollte aber eigentlich nicht sein.

                                Git und SVN können eigentlich alle professionellen Entwickler

                                Nö. Bei meinem früheren Arbeitgeber gab es fünf Softwareentwickler (ich gehörte nicht dazu), von denen hatte nur einer schon mal was von Versionskontrollsystemen gehört und wäre geneigt gewesen, eins zu benutzen. Den anderen hat man mit einer Präsentation eines Externen mal die Möglichkeiten aufgezeigt und grob erläutert, worum es da geht - und dann wollten sie es erst recht nicht mehr haben. Ich kann's verstehen ...

                                Ciao,
                                 Martin

                                --
                                Treffen sich zwei Holzwürmer im Käse: "Na, auch Probleme mit den Zähnen?"
                                Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
                                1. Hallo,

                                  nein, *manche* wissen es. Bei weitem nicht alle.

                                  Ich mache das ganze seit 2006 Professionell und es ist mir kein einziger untergekommen der kein SVN anwenden konnte, mittlerweile steigen die meisten auf Git um. Die Anwendung von Versionierungssystemen gehört zu den Grundwerkzeugen eines Softwareentwicklers, wenn er nicht einmal das kann, kann man davon ausgehen dass er höchstens ein guter Ameteur ist. Das ist eine der Voraussetzungen die man nicht einmal mehr in die Stellenausschreibung schreibt weil man voraussetzt dass das jeder kann.

                                  Um zugriff über HTTP zu bekommen musst du auch ein Programm haben das das kann, also einen Browser oder wget, etc., für FTP genauso.
                                  Ja klar. Hab ich. Haben wohl auch die meisten. Und das wird wohl auch der meistverwendete Weg sein, um Software runterzuladen. Scheitert eben nur dann, wenn die "Macher" nur ein Repo mit Sources zur Verfügung stellen, aber nichts Fertiges. Wobei ein zip-Archiv mit dem kompletten Source-Code und einem Makefile (oder Build-Anleitungen für gängige Compiler) ja auch schon fast etwas Fertiges wäre.

                                  Versionierungssysteme gehören halt zum Grundwerkzeug eines Softwareentwicklers wie GCC, Python und wget, das ist doch kein wirkliches Argument, du sagst ja auch nicht "Das ist doch alles scheiße ich muss mir erst GCC installieren damit ich das Programm kompilieren kann".

                                  Doch, angefangen damit, dass ich mir *noch ein weiteres* Tool installieren, mich in dessen Handhabung einarbeiten und meine gewohnte Arbeitsweise umstellen muss. Das ist es doch, was ich nach Möglichkeit vermeide.

                                  Es ist eben nicht *noch ein weiteres Tool* sondern es ist *das Tool* zur Verwaltung von Source Code. Dass man das 2012 noch vermeidet zu lernen zeugt eigentlich nur von Stillstand, unter diesen Voraussetzungen wird es sehr schwierig sein in Zukunft noch einen neuen Job zu finden.

                                  Ich halte große Stücke auf gedruckte Dokumentation, aber *nur* auf Papier ist Murks.
                                  Naja Dokumentation und commits haben aber miteinander kaum etwas zu tun. Ein commit ist die Beschreibung einer Änderung während des Entwickelns. Eine Dokumentation ist die Beschreibung wie man das Programm benutzt.

                                  Nein. Das ist zwar ein Teil der Dokumentation (nämlich die Bedienungsanleitung oder User's Manual). Unter Dokumentation von Software verstehe ich aber vor allem eine ausführliche Beschreibung der Struktur, der inneren Zusammenhänge, der prinzipiellen Funktion und der Schnittstellen. Die Dokumentation einer Software ist das, was mir das nötige Wissen vermittelt, um an dieser Software mitzuentwickeln. Der Endanwender kriegt diese Dokumentation normalerweise nie zu Gesicht.

                                  Ja nichts anderes habe ich auch geschrieben, du beschreibst hier die Dokumentation für Entwickler, das hat nichts mit der Beschreibung der Änderungen im Code zu tun was durch Commits gemacht wird. Ich habe leider das Gefühl dass du mein verlinktes Beispiel eines Commits nicht einmal aufgerufen hast, und falls doch dann nicht verstanden hast.

                                  Git und SVN können eigentlich alle professionellen Entwickler
                                  Nö.

                                  Doch.

                                  Bei meinem früheren Arbeitgeber gab es fünf Softwareentwickler (ich gehörte nicht dazu), von denen hatte nur einer schon mal was von Versionskontrollsystemen gehört und wäre geneigt gewesen, eins zu benutzen. Den anderen hat man mit einer Präsentation eines Externen mal die Möglichkeiten aufgezeigt und grob erläutert, worum es da geht - und dann wollten sie es erst recht nicht mehr haben. Ich kann's verstehen ...

                                  Sie waren wohl schon älter und hatten auch angst etwas neues zu lernen? Sehr schade dass das auch auf dich abgefärbt hat.

                                  Jeena

                                  1. Hi,

                                    Versionierungssysteme gehören halt zum Grundwerkzeug eines Softwareentwicklers

                                    nein, sie sind *eine* mögliche Herangehensweise. Das zur Selbstverständlichkeit hochzustilisieren, ist mutig.

                                    Es ist eben nicht *noch ein weiteres Tool* sondern es ist *das Tool* zur Verwaltung von Source Code. Dass man das 2012 noch vermeidet zu lernen zeugt eigentlich nur von Stillstand, unter diesen Voraussetzungen wird es sehr schwierig sein in Zukunft noch einen neuen Job zu finden.

                                    "Man" meidet Veränderungen allgemein, wo immer möglich. Der Mensch ist ein Gewohnheitstier. Klar, es gibt auch ein paar, die sofort auf alles Neue fliegen. Ich halte das aber nicht für erstrebenswert. Die Welt verändert sich schnell genug, da muss man nicht noch nachhelfen oder sofort mitgehen, sondern ruhig auch mal an Bewährtem festhalten. Es lohnt sich oft.

                                    Ja nichts anderes habe ich auch geschrieben, du beschreibst hier die Dokumentation für Entwickler, das hat nichts mit der Beschreibung der Änderungen im Code zu tun was durch Commits gemacht wird. Ich habe leider das Gefühl dass du mein verlinktes Beispiel eines Commits nicht einmal aufgerufen hast, und falls doch dann nicht verstanden hast.

                                    Dein "verlinktes Beispiel" waren ein paar Screenshots mit Codeausschnitten. So stark verkleinert, dass man eigentlich kaum noch etwas erkennen kann.

                                    Bei meinem früheren Arbeitgeber gab es fünf Softwareentwickler (ich gehörte nicht dazu), von denen hatte nur einer schon mal was von Versionskontrollsystemen gehört und wäre geneigt gewesen, eins zu benutzen. Den anderen hat man mit einer Präsentation eines Externen mal die Möglichkeiten aufgezeigt und grob erläutert, worum es da geht - und dann wollten sie es erst recht nicht mehr haben. Ich kann's verstehen ...
                                    Sie waren wohl schon älter und hatten auch angst etwas neues zu lernen?

                                    Die sind im Schnitt etwa 10..15 Jahre jünger als ich (damals also etwa 25..30) und dachten vermutlich, dass es für einen gesunden Menschen sehr lästig wäre, an Krücken zu gehen zu müssen. Ach ja, es war übrigens ausgerechnet der Älteste im Team (etwa 40), der ein VCS akzeptiert hätte.

                                    Ciao,
                                     Martin

                                    --
                                    Ein Ehepaar beim Sex. Sie fragt ihn: "Woran denkst du gerade?" - Er antwortet: "Kennste sowieso nicht."
                                    Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
                                    1. Versionierungssysteme gehören halt zum Grundwerkzeug eines Softwareentwicklers

                                      nein, sie sind *eine* mögliche Herangehensweise. Das zur Selbstverständlichkeit hochzustilisieren, ist mutig.

                                      Wer es einmal "gewagt" hat, mit einem Versionierungssystem _ernsthaft_ über einen gewissen Zeitraum zu arbeiten, wird es danach nicht mehr missen wollen.

                                      "Man" meidet Veränderungen allgemein, wo immer möglich. Der Mensch ist ein Gewohnheitstier. Klar, es gibt auch ein paar, die sofort auf alles Neue fliegen. Ich halte das aber nicht für erstrebenswert. Die Welt verändert sich schnell genug, da muss man nicht noch nachhelfen oder sofort mitgehen, sondern ruhig auch mal an Bewährtem festhalten. Es lohnt sich oft.

                                      Allgemeine Zustimmung. VCS aber sind kein Kiddie-Hype. Im Gegenteil bereits seit langem bewährt.

                                    2. Hallo,

                                      nein, sie sind *eine* mögliche Herangehensweise. Das zur Selbstverständlichkeit hochzustilisieren, ist mutig.

                                      Es ist nicht wirklich mutig einfach auf die Realität zu verweisen. Vielleicht hilft hier eine Parabel (also ein Gleichnis):

                                      Es gibt die Klimaskeptiker (entspricht dazu bei unserer Diskussion denen die gegen Versionierungssysteme argumentieren), wobei ich die Englische benennung "climate change denier" besser finde, und es gibt den breiten Konsens der Naturwissenschaftler, dass der Mensch für die Klimaveränderungen verantwortlich ist (die in unserer Diskussion den ganzen Professionellen Entwicklern entsprechen).

                                      Man könnte jetzt hingehen und sagen dass es mutig ist die Meinung der Klimaskeptiker als Blödsinn abzustempeln, aber das ist es nicht, denn von denen die sich mit dem Thema in professioneller Weise auskennen vertritt praktisch niemand die Meinung der Klimaskeptiker. Es ist also Mainstream zu denken dass das nur vereinzelte Spinner sind, man braucht keinen Mut um mit dem Mainstream mitzuschwimmen.

                                      Genauso ist es bei der Versionierung, der Mainstream nutzt es und findet es sinnvoll, die Anfänger können das noch nicht und ein paar unbelehrbare werden es nie lernen wollen.

                                      "Man" meidet Veränderungen allgemein, wo immer möglich.

                                      Nicht ganz, nur wenn das Kosten/Nutzen-Verhältniss nicht groß genug ist.

                                      Klar, es gibt auch ein paar, die sofort auf alles Neue fliegen.

                                      Öhm wie meinst du das jetzt im Zusammenhang zu Versionierungssystemen? Alexander hat doch aufgezeigt dass die ersten Versionierungssysteme schon über 40 Jahre alt sind. Also genauso alt wie C, was ich jetzt nicht mehr wirklich als Neue Sprache bezeichnen würde.

                                      Ich halte das aber nicht für erstrebenswert. Die Welt verändert sich schnell genug, da muss man nicht noch nachhelfen oder sofort mitgehen, sondern ruhig auch mal an Bewährtem festhalten.

                                      So lange es sich zum besseren verändert ist es natürlich erstrebenswert. Meiner Meinung nach hatten wir im Mittelalter lange genug Stillstand. Dazu fällt mir dieses Bild ein :D

                                      Es lohnt sich oft.

                                      Nicht in diesem Fall.

                                      Dein "verlinktes Beispiel" waren ein paar Screenshots mit Codeausschnitten. So stark verkleinert, dass man eigentlich kaum noch etwas erkennen kann.

                                      Ich habe überlegt wo ich den Link zum Orginal hintun sollte, über oder unter den Screenshot, habe mich für unter entschieden, das war wohl falsch. Hier noch mal ohne Screenshot: added Constants module. fixes #4

                                      Die sind im Schnitt etwa 10..15 Jahre jünger als ich (damals also etwa 25..30) und dachten vermutlich, dass es für einen gesunden Menschen sehr lästig wäre, an Krücken zu gehen zu müssen. Ach ja, es war übrigens ausgerechnet der Älteste im Team (etwa 40), der ein VCS akzeptiert hätte.

                                      Es ist faszinierend dass jemand in der Informatik arbeitet um jeden Preis versucht neue Sachen zu lernen. Gerade in einem Bereich wo täglich wichtige neue Erkenntnisse und Tools dazukommen, die es überhaupt erst ermöglichen dass sich die Branche so schnell weiterentwickeln kann.

                                      Jeena

                                      1. Hallo,

                                        Es ist faszinierend dass jemand in der Informatik arbeitet um jeden Preis versucht neue Sachen zu lernen.

                                        Hehe doofer Vertipper, es sollte heißen:

                                        Es ist faszinierend dass jemand in der Informatik arbeitet um jeden Preis vermeidet neue Sachen zu lernen.

                                        Jeena

                                      2. Hi,

                                        Genauso ist es bei der Versionierung, der Mainstream nutzt es und findet es sinnvoll, die Anfänger können das noch nicht und ein paar unbelehrbare werden es nie lernen wollen.

                                        eben, aber unter den Unbelehrbaren sind auch ein paar sehr erfolgreiche Professionelle, die zeigen, dass man ohne den Kram auch sehr gut auskommen kann.

                                        "Man" meidet Veränderungen allgemein, wo immer möglich.
                                        Nicht ganz, nur wenn das Kosten/Nutzen-Verhältniss nicht groß genug ist.

                                        Genau. Man meidet also Veränderungen, die keinen unmittelbaren Nutzen bringen. Und, sorry, den konnte ich bei all den Erläuterungen zu VCS hier immer noch nicht erkennen. Nur viel technischen Aufwand um der Technik willen.

                                        Ich halte das aber nicht für erstrebenswert. Die Welt verändert sich schnell genug, da muss man nicht noch nachhelfen oder sofort mitgehen, sondern ruhig auch mal an Bewährtem festhalten.
                                        So lange es sich zum besseren verändert ist es natürlich erstrebenswert. Meiner Meinung nach hatten wir im Mittelalter lange genug Stillstand. Dazu fällt mir dieses Bild ein :D

                                        Und was erkennen wir daraus? Dass schon die alten Römer ihre Entwicklung hätten bremsen sollen, weil danach der zu schnelle Fortschritt einfach zusammengebrochen ist. Wer weiß, ob uns das nicht in 10 oder 20 Jahren wieder bevorsteht.

                                        Dein "verlinktes Beispiel" waren ein paar Screenshots mit Codeausschnitten. So stark verkleinert, dass man eigentlich kaum noch etwas erkennen kann.
                                        Ich habe überlegt wo ich den Link zum Orginal hintun sollte, über oder unter den Screenshot, habe mich für unter entschieden, das war wohl falsch. Hier noch mal ohne Screenshot: added Constants module. fixes #4

                                        Toll. Daraus erkenne ich immer noch nichts, was mir nicht ein diff auch verraten hätte. Ja, da ist was geändert worden. Warum? Auf welcher Grundlage? Keine Angaben. Also kein Mehrwert.

                                        Es ist faszinierend dass jemand in der Informatik arbeitet um jeden Preis versucht neue Sachen zu lernen. Gerade in einem Bereich wo täglich wichtige neue Erkenntnisse und Tools dazukommen, die es überhaupt erst ermöglichen dass sich die Branche so schnell weiterentwickeln kann.

                                        Ich habe den Eindruck, dieser Absatz ist etwas verunglückt. Dennoch: Ja, gerade die IT-Branche ist ein Bereich, in dem man eigentlich mit allen Kräften bremsen sollte, weil die Entwicklung viiiel zu schnell abläuft.

                                        Ciao,
                                         Martin

                                        --
                                        Die letzten Worte des Polizisten:
                                        Ich hab mitgezählt, Leute: Sechs Schuss, jetzt hat er keine Munition mehr!
                                        Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
                                        1. Hallo,

                                          Und, sorry, den konnte ich bei all den Erläuterungen zu VCS hier immer noch nicht erkennen.

                                          Wenn mir das bisher immer noch nicht gelungen ist, dann tut es mir leid, ich habe es wirklich versucht aber muss jetzt wohl aufgeben die Diskussion bringt ja nichts mehr.

                                          Jeena

                                        2. Hello,

                                          So lange es sich zum besseren verändert ist es natürlich erstrebenswert. Meiner Meinung nach hatten wir im Mittelalter lange genug Stillstand. Dazu fällt mir dieses Bild ein :D

                                          Vielleicht hat es das "Mittelalter" auch gar nicht gegeben? :-D

                                          Und was erkennen wir daraus? Dass schon die alten Römer ihre Entwicklung hätten bremsen sollen, weil danach der zu schnelle Fortschritt einfach zusammengebrochen ist. Wer weiß, ob uns das nicht in 10 oder 20 Jahren wieder bevorsteht.

                                          Wir sind doch schon mitten im Zusammenbruch. Die Geldhanseln haben uns bis an die Grenze getrieben. Die Atomlobby macht auch einfach weiter, obwohl selbst im bisher atomhörigen Japan die meisten Menschen nun doch lieber Alternativen suchen wollen. Aber 97% der menschen dürfen nicht vernünftig handeln, weil 1% es nicht erlauben. Die 2% verdienen an jeder Entwicklung...

                                          Liebe Grüße aus dem schönen Oberharz

                                          Tom vom Berg

                                          --
                                           ☻_
                                          /▌
                                          / \ Nur selber lernen macht schlau
                                          http://bergpost.annerschbarrich.de
                                        3. Hi,

                                          added Constants module. fixes #4

                                          Toll. Daraus erkenne ich immer noch nichts, was mir nicht ein diff auch verraten hätte. Ja, da ist was geändert worden. Warum? Auf welcher Grundlage? Keine Angaben. Also kein Mehrwert.

                                          Steht doch drüber.
                                          "added Constants module. fixes #4"
                                          Sogar mit Link auf das Item aus dem Bugtracker. Wenn nun jemand die History des Projekts anschaut, dann sieht er eine Kurzbeschreibung der Änderung und eine Langbeschreibung (in diesem Fall hinter dem Link verborgen).

                                          Gerade bei Projekten mit mehreren Entwicklern ist da wichtig. Man will wissen, warum sich eine Zeile geändert hat/woher ein Bug kommt/.... Dann schaut man in die History der Datei und sieht (z.B): "Entwickler XYZ fixed bug 12345 by changing method getArghs".

                                          Bei deiner Methode
                                           - gibt es dieses Commit-Log gar nicht (das commit-log beschreibt die Änderungen und deren Gründe)
                                           - muss man erst aufwendig suchen, wann sich die Datei verändert hat, wenn du das entsprechende Verzeichnis nicht sowieso schon weggeworfen hast.

                                          Weiterhin hast du keine einfache Möglichkeit, branches anzulegen. Dies will man tun, um gewisse Dinge einfach mal auszuprobieren. Ich arbeite z.B. häufiger mal an mehreren Dingen gleichzeitig. Kurzfristige Bugfixes und langfristige Weiterentwicklung wäre ein einfaches Beispiel.

                                          Die Bugs fixe ich anhand des Codes, der derzeit auf Produktion läuft. In dem Code-Baum, in dem ich sie fixe, darf aber kein Code aus der Weiterentwicklung sein, damit nicht auf diesem Weg ungetestetes Zeugs auf Produktion landet.

                                          Natürlich kann man diesen letzten Anwendungsfall durch deine Lösung abdecken. Zwingt dich aber zu Tools wie diff/patch, welche deutlich unkomfortabler sind als git/svn.

                                          Als letztes: ich kann an der Hand abzählen, wann ich in Mehrpersonenprojekten nicht in "fremden" Codebäumen etwas geändert habe. Zusammenarbeit wird ohne Codeverwaltung deutlich (!) erschwert. Und von Hilfstools wie CI u.ä. will ich gar nicht erst reden.

                                          Bis die Tage,
                                          Matti

                                    3. Moin Moin!

                                      Versionierungssysteme gehören halt zum Grundwerkzeug eines Softwareentwicklers

                                      nein, sie sind *eine* mögliche Herangehensweise. Das zur Selbstverständlichkeit hochzustilisieren, ist mutig.

                                      Nein, es ist tatsächlich so. Wer mit ZIPs auf Fileservern und Workstations herumfrickelt, statt SVN, Git & Co zu benutzen, macht etwas grundsätzlich falsch. Ich habe mittlerweile einige Entwicklergruppen gesehen, und ein Muster ist ganz klar zu erkennen: Diejenigen, die SVN & Co einsetzen, haben halbwegs sauberen Code und produzieren durchschnittliche bis gute Software, diejenigen, die manuell kopieren, liefern unterdurchschnittliche bis gruselig schlechte Software. Es mag Ausnahmen geben, aber mir ist bislang keine Ausnahme untergekommen. Ganz im Gegenteil: Einer unserer "Zulieferer" treibt es noch wilder: Alle Entwickler frickeln mit irgendwelchen wilden Kopien in nicht definierten Zuständen herum, und ab und zu mailt man ein ZIP an den einen großen Guru, der das ZIP dann auspackt und ins CVS comitted - ohne Kommentar, und niemand außer dem Guru darf das CVS auch nur ansehen. Ich glaube, ich will gar nicht wissen oder nachvollziehen, wie man zu solchen Arbeitsabläufen kommt. Ich weiß aber, was für Schrott aus dem Laden kommt. Gruselig ist noch untertrieben. Eigentlich müßte man die Software in Stahlfässer einschweißen, mit Beton ummanteln und sehr, sehr tief vergraben.

                                      "Man" meidet Veränderungen allgemein, wo immer möglich. Der Mensch ist ein Gewohnheitstier. Klar, es gibt auch ein paar, die sofort auf alles Neue fliegen. Ich halte das aber nicht für erstrebenswert. Die Welt verändert sich schnell genug, da muss man nicht noch nachhelfen oder sofort mitgehen, sondern ruhig auch mal an Bewährtem festhalten. Es lohnt sich oft.

                                      So weit, so gut. CVS und SVN sind bewährt, wenn Du SVN einsetzt, bist Du definitiv kein Early Adopter mehr, der riskiert, viel Geld oder Arbeit für unfertigen Schrott auszugeben und gelegentlich auch mal Daten zu verlieren. Für Git dürfte ähnliches gelten.

                                      Die sind im Schnitt etwa 10..15 Jahre jünger als ich (damals also etwa 25..30) und dachten vermutlich, dass es für einen gesunden Menschen sehr lästig wäre, an Krücken zu gehen zu müssen. Ach ja, es war übrigens ausgerechnet der Älteste im Team (etwa 40), der ein VCS akzeptiert hätte.

                                      Ein guter Entwickler ist sich zu schade, Routinejobs von Hand zu erledigen. Die kann der Computer schneller und zuverlässiger automatisch erledigen. Wer sich zu schade ist, Werkzeuge zu benutzen, hat seinen Job nicht verstanden.

                                      Das ist eines der Lehren, die ich aus dem Zivildienst mitgenommen habe. Man kann drei Litzen freihändig miteinander verlöten, wenn man einigermaßen geschickte Finger hat. Es geht aber viel einfacher, schneller, sauberer und schmerzfreier, wenn man die Litzen in eine Haltevorrichtung für 5 DM Materialaufwand einklemmt. Und es bricht einem dabei kein Zacken aus der Krone, auch wenn die Vorrichtung eigentlich für einen körperlich sehr eingeschränkten Kollegen gebaut wurde.

                                      Und ein guter Entwickler erkennt auch, wann er ein Werkzeug braucht, und wenn er kein fertiges findet, baut er sich eines. In den letzten 10 Wochen, seit dem ich an einem neuen Projekt in einer neuen Umgebung arbeite, ist meine Software-Werkzeugkiste um etwa 10 neue Werkzeuge angewachsen, die in der Umgebung bislang schlicht fehlten.

                                      Was SVN angeht, bin ich mittlerweile skrupellos. Ich hab bei meinen letzten drei Arbeitgebern SVN eingeführt, stumpf auf irgendwelchen alten Maschinen, die ich mit Linux wieder flott gemacht habe. Und ich habe gnadenlos alles, was zu meiner Arbeit gehört, ins SVN eingepflegt und dort bearbeitet. Zusammen mit TortoiseSVN und SVN::Web konnte jeder, einschließlich Vorgesetzten, nach ein paar Tagen die Vorteile sehen, und nach ein paar weiteren Tagen habe ich bei jeder Änderung provokant gefragt, wo im SVN die Kollegen ihre Änderung eingecheckt haben.

                                      SVN kann man in 30 Minuten soweit erklären, dass JEDER damit arbeiten kann. Viel mehr als checkout, update, commit, und revert braucht man im Alltag nicht, den Rest hab ich zwar irgendwo im Hinterkopf, lese ich aber auch immer wieder nach. Das kostenlose SVN-Buch liegt deswegen immer griffbereit auf dem Webserver des Entwicklungsservers.

                                      Genauso installiere ich immer Bugzilla auf dem Server, und Bug 1 lautet immer "Was nicht im Bugzilla steht, ist kein Fehler".

                                      Alexander

                                      --
                                      Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".
                                      1. Moin Alexander,

                                        absolut und uneingeschränkt ACK.

                                        LG,
                                         CK

                                      2. Hi,

                                        Versionierungssysteme gehören halt zum Grundwerkzeug eines Softwareentwicklers
                                        nein, sie sind *eine* mögliche Herangehensweise. Das zur Selbstverständlichkeit hochzustilisieren, ist mutig.
                                        Nein, es ist tatsächlich so. Wer mit ZIPs auf Fileservern und Workstations herumfrickelt, statt SVN, Git & Co zu benutzen, macht etwas grundsätzlich falsch.

                                        okay, Standpunkt begriffen und akzeptiert. Ich teile diese Ansicht dennoch nicht.

                                        Ein guter Entwickler ist sich zu schade, Routinejobs von Hand zu erledigen.

                                        Ein guter Entwickler ist sich auch zu schade, einfach irgendwas zu nutzen, was gerade "hip" ist, ohne davon einen Nutzen zu haben. Lieber drei Anweisungen an der Kommandozeile, als ein Fremdtool zu verwenden, das einen zwingt, die eigene Arbeitsweise zu ändern.
                                        Nicht der Entwickler sollte sich den Tools anpassen, sondern die Tools sollten zur Arbeitsweise des Entwicklers passen, oder sich notfalls daran anpassen lassen. Idealerweise programmiert man sie selbst.

                                        Nein, ich halte wirklich nichts von Tools, die mir das Denken abnehmen wollen. Ich programmiere auch keine Telefonnummern ein, sondern wähle sie aus dem Gedächtnis. Ich benutze auch keinen Terminkalender, denn wer seine Termine nicht mehr im Kopf überblicken kann, hat zu viele. Ich schreibe auch keine Einkaufszettel, sondern ärgere mich gelegentlich, dass ich doch etwas vergessen habe. Das trainiert aber.

                                        Wer sich zu schade ist, Werkzeuge zu benutzen, hat seinen Job nicht verstanden.

                                        Der Job des Entwicklers ist, ein Ergebnis zu liefern. Wie er das macht, ist seine Sache. Die Zusammenarbeit vieler Entwickler an einem Projekt ist normalerweise etwas, was es zu vermeiden gilt, ist aber bei sehr großen Projekten wohl ein notwendiges Übel. Und *dann* muss man eventuell auch Zugeständnisse bei der Arbeitsweise machen. Das halte ich aber für einen Sonderfall.

                                        Und ein guter Entwickler erkennt auch, wann er ein Werkzeug braucht, und wenn er kein fertiges findet, baut er sich eines.

                                        Eben. Und wenn er feststellt, dass er keins braucht, weil er mit dem vorhandenen Angebot gut auskommt, auch gut.

                                        Genauso installiere ich immer Bugzilla auf dem Server

                                        Toll. Noch 'ne Krücke.

                                        Ciao,
                                         Martin

                                        --
                                        I do take my work seriously, and the way to do that is not to take yourself too seriously.
                                          (Alan Rickman, britischer Schauspieler)
                                        Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
                                        1. Moin Moin!

                                          Ein guter Entwickler ist sich zu schade, Routinejobs von Hand zu erledigen.

                                          Ein guter Entwickler ist sich auch zu schade, einfach irgendwas zu nutzen, was gerade "hip" ist, ohne davon einen Nutzen zu haben.

                                          Richtig.

                                          Lieber drei Anweisungen an der Kommandozeile, als ein Fremdtool zu verwenden, das einen zwingt, die eigene Arbeitsweise zu ändern.

                                          Ah, das Not Invented Here Syndrome. Das erklärt einiges.

                                          Nicht der Entwickler sollte sich den Tools anpassen, sondern die Tools sollten zur Arbeitsweise des Entwicklers passen, oder sich notfalls daran anpassen lassen.

                                          Richtig, bis zu einem gewissen Punkt.

                                          Idealerweise programmiert man sie selbst.

                                          NIHS, definitiv.

                                          Man sollte wissen, was es an Werkzeugen gibt, was welches Werkzeug kann und was nicht. Und nur dann, wenn kein fertiges Werkzeug für das Problem geeignet ist, baut man sich eines selbst.

                                          Nein, ich halte wirklich nichts von Tools, die mir das Denken abnehmen wollen.

                                          SVN, Git & Co. sind beim "Denken abnehmen" extrem schlecht. SVN, Git & Co. sorgen für eine strukturierte Ablage von altem und aktuellem Code, nicht mehr und nicht weniger.

                                          Ich programmiere auch keine Telefonnummern ein, sondern wähle sie aus dem Gedächtnis. Ich benutze auch keinen Terminkalender, denn wer seine Termine nicht mehr im Kopf überblicken kann, hat zu viele. Ich schreibe auch keine Einkaufszettel, sondern ärgere mich gelegentlich, dass ich doch etwas vergessen habe. Das trainiert aber.

                                          Und ich entwickle Software, bei der ein durchgerutschter Fehler dafür sorgen kann, das Menschen sterben, und in Folge dessen minimal mein Vorgesetzter und der Geschäftsführer die nächsten Jahre hinter Gitter kommen. "Hups, hab vergessen, Wurst einzukaufen" und "Hups, verwählt" geht da schlicht nicht.

                                          Wer sich zu schade ist, Werkzeuge zu benutzen, hat seinen Job nicht verstanden.

                                          Der Job des Entwicklers ist, ein Ergebnis zu liefern. Wie er das macht, ist seine Sache. Die Zusammenarbeit vieler Entwickler an einem Projekt ist normalerweise etwas, was es zu vermeiden gilt, ist aber bei sehr großen Projekten wohl ein notwendiges Übel. Und *dann* muss man eventuell auch Zugeständnisse bei der Arbeitsweise machen. Das halte ich aber für einen Sonderfall.

                                          Willkommen in der Realität.

                                          Genauso installiere ich immer Bugzilla auf dem Server

                                          Toll. Noch 'ne Krücke.

                                          Dir ist wirklich nicht zu helfen.

                                          Ja, Bugzilla ist nicht der Heilsbringer, und unter der Haube sieht Bugzilla einfach gräßlich aus. Aber als Black Box für Issue-Tracking funktioniert Bugzilla einfach deutlich besser als Excel-Listen, Word-Dokumente, Mails, lose Zettel, Pinwände, Aktenstapel und Aussitzen-bis-es-ein-Donnerwetter-gibt.

                                          Alexander

                                          --
                                          Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".
                                          1. hi,

                                            NIHS, definitiv.

                                            http://de.wikipedia.org/wiki/Not-invented-here-Syndrom

                                            ... kannte ich noch garnicht bzw. kenne ich schon, aber nicht den begriff bzw. dass es sogar einen wikipediaartikel dazu gibt ...;

                                            mfg

                                            tami

                                          2. [latex]Mae  govannen![/latex]

                                            NIHS, definitiv.

                                            Du solltest also deine Energie besser in aussichtsreichere Unterfangen stecken als den Versuch, Martin zu überzeugen; beispielsweise den Vereinigten Staaten erklären, daß ihnen keiner was böses will oder den Papst, daß Frauen in hohe Kirchenämter gehören ^^

                                            Stur lächeln und winken, Männer!
                                            Kai

                                            --
                                            It all began when I went on a tour, hoping to find some furniture
                                             Followed a sign saying "Beautiful Chest", led to a lady who showed me her best)
                                            SelfHTML-Forum-Stylesheet
                                            1. Moin Moin!

                                              NIHS, definitiv.

                                              Du solltest also deine Energie besser in aussichtsreichere Unterfangen stecken als den Versuch, Martin zu überzeugen; beispielsweise den Vereinigten Staaten erklären, daß ihnen keiner was böses will oder den Papst, daß Frauen in hohe Kirchenämter gehören ^^

                                              Hmmm, Anfang nächster Woche ist mein vor 8 Wochen angefangenes 12-Monate-Projekt fertig. Dann bleibt noch genügend Zeit, bis Ende nächster Woche für  Weltfrieden und eine knackig-junge, schwarze Lesbe als Päpstin zu sorgen. Überhaupt kein Problem.

                                              Alexander

                                              --
                                              Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".
                                              1. Moin Moin!

                                                NIHS, definitiv.

                                                Du solltest also deine Energie besser in aussichtsreichere Unterfangen stecken als den Versuch, Martin zu überzeugen; beispielsweise den Vereinigten Staaten erklären, daß ihnen keiner was böses will oder den Papst, daß Frauen in hohe Kirchenämter gehören ^^

                                                Hmmm, Anfang nächster Woche ist mein vor 8 Wochen angefangenes 12-Monate-Projekt fertig. Dann bleibt noch genügend Zeit, bis Ende nächster Woche für  Weltfrieden und eine knackig-junge, schwarze Lesbe als Päpstin zu sorgen. Überhaupt kein Problem.

                                                Wieso werd' ich den Eindruck nicht los, dass mein Chef sein Reality Distortion Field gerade mal kurz voll aufgedreht hat? Das erklärt auch die Stromschwankungen in der Gegend ...

                                                Alexander

                                                --
                                                Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".
                                                1. hi,

                                                  Wieso werd' ich den Eindruck nicht los, dass mein Chef sein Reality Distortion Field gerade mal kurz voll aufgedreht hat? Das erklärt auch die Stromschwankungen in der Gegend ...

                                                  Komm doch am 27.10. nach Dortmund ;-) http://www.doodle.com/fbhsnx9vrkiifqre

                                                  mfg

                                                  tami

                                          3. Hallo,

                                            Lieber drei Anweisungen an der Kommandozeile, als ein Fremdtool zu verwenden, das einen zwingt, die eigene Arbeitsweise zu ändern.
                                            Ah, das Not Invented Here Syndrome. Das erklärt einiges.

                                            den Begriff kannte ich noch nicht, trifft die Sache aber recht gut. Und ja, ich halte es für etwas Gutes. Tatsächlich meide ich den Einsatz von Fertiglösungen, wenn ich das zugrundeliegende Problem auch mit vertretbarem Aufwand selbst lösen kann. Und das nicht nur in der IT, sondern auch in anderen Lebensbereichen. Wochenlang durch Möbelhäuser dackeln und suchen, und an jedem Stück ist irgendwas, was mir nicht passt? Do it yourself.
                                            Erst wenn ich feststelle, dass Selbermachen wesentlich teurer wird, unverhältnismäßig lange dauern wird oder einfach meine Fähigkeiten übersteigt, gehe ich den Kompromiss ein (denn das ist es dann immer!), etwas Fertiges zu verwenden, was meinen Vorstellungen ungefähr entspricht.

                                            Idealerweise programmiert man sie selbst.
                                            NIHS, definitiv.

                                            Ja. :-)

                                            Ich programmiere auch keine Telefonnummern ein, sondern wähle sie aus dem Gedächtnis. Ich benutze auch keinen Terminkalender, denn wer seine Termine nicht mehr im Kopf überblicken kann, hat zu viele. Ich schreibe auch keine Einkaufszettel, sondern ärgere mich gelegentlich, dass ich doch etwas vergessen habe. Das trainiert aber.
                                            Und ich entwickle Software, bei der ein durchgerutschter Fehler dafür sorgen kann, das Menschen sterben, ...

                                            Sowas gibt's natürlich auch, und da sind entsprechend wirksame Maßnahmen zur Fehlererkennung und -vermeidung erforderlich. Wenn man Mitarbeiter aber dazu drängt, ihre gewohnte Arbeitsweise umzustellen, vermeidet man Fehler nicht, sondern begünstigt sie sogar noch - zumindest in einer Anfangsphase. Man muss die Mitarbeiter also so auswählen, dass deren Ansichten und Gewohnheiten zum Konzept passen.

                                            Genauso installiere ich immer Bugzilla auf dem Server
                                            Toll. Noch 'ne Krücke.
                                            Dir ist wirklich nicht zu helfen.

                                            Natürlich nicht. Wobei auch? Ich bin ja genau da, wo ich hin will.

                                            Ciao,
                                             Martin

                                            --
                                            Letztlich basiert alles auf dem Feuer, dem Rad, der Eins und der Null.
                                              (Gernot Back)
                                            Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
                    3. Hi,

                      Nun habe ich mich doch auf eine Diskussion eingelassen, aber was soll's kann sich ja vielleicht doch noch interessant entwickeln.

                      vielleicht entdecke ich ja im Zuge dieser Diskussion endlich mal, was an so einer Versionsverwaltung so toll ist. Ich mein, wenn man als großes Team an einem Projekt arbeitet, ohne dass es eine klare Zuordnung der einzelnen Module zu einem Bearbeiter gibt, mag das Sinn machen. Aber dann hat man IMO schon in der Planung was falsch gemacht.

                      Der Normalfall dürfte doch sein, dass jeder Entwickler seinen abgegrenzten Teilbereich des Projekts mit klar definierten Schnittstellen bearbeitet, in den ihm kein anderer reinzupfuschen hat. Und dieser ihm zugewiesene Teilbereich ist dann wieder genauso zu sehen, als ob er allein irgendein Mini-Projekt bearbeitet. Das heißt, er hält stabile Versionen, Testversionen und wilde Experimente in verschiedenen Verzeichnissen vor und stellt seinen Kollegen jeweils das zur Verfügung, was er im Moment für "final" oder "ausgereift" hält (und behält die Testversionen unter Verschluss).

                      Ganz ehrlich, ich habe den Sinn eines Versionskontrollsystems bisher noch nicht verstanden. Wenn ich eine Version als "Milestone" konservieren will, dann archiviere ich den aktuellen Zwischenstand, und fertig. Das ist eine simple Kopieraktion (meinetwegen zusätzlich eine Komprimierung).

                      So long,
                      Martin

                      Kennst du Beyond Compare?

                  2. Wie lange dauert denn das Migieren von 20 mittelgrossen und 5 grossen Projekte von SVN nach Git? Wenn es unter 2 Stunden geht, lass ich mich evtl. dazu überreden.
                    Da meine Hook-Scripts eh nur spezifische Shell-Scriptsaufrufen, ist deren Migration kein Problem.

                    1. Moin Multi,

                      Wie lange dauert denn das Migieren von 20 mittelgrossen und 5 grossen Projekte von SVN nach Git?

                      Das hängt von der Definition von „gross“ ab. Und davon, ob auf das Repository auch lokal zugegriffen werden kann. Im Allgemeinen solltest du mit <2h problemlos hinkommen, das konvertieren des CForum-Repos hat nur ein paar Minuten gedauert. Wenn du aber nur über SSH oder WebDAV auf die Repos zugreifen kannst, dauert das ganze schon länger.

                      Wenn es unter 2 Stunden geht, lass ich mich evtl. dazu überreden.

                      Ich würde mich nicht „überreden lassen.“

                      Probiere git erstmal aus bei einem neuen Projekt, alternativ kannst du ja git-svn benutzen. Hier benutzt du zwar git als Frontend und hast auch die Vorzüge (Offline-Commits, eine Kopie des Repos lokal, etc, pp), aber das Backend ist immer noch Subversion.

                      LG,
                       CK

                      1. Das hängt von der Definition von „gross“ ab. Und davon, ob auf das Repository auch lokal zugegriffen werden kann.

                        Server steht hier im Büro, also lokal verfügbar. Projekte zwischen 2500 und 20000 Dateien, ca. 5MB bis 500MB.

                        Probiere git erstmal aus bei einem neuen Projekt, alternativ kannst du ja git-svn benutzen.

                        Neues Projekt steht aktuell keines an. Da fast alle neuen Sachen als Modul auf meinem Framework aufbauen, geht das nicht ohne Konvertieren, da ich das Grundsystem und das Modul nichtu nter verschienen Versionskontrollen laufen lassen will.

                        git-svn schau ich mir nochmal an. Hab ich damals wegen Zeitmangel nur überflogen aber nie probiert.

            2. Moin Moin!

              Und wo wir schon mal bei Versionsverwaltung sind: Welches System lässt denn genügend Raum für die Gedanken, die zu Versionsänderungen geführt haben. Begründungen gehören immer zum Projekt, aber nicht unbedingt als Kommentar in den Quelltext.

              Commit-Kommentare.

              Außerdem hab ich meine Dokumentation auch im SVN, typischerweise als POD, HTML oder Plain Text, dort kann ich auch Planänderungen dokumentieren.

              Alexander

              --
              Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".
          2. Moin Moin!

            Versionsverwaltung: Subversion, TortoiseSVN
            Oh Gott,

            Nicht so förmlich. Alexander reicht.

            wäre es nicht langsam höchste Zeit mal auf Git oder Mercurial umzusteigen?

            Wozu? ich brauche kein verteiltes System, ich habe sowohl privat als auch beruflich immer einen zentralen Server mit zuverlässiger Backup-Lösung.

            Alexander

            --
            Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".
      6. Hallo,

        Welche Werkzeuge benutzt Ihr überhaupt?

        Da will ich auch mal antworten:

        Editor: Eclipse mit Aptana
        Browser: Firefox mit Web Developer und Firebug
        Graphik: Photoshop (und Illustrator)
        DB-Admin.: MySQL Administrator, Workbench, Migration Toolkit, SQL Yog
        FTP: Eclipse-Plugin oder FileZilla

        Bin damit zufrieden - funktioniert für meine Bedürfnisse sehr gut. Nur der Workflow beim DB-Entwurf funktioniert noch nicht so reibungslos ...

        Ich richte mir übrigens für jedes Projekt einen vHost mit der selben Domain wie das live-Projekt und "test" als TLD ein. Das finde ich sehr praktisch.

        Gruß,
        luti

      7. Hi there,

        Welche Werkzeuge benutzt Ihr überhaupt?

        kommt drauf an[tm]. ;-)

        * Konsole, Nautilus (Linux)
         * Konsole, Explorer (Windows)
         * Bluefish (Linux)
         * PNP2 (Windows)
         * Opera mit Dragonfly (wobei Dragonfly leider oft nicht funktioniert[1])
         * Firefox mit Firebug und LiveHTTP
         * Code::Blocks (Linux), mit mingw32-Toolchain auch als Cross-Compiler für Windows
         * devcpp (Windows)
         * Apache, PHP
         * Wireshark (gewöhnlich Linux)
         * Micrografx Pictire Publisher (Windows)

        Für die Grafikbearbeitung habe ich inzwischen glücklicherweise wieder meinen geliebten Micrografx Picturepublisher. Aber alles kann man damit auch nicht machen.

        Natürlich nicht - zum Zubereiten von Wurstsalat ist er nicht geeignet. Aber wenn es um die Bearbeitung (oder Erstellung) von Bitmap-Grafiken geht, hat er mir bisher immer gute Dienste geleistet. Wenn es um eine rein formal-algorithmische Bildbearbeitung geht, schreib ich mir auch gern mal schnell ein PHP-Script, das die Transformation dann mit der gd-lib macht.

        Ciao,
         Martin

        [1] Wenn ich es versuche, kriege ich in schätzungsweise 99 von 100 Fällen nur die Meldung "This window has no runtime" im Dragonfly-Fenster.

        --
        F: Kennt jemand ein Automobil-Märchen?
        A: Radkäppchen und der böse Golf.
        Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
      8. gudn tach!

        Welche Werkzeuge benutzt Ihr überhaupt?

        unter linux und windows dasselbe:
        * gvim als texteditor bzw. eigentlich ist er auch als ein IDE zu gebrauchen.
        * perl fuer hexenwerk

        ach so, fuer mysql-gedoens (nur unter linux) verwende ich "emma".

        prost
        seth

  2. Hallo Dom,

    DW ist schon ein mächtiges Tool und vermutlich kann es auch viel mehr als du denkst. Aber wie bei jedem Tool ist es so, dass man sich erst intensiv damit auseinander setzen muss um zu verstehen wie es funktioniert und dann muss einem diese Funktionalität auch noch gefallen.

    Ich nutze DW seit Jahren gerne und möchte es nicht mehr missen. Wenn es nur um HTML, CSS und JS geht, gibt es für mich kein besseres Tool. Ich habe auch andere probiert, wie z.B. Eclipse, aber da gefiel mir zum Beispiel der komplette Ansatz nicht.

    Die Designansicht nutze ich zum Beispiel nie. Aber Tools wie  Projektverwaltung, Codevervollständigung, -validierung, Styleverwaltung, Datenbanken, Livecode und und und will ich einfach nicht mehr missen und habe ich so (mein Geschmack, mein Ansatz, mein persönliches Verständnis von Arbeitsprozessen) noch bei keinem anderen Tool gefunden.

    Außerdem lässt es sich durch diverse Erweiterungen erweitern.

    Auch im Zusammenspiel mit serverseitigen Sprachen ist DW stark, wenn es auch nicht seine Paradedisziplin ist (abgesehen von ColdFusion vielleicht) und andere Tools da besser, weil meist spezialisierter sind, ich habe noch nie etwas vermisst.

    Ob DW ein vollwertiges hängt immer von der Definition und den eigenen Ansprüchen ab ... für mich ist es das, da es alles bietet was ich zum Entwickeln brauche.

    Gruß
    Ole