Hallo, Leute!
Ich habe bisher immer CVS benutzt. Nun soll ich einen Repository im Büro installieren. Ich wollte deswegen SVN probieren, den kenne ich aber von der administrativen Seite nicht.
Kann jemand mir einen guten HowTo vorschlagen?
Ich würde sehr gern die Systemnutzer nutzen (wie bei CVS), aber ungern über SSH, da ich nicht allen Nutzer einen SSH-Zugang geben will (keine Sicherheitsproblem, da hier nur lokales Netz ist).
Danke für eure Empfehlungen! Luca Bertoncello (lucabert@lucabert.de)
Hallo Luca!
Am 6. September 2010 17:19 schrieb Luca Bertoncello lucabert@lucabert.de:
Ich wollte deswegen SVN probieren, den kenne ich aber von der administrativen Seite nicht.
Ich würde sehr gern die Systemnutzer nutzen (wie bei CVS), aber ungern über SSH, da ich nicht allen Nutzer einen SSH-Zugang geben will (keine Sicherheitsproblem, da hier nur lokales Netz ist).
Subversion überlässt die Authentifizierung üblicherweise Apache2. Da kann libapache2-mod-auth-pam [1] dir gegen die Systemuser authentifizieren [2]. Vergiss dann aber bitte SSL nicht zu installieren, sonst kann jeder die Systempasswörter mitlesen.
In der Apache-Config schreibst du um SVN zu benutzen in deinem VirtualHost: DAV svn SVNParentPath /var/local/svn
Und wie du in /var/local/svn ein SVN-Repository unterbringst, findest du in massenweise HowTos.
Gruß Thomas
[1] http://packages.ubuntu.com/de/hardy/libapache2-mod-auth-pam [2] http://www.debianhelp.co.uk/apachepam.htm
Am Montag, 6. September 2010, 17:19:20 schrieb Luca Bertoncello:
Hallo, Leute!
Ich habe bisher immer CVS benutzt. Nun soll ich einen Repository im Büro installieren. Ich wollte deswegen SVN probieren, den kenne ich aber von der administrativen Seite nicht.
Kann jemand mir einen guten HowTo vorschlagen?
Nein, kann|will ich nicht.
ABER: 1.) Drüber nachdenken, welche Dateiformate benutzt werden. (git / svn sind gut bei Dingen, die auch "patch" vertragen würden, weniger also bei "blobs".)
2.) Welche Clienten stehen den Nutzern zur Verfügung (windows tortoise?)
3.) ICH würde heutzutage lieber ein git-Repository anlegen und nach außen als SVN verkaufen (git bliebe dabei für Kenner auch sichtbar). Das hilft Powerusern, die History ist im Ernstfall sehr leicht übertragbar und über Performance hat sich auch noch keiner beschwert. Ebenfalls interessant ist, das git per Design nachprüfbare Konsistenz des Inhalts bietet.
IMHO machen das ziemlich viele Admins schon unter der Hand so, einfach, da Windows keinen guten git-Clienten hat und deswegen SVN Vorgabe ist. (Es gibt wohl Performanceprobleme im Zusammenspiel Windows/NTFS, die Software selbst ist benutzbar.)
Danke für eure Empfehlungen! Luca Bertoncello (lucabert@lucabert.de)
;-) Bernhard
On Monday 06 September 2010 17:45:06 Bernhard Schiffner wrote:
3.) ICH würde heutzutage lieber ein git-Repository anlegen und nach außen als SVN verkaufen (git bliebe dabei für Kenner auch sichtbar). Das hilft Powerusern, die History ist im Ernstfall sehr leicht übertragbar und über Performance hat sich auch noch keiner beschwert. Ebenfalls interessant ist, das git per Design nachprüfbare Konsistenz des Inhalts bietet.
Ich stimme vollumfänglich zu. Ich hoste Git-Repositories mit Gitosis, und einfacher gehts wirklich nicht.
Allerdings weiß ich nicht, wie das mit SVN-Maskierung für Git aussieht. Ich mach es nur andersrum (Zugriff mit Git auf SVN-Repo).
Gruß Stefan
Hej Luca!
Ich würde sehr gern die Systemnutzer nutzen (wie bei CVS), aber ungern über SSH, da ich nicht allen Nutzer einen SSH-Zugang geben will (keine
Du kannst SSH problemlos so einschränken, dass die Nutzer damit _nur_ svn betreiben können und sonst nichts. (Stichworte: svn restricted ssh authorized_keys)
Beste Grüße Fabian
On Monday 06 September 2010, Luca Bertoncello wrote:
Ich habe bisher immer CVS benutzt. Nun soll ich einen Repository im Büro installieren. Ich wollte deswegen SVN probieren, den kenne ich aber von der administrativen Seite nicht.
Kann jemand mir einen guten HowTo vorschlagen?
SVN hat ein sehr gutes Buch, das auch online einsehbar ist: http://svnbook.red-bean.com/
Ich würde sehr gern die Systemnutzer nutzen (wie bei CVS), aber ungern über SSH, da ich nicht allen Nutzer einen SSH-Zugang geben will (keine Sicherheitsproblem, da hier nur lokales Netz ist).
SVN hat im Wesentlichen drei Modi:
file:///... - SVN greift direkt auf ein lokales Repository zu. Wird normalerweise verwendet wenn es nur ein Nutzer ist oder SVN nur für Backups verwendet wird.
svn+ssh://... - über SSH getunnelt. Alle Nutzer die dafür benutzt werden müssen vollen Schreibzugriff auf das Repository haben. Das ist in der Praxis nicht ganz einfach so zu verwirklichen dass es auch so bleibt. Und es hat das Problem dass man nicht wirklich einschränken kann was die Nutzer mit dem Repository tun können. Wird kaum verwendet, es sei denn der einzelne Nutzer betreut mehrere Rechner.
http://... - Apache2 plus Mod-SVN funktioniert als erweiterter DAV-Server. Das Repository gehört Apache und man braucht sich keine Sorgen um Zugriffsrechte machen. Die Nutzer existieren in der Konfiguration des SVN- Servers und man hat recht gute Kontrolle darüber welcher Nutzer was machen darf. Das ist die normale Konfiguration für Gruppen von Entwicklern.
Wie man das alles einrichtet steht im Buch oben.
Konrad
Am 6. September 2010 21:32 schrieb Konrad Rosenbaum konrad@silmor.de:
http://... - Apache2 plus Mod-SVN funktioniert als erweiterter DAV-Server. Die Nutzer existieren in der Konfiguration des SVN- Servers und man hat recht gute Kontrolle darüber welcher Nutzer was machen darf.
Ich mache das über Mod-Auth vom Apache2. Da kann ich für jedes Verzeichnis im Repository mit der Location-Direktive festlegen, welcher User hier commiten darf und wer nur lesen (das sind die HTTP-Befehle GET, PROPFIND, OPTIONS und REPORT).
<Location /svn/geheimakten> require user www-data thomas AuthType Basic AuthName "Subversion repository" AuthUserFile /www/passwords </Location>
Thomas
Kann jemand mir einen guten HowTo vorschlagen?
SVN hat ein sehr gutes Buch, das auch online einsehbar ist: http://svnbook.red-bean.com/
kann mich nur anschliessen das Buch ist echt hilfreich, habe es genommen
Ich würde sehr gern die Systemnutzer nutzen (wie bei CVS), aber ungern über SSH, da ich nicht allen Nutzer einen SSH-Zugang geben will (keine Sicherheitsproblem, da hier nur lokales Netz ist).
SVN hat im Wesentlichen drei Modi:
file:///... - SVN greift direkt auf ein lokales Repository zu. Wird normalerweise verwendet wenn es nur ein Nutzer ist oder SVN nur für Backups verwendet wird.
diesen Modi habe ich letztens mal schnell aufgesetzt
repository erstellt und im filesystem noch paar configs angepasst und es ging aufwand max 30min
Andreas
Hallo Luca,
Luca Bertoncello lucabert@lucabert.de (Mo 06 Sep 2010 17:19:20 CEST):
Hallo, Leute!
Ich habe bisher immer CVS benutzt. Nun soll ich einen Repository im Büro installieren. Ich wollte deswegen SVN probieren, den kenne ich aber von der administrativen Seite nicht.
Ich würde Git oder HG (Mercurial) probieren. Für letztere gibt es wohl auch einen brauchbaren Windows-Client (Tortoise oder so…), bei Git weiß ich das nicht. Ansonsten ist der Unterschied Git/HG wohl mehr religiöser Natur. Ich nutze HG, weil ich da den Umstieg von SVN als sehr schmerzarm empfunden hatte.
HG hängt als CGI-Script von der Authentifizierung des Apachen ab. Die Authorisierung kann dann im Repository selbst erledigt werden. Es gibt brauchbare Anleitungen dazu. WebDAV oder so Kram ist nicht notwendig, einfach ein Apache, der CGI kann. (Bei mir unter einer eigenen User-ID mit apache-mpm-itk.)
Hi:
2010/9/7 Heiko Schlittermann hs@schlittermann.de
Ich würde Git oder HG (Mercurial) probieren. Für letztere gibt es wohl auch einen brauchbaren Windows-Client (Tortoise oder so…), bei Git weiß ich das nicht. Ansonsten ist der Unterschied Git/HG wohl mehr religiöser Natur. Ich nutze HG, weil ich da den Umstieg von SVN als sehr schmerzarm empfunden hatte.
Der Windows GIT Client ist aehnlich wie TortoiseSVN / TortoiseCVS und durchaus gut benutzbar - und heisst TortoiseGIT ;-)
Als wir damals von SVN auf GIT umgestellt hatten war es eher eine Verstaendnisfrage was denn Commit, Changeset, Push, Repo etc... nun bei Git bedeuten. Das "nicht-zwingende-Vorhandensein" eines zentralen Repositories kann schon zu Fragen und Verwirrung fuehren.
Wenn Luca viele bestehende CVS/SVN User hat waere wohl eine Umstellung auf SVN im ersten Schritt, GIT/HG dann im zweiten Schritt empfehlenswert, denke ich.
Sebastian
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
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.)
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
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@mailman.schlittermann.de
-
Bernhard Schiffner -
Fabian Hänsel -
Grimnin Fridyson -
Heiko Schlittermann -
Konrad Rosenbaum -
Luca Bertoncello -
Sebastian Roth -
Stefan Majewsky -
Thomas Schmidt -
Torsten Werner