Re: Installation von SVN
Hi, On Tuesday 07 September 2010, Heiko Schlittermann wrote: Ich würde Git oder HG (Mercurial) probieren. um mal eine Gegenmeinung zur allgemeinen Git-Begeisterung beizusteuern: Git ist ein dezentrales System. Die Arbeitsweise ist hier anders - man entwickelt auf seinem lokalen Repository, welches zufälligerweise im Working Directory versteckt ist. Sprich: auf jedem Rechner wo eine Kopie der Sourcen liegt sieht man ein anderes Repository und es gehört einige Disziplin dazu diese (mit einem zentralen Repo) synchron zu halten. Bei größeren Teams ist die Unterscheidung noch größer: während bei SVN alle commits sofort für jeden sichtbar sind, sind bei Git i.d.R. drei Schritte nötig: 1) man committet, 2) der Commit muss in Richtung zentrales Repo gepusht werden und 3) der zentral Verantwortliche muss den Patch annehmen (es sei denn jeder hat zentral vollen Zugriff, dann sind es zwei Schritte). Da die meisten unter uns Freigeister sind ist diese Arbeitsweise oft bevorzugt. In Firmenumgebungen hat sie meiner Meinung nach aber den Nachteil dass alle wirklich mitspielen wollen müssen und die Konzepte wesentlich komplexer sind. Ein vollständiger Commit sind auch 2-3 Schritte statt einem, was dazu führt dass es einfacher ist einen zu vergessen. Was auch ein Faktor sein kann: dezentrale Systeme haben keine eindeutigen und stetig steigenden Versionsnummern, was unter Umständen per Policy gebraucht wird. Was man wählt hängt letztlich davon ab welche Arbeitsweise man bevorzugt und wieviel Komplexität man seinen Mitspielern zumuten will. Versionskontrolle ist an sich schon heftig, mit dezentralen Systemen ist es noch heftiger. Dass es noch keinen eindeutigen Favoriten unter den Systemen gibt macht die Auswahl nicht leichter. Konrad signature.asc Description: This is a digitally signed message part. ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: Installation von SVN
Hi Konrad, Am 07.09.2010 09:55, schrieb Konrad Rosenbaum: Bei größeren Teams ist die Unterscheidung noch größer: während bei SVN alle commits sofort für jeden sichtbar sind, die Annahme gilt natürlich nicht mehr, wenn man wie ich immer 'git svn' benutzt. :) Viele Grüße, Torsten ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: AW: Alternative zu »tar« oder Hinweis zu Option
Hallo Grimnin! wenn gnu tar zu langsam könnte man star mal testen vielleicht hat tar auch Probleme mit links Vielen Dank für den Hinweis! Ich werde diesem mal nachgehen. Links gibt es in der gesamten Verzeichnisstruktur keine. man könnte versuchen in Echtzeit mit dnotify eine Liste erstellen oder gleich den Archiv hinzufügen dnotify halte ich für eine interessante Idee. Die online-Archivierung hatten wir kürzlich aufgrund von Fehlern (sehr aufwändig) abschalten müssen. LZOlayer-FS flog uns regelmäßig um die Ohren, falls das jemandem etwas sagt. Seit dieser negativen Erfahrung wollten wir auf eine solche Schicht verzichten. Grüße Björn smime.p7s Description: S/MIME Cryptographic Signature ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: Installation von SVN
Am Dienstag, 7. September 2010, 09:55:50 schrieb Konrad Rosenbaum: Hi, On Tuesday 07 September 2010, Heiko Schlittermann wrote: Ich würde Git oder HG (Mercurial) probieren. um mal eine Gegenmeinung zur allgemeinen Git-Begeisterung beizusteuern: Git ist ein dezentrales System. Die Arbeitsweise ist hier anders - man entwickelt auf seinem lokalen Repository, welches zufälligerweise im Working Directory versteckt ist. Sprich: auf jedem Rechner wo eine Kopie der Sourcen liegt sieht man ein anderes Repository und es gehört einige Disziplin dazu diese (mit einem zentralen Repo) synchron zu halten. ... Konrad Absolut zutreffend. Deswegen bin ich in normalen Firmen dafür SVN zu nutzen. ( Aber das bitte als Frontend für ein git Respository.) Einmal die git-Luft geschnuppert und mehr oder weniger verstanden: Da gibt's für mich kein zurück mehr. Es gibt für mich außerdem bei git ganz entscheidende Pluspunkte: 1.) serverside moves werden als mv übertragen. (Ich bin Modemnutzer. Mach damit mal bei KDE ein svn update, wenn sie die Icons wieder mal in ein anders Verzeichnis verschoben haben!) 2.) Bei SVN ist es schwer bis unmöglich eine History lokal (und disconnected!) zu haben. (git blame geht disconnected, svn blame nicht) 3.) Diese Freiheit mit branches, tags, rebase ... 4.) Das Feature konsistent durch Design wird für mich immer wichtiger, da in letzter Zeit mein Vertrauen in die Zuverlässigkeit von Speichermedien abnimmt. Und wichtig für Normalbenutzer: die Brücke von und zu SVN ist sehr gut ausgebaut! Bernhard (HG/Monotone/Bazaar habe ich nie probiert vielleicht wäre meine Meinung darüber ähnlich.) ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Morgen Kinder ...
... wird's was geben. Das ist klar, aber wo? GAG18? Ich würde mich bei Erfahrungsträgern gerne mal für eine kurze guided tour zu wine anmelden. Gibt es einen Freiwilligen? TIA! Bernhard ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: Installation von SVN
Hallo! Ich sehe bei SVN den größten Vorteil darin, dass jeder User die Logik mit dem großen allmächtigen Server und den kleinen Clients versteht. Bei GIT ist jeder technisch gleich, logisch gibt es aber nach wie vor den Master und die Untertanen. Da entsteht eine unnötige Diskrepanz zwischen Programmbedienung und gefühlter Logik. Für mich ist wichtig, dass Repositories auch teilweise ausgecheckt werden können. Das geht mit SVN sehr gut. Wenn z.B. die Buchhaltung nur die Buchführung, aber nicht die 10 GB Rechnungen braucht, holt es sich auch nur diesen Teil. Gegen GIT spricht als KO-Kriterium die schlechte Verfügbarkeit an Oberflächen. Damit kann ich GIT nicht im Unternehmen etablieren. @Bernhard: Mich stört auch, dass ein mv auf Dateisytemebene nicht funktioniert, sondern im SVN-Client gemacht werden muss. Würde man es einfach im Dateisystem machen, wäre das für SVN ein Delete und Add. Ich denke aber, ein intelligenter Client könnte auf den Trichter kommen, dass nur verschoben wurde, und das dem Server mitteilen. Dafür sind die SVN-Clients momentan noch zu blöd. Warum ist GIT konsistent by design? Kann mir das bitte jemand erklären? Viele Grüße! Thomas ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: Installation von SVN
Am Dienstag, 7. September 2010, 14:07:01 schrieb Thomas Schmidt: Hallo! Ich sehe bei SVN den größten Vorteil darin, dass jeder User die Logik mit dem großen allmächtigen Server und den kleinen Clients versteht. Bei GIT ist jeder technisch gleich, logisch gibt es aber nach wie vor den Master und die Untertanen. Da entsteht eine unnötige Diskrepanz zwischen Programmbedienung und gefühlter Logik. Selbst Gefühle können sich ändern. Für mich ist wichtig, dass Repositories auch teilweise ausgechekt werden können. Das geht mit SVN sehr gut. Wenn z.B. die Buchhaltung nur die Buchführung, aber nicht die 10 GB Rechnungen braucht, holt es sich auch nur diesen Teil. Guter Punkt! Gegen GIT spricht als KO-Kriterium die schlechte Verfügbarkeit an Oberflächen. Damit kann ich GIT nicht im Unternehmen etablieren. Ich habe leider Tortoise-Git selbst nicht angefaßt, denke aber, daß es _durchaus_ verwendbar ist. @Bernhard: Mich stört auch, dass ein mv auf Dateisytemebene nicht funktioniert, sondern im SVN-Client gemacht werden muss. Würde man es einfach im Dateisystem machen, wäre das für SVN ein Delete und Add. Ja. Du schilderst die Client Seite. Ich meinte die Server-Seite. Von dort kommt nämlich bei svn update delete add an (statt mv). Und das kostet Bandbreite. Ich denke aber, ein intelligenter Client könnte auf den Trichter kommen, dass nur verschoben wurde, und das dem Server mitteilen. Dafür sind die SVN-Clients momentan noch zu blöd. Warum ist GIT konsistent by design? Kann mir das bitte jemand erklären? Ganz grob: Jeder Eintrag hat seinen Typ, eine sha1-Checksumme des Inhalts und den Verweis auf einen Vorgänger, der widerum seine eigne sha1-Ckecksumme hat. An jeder Stelle im Geäst des Versionsbaumes ist sozusagen ein inhaltsadressierter Weg zurück zur Wurzel möglich. Und das wird von git intern und oft genug überprüft! Nachträgliche Manipulationen werden sofort bemerkt (auch wenn es nur HD- Lesefehler sein sollten!) Du kannst als ersten Commit ja eine von Dir (gpg-) signierte Textdatei nehmen. Damit hättest Du jeden späteren Inhalt (besser den Weg dahin) digital signiert und jeder könnte das nachprüfen (und tut's auch unbemerkt) ! Versuch das mal woanders! Der Hardcore-Link dazu (von git-scm.com) http://eagain.net/articles/git-for-computer-scientists/ Ja, damit kann man sogar solche Sachen wie revisionssichere E-Mail- Archivierung angehen. a la: sha1sum Maildatei | git commit -a -m`Mail-Eingang Damit hätte man Reihenfolge (sogar Zeit, weil im Namen der Maildatei) und Inhaltshash gut gesichert. Später könnte man eine E-Mail an einen RA schreiben: Bitte senden Sie diese Mail qualifiziert signiert an mich zurück: 2007 sha1 des letzten git commits 2008 sha1 des letzten git commits 2009 sha1 des letzten git commits mfG. Bernhard Und bei Empfang hättest Du einen ganzen Zeitraum (hier ein Jahr) versiegelt. Durch die Angabe der alten Summen ist noch nicht mal nötig, das der Key des RA von z.B. 2007 (immer noch) überprüfbar ist. Da kein Mail-Inhalt selbst unter git verwaltet wird, könntest Du eine Mail sogar löschen (Stichwort wg. Datenschutz -private Mail), jeder würde sehen können das da was fehlt und der Rest wäre trotzdem revisionssicher | nicht betroffen. (Rechtlich gefordert muß man Geschäftsbriefe aufbewahren. Was von der E-Mail darunter fällt, ist letztlich Entscheidung des Geschäftsführers. Die Idee, einfach alles aufzubewahren, ist sehr verkürzt.) Dumm bloß, daß der Gesetzgeber von Technik keine Ahnung hat ... Viele Grüße! Thomas Bernhard ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: Morgen Kinder ...
Hallo Bernhard, On Tue, Sep 07, 2010 at 10:57:59 +0200, Bernhard Schiffner wrote: ... wird's was geben. Das ist klar, aber wo? GAG18? Ich gehe vom GAG18 aus und werde dort sein. Gruss, Chris -- Christian Perlechris AT linuxinfotag.de 010111 http://chris.silmor.de/ 101010 LinuxGuitarKitesBicyclesBeerPizzaRaytracing ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: Morgen Kinder ...
Am 07.09.2010 16:02, schrieb Christian Perle: Hallo Bernhard, On Tue, Sep 07, 2010 at 10:57:59 +0200, Bernhard Schiffner wrote: ... wird's was geben. Das ist klar, aber wo? GAG18? Ich gehe vom GAG18 aus und werde dort sein. Gruss, Chris Hallo alle zusammen, da mich das Thema wine interessiert, möchte ich die Gunst der Stunde nutzen und gerne einmal vorbei schauen. Leider sind die Informationen bezüglich des Stattfindens der Treffen etwas spärlich und widersprüchlich. Es soll ja der 2 und 4 Mittwoch im Monat sein (http://article.gmane.org/gmane.user-groups.linux.dresden/20893). Der Terminplan des GAG18 sagt dazu leider etwas anderes (http://www.gag18.de/programm.html?page). Für einen LUG-Treffen-Neuling wie mich ist das leider nicht sehr hilfreich. Wann ist denn nun das Treffen? Cheers Rico ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: Morgen Kinder ...
Es sieht ganz danach aus, als ob beim GAG18 jemand nicht rechnen kann, denn morgen ist bereits der zweite Mittwoch, aber vielleicht kann jemand noch mal dort anfragen. Gruß und Gute Nacht Björn smime.p7s Description: S/MIME Cryptographic Signature ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
