nicht angemeldet dedlfix
dedlfix
Matti Mäkitalo
dedlfix
dedlfix
Auge
dedlfix
Auge
Hallo Gemeinde,
bis jetzt habe ich noch nie mit einer Versionierungssoftware gearbeitet! Daher frage ich euch: Welche Erfahrungen habt Ihr damit? und welche Versionierungssoftware(Subversion, Git, CSV) würdert Ihr empfehlen?
Gruß
Sipatshi
Grüße,
bis jetzt habe ich noch nie mit einer Versionierungssoftware gearbeitet! Daher frage ich euch: Welche Erfahrungen habt Ihr damit? und welche Versionierungssoftware(Subversion, Git, CSV) würdert Ihr empfehlen?
welche lässt sich denn am bequemsten in deine IDE integrieren?
MFG
bleicher
Hallo,
welche lässt sich denn am bequemsten in deine IDE integrieren?
Subversion und CVS
Gruß
Sipatshi
Grüße,
subversion ist relativ einfach im Gebrauch, aber beschissen dokumentiert.
Dokumentation ist da, aber da was auszulesen ist schwer - wenn mal was schief läuft
MFG
bleicher
Moin!
bis jetzt habe ich noch nie mit einer Versionierungssoftware gearbeitet! Daher frage ich euch: Welche Erfahrungen habt Ihr damit? und welche Versionierungssoftware(Subversion, Git, CSV) würdert Ihr empfehlen?
Von CVS ist definitiv abzuraten. Diese Software ist nicht nur im Kontext "So sollte Versionskontrolle sein" schlecht, sondern auch noch im wesentlich kleineren Kontext "So sollte Versionskontrolle mit zentralem Server sein".
Wenn es also unbedingt ein zentraler Server sein soll, nimm halt Subversion.
Würde ich dir allerdings trotzdem nicht empfehlen. Der vernünftigste Ansatz ist ein dezentrales Versionskontrollsystem. Nimm also GIT, Mercurial oder sowas. Du hast den Vorteil, dass du nicht umlernen und deine Erfahrungen mit Subversion oder gar CVS vergessen musst, also fang gleich mit dem richtigen System an.
- Sven Rautenberg
Hi!
Der vernünftigste Ansatz ist ein dezentrales Versionskontrollsystem.
Gibt es Begründungen für diese These, typische Anwendungsfälle und solche, bei denen man es nicht nehmen kann?
Lo!
Moin!
Der vernünftigste Ansatz ist ein dezentrales Versionskontrollsystem.
Gibt es Begründungen für diese These, typische Anwendungsfälle und solche, bei denen man es nicht nehmen kann?
Ja, gibts.
Allein schon die Tatsache, dass man bei zentralen Systemen nur committen kann, indem man seinen Mitarbeitenden seinen Code aufzwingt, egal ob die den wollten oder nicht.
Und dezentrale Systeme können sich natürlich auch wie zentrale Systeme verhalten - umgekehrt funktioniert es nicht.
- Sven Rautenberg
Hi!
Der vernünftigste Ansatz ist ein dezentrales Versionskontrollsystem.
Gibt es Begründungen für diese These, typische Anwendungsfälle und solche, bei denen man es nicht nehmen kann?
Allein schon die Tatsache, dass man bei zentralen Systemen nur committen kann, indem man seinen Mitarbeitenden seinen Code aufzwingt, egal ob die den wollten oder nicht.
Und wenn man solch eine Anforderung nicht hat? Der OP hat ja die seinigen an ein solches System nicht genannt. Es könnte sich ja auch um solch ein Szenario handeln: Eine Einzelperson möchte mit einem Rechner an Ort A und einem weiteren an Ort B arbeiten, natürlich nie zur gleichen Zeit. Und wenn er an Ort A ist, ist Rechner B ausgeschaltet und umgekehrt. Hilft dann ein verteiltes System ohne einen zusätzlichen Server? Da keine weiteren Mitarbeiter vorgesehen sind, sondern nur Arbeitsstände synchronisiert und versioniert werden sollen, welche Vorteile hat dann noch ein dezentrales System?
Muss man für solche dezentralen Systeme immer einen Daemon/Dienst laufen haben, sowie eine bekannte IP-Adresse besitzen, damit sich andere verbinden können? Wie ist es mit Arbeiten hinter Firewalls, über die man noch dazu keine administrative Gewalt hat, beispielsweise wenn man in einem Unternehmen sitzt, das einen Internetzugriff nur über Proxy gestattet?
Ist also in solchen Fällen ein dezentrales Versionskontrollsystem immer noch der vernünftigste Ansatz? Das soll übrigens auch an den OP eine Aufforderung sein, seine Anforderungen und Randbedingungen anzugeben, damit man diese bei der Antwort berücksichtigen kann.
Lo!
Hi,
Muss man für solche dezentralen Systeme immer einen Daemon/Dienst laufen haben, sowie eine bekannte IP-Adresse besitzen, damit sich andere verbinden können? Wie ist es mit Arbeiten hinter Firewalls, über die man noch dazu keine administrative Gewalt hat, beispielsweise wenn man in einem Unternehmen sitzt, das einen Internetzugriff nur über Proxy gestattet?
Das Argument gilt doch umso mehr für zentrale Systeme.
Bei zentralen Systemen muss immer der zentrale Punkt erreichbar sein, egal was man tut.
Bei dezentralen Systemen wie git kann ich lokal arbeiten, wenn der zentrale Punkt (z.B. der "Hauptentwicklungszweig", an dem sich alle Teilbäume wieder vereinigen (sollen)) nicht verfügbar/erreichbar ist.
Bis die Tage,
Matti
Hi!
Muss man für solche dezentralen Systeme immer einen Daemon/Dienst laufen haben, sowie eine bekannte IP-Adresse besitzen, damit sich andere verbinden können? Wie ist es mit Arbeiten hinter Firewalls, über die man noch dazu keine administrative Gewalt hat, beispielsweise wenn man in einem Unternehmen sitzt, das einen Internetzugriff nur über Proxy gestattet?
Das Argument gilt doch umso mehr für zentrale Systeme.
Gerade bei einem zentralen Server wie SVN sind die obigen Punkte kein Thema. Der Server ist irgendwo stets erreichbar, dessen Adresse ist bekannt und er kann normalerweise auch über einen Proxy angesprochen werden. Der Punkt war, ob sich die dezentralen Systeme ebenso leicht erreichen lassen. Und ob man statt einem Server mit einem offenen Port nun viele Server mit je einem offenen Port betreiben muss - inklusive dem Einrichten von Portforwarding hinter Routern.
Bei zentralen Systemen muss immer der zentrale Punkt erreichbar sein, egal was man tut.
Wenn ich den aktuellen Stand haben möchte, muss auch einer der dezentralen Punkte erreichbar und aktuell sein. Die Frage war, ob man in meinem Szenario vom dezentralen System irgendeinen Vorteil hat oder eine Infrastruktur wie beim zentralen System benötigt.
Bei dezentralen Systemen wie git kann ich lokal arbeiten, wenn der zentrale Punkt (z.B. der "Hauptentwicklungszweig", an dem sich alle Teilbäume wieder vereinigen (sollen)) nicht verfügbar/erreichbar ist.
Da hab ich aber keinen aktuellen Stand. Man kann vielleicht weiterarbeiten, wenn man Arbeitsteilung hat und wenigstens der von einem selbst bearbeitete Teil lokal verfügbar ist. Das war in meinem Szenario nicht gegeben. Dazu bräuchte man einen Laptop oder nur einen Arbeitsort.
Lo!
Moin!
Muss man für solche dezentralen Systeme immer einen Daemon/Dienst laufen haben, sowie eine bekannte IP-Adresse besitzen, damit sich andere verbinden können? Wie ist es mit Arbeiten hinter Firewalls, über die man noch dazu keine administrative Gewalt hat, beispielsweise wenn man in einem Unternehmen sitzt, das einen Internetzugriff nur über Proxy gestattet?
Das Argument gilt doch umso mehr für zentrale Systeme.Gerade bei einem zentralen Server wie SVN sind die obigen Punkte kein Thema.
Das siehst du falsch.
Der Server ist irgendwo stets erreichbar, dessen Adresse ist bekannt und er kann normalerweise auch über einen Proxy angesprochen werden. Der Punkt war, ob sich die dezentralen Systeme ebenso leicht erreichen lassen. Und ob man statt einem Server mit einem offenen Port nun viele Server mit je einem offenen Port betreiben muss - inklusive dem Einrichten von Portforwarding hinter Routern.
Halten wir fest: OHNE Zugang zum zentralen SVN-Server kann man mit SVN nicht arbeiten. Ohne Zugang zu einem als zentral definierten Git-Server kann man aber sehr wohl arbeiten.
Und die Verfügbarkeit eines Online-Zugangs schwankt durchaus!
Bei zentralen Systemen muss immer der zentrale Punkt erreichbar sein, egal was man tut.
Wenn ich den aktuellen Stand haben möchte, muss auch einer der dezentralen Punkte erreichbar und aktuell sein. Die Frage war, ob man in meinem Szenario vom dezentralen System irgendeinen Vorteil hat oder eine Infrastruktur wie beim zentralen System benötigt.
Der dezentrale Punkt liegt auf der eigenen Platte. Dorthin kann ich mir alle Entwicklungszweige der Mitarbeitenden zusammenziehen und lokal so arbeiten, als wäre ich mit dem zentralen Server verbunden. Ich muss aber kein einziges Byte online versenden, um so arbeiten zu können, d.h. ich kann mir dann, wenn ich online bin, alle anderen Entwicklungszweige holen.
Bei dezentralen Systemen wie git kann ich lokal arbeiten, wenn der zentrale Punkt (z.B. der "Hauptentwicklungszweig", an dem sich alle Teilbäume wieder vereinigen (sollen)) nicht verfügbar/erreichbar ist.
Da hab ich aber keinen aktuellen Stand.
Es gibt ja auch nicht "den aktuellen Stand" in einem verteilten Entwicklungssystem. Und die neuesten Entwicklungen und Commits in den Zweigen der Mitarbeitenden interessieren in der Regel auch nicht, solange diese nicht freigegeben und in die aktuelle Codebasis eingearbeitet wurden.
Man kann vielleicht weiterarbeiten, wenn man Arbeitsteilung hat und wenigstens der von einem selbst bearbeitete Teil lokal verfügbar ist. Das war in meinem Szenario nicht gegeben. Dazu bräuchte man einen Laptop oder nur einen Arbeitsort.
Git ist darauf ausgelegt, lokal zu arbeiten und obendrein noch gut strukturierte Netzwerkkommunikation zur Codeverteilung anzubieten.
Subversion _kann_ das Repository auch lokal ablegen, aber das war's dann auch, damit ist man festgelegt auf genau diesen einen Ort des Repositories. Lokal arbeiten und optional mit anderen Servern, das geht mit Subversion nicht.
- Sven Rautenberg
Hi!
Muss man für solche dezentralen Systeme immer einen Daemon/Dienst laufen haben, sowie eine bekannte IP-Adresse besitzen, damit sich andere verbinden können? Wie ist es mit Arbeiten hinter Firewalls, über die man noch dazu keine administrative Gewalt hat, beispielsweise wenn man in einem Unternehmen sitzt, das einen Internetzugriff nur über Proxy gestattet?
Das Argument gilt doch umso mehr für zentrale Systeme.
Gerade bei einem zentralen Server wie SVN sind die obigen Punkte kein Thema.
Das siehst du falsch.
Aber was daran falsch ist, kann ich in deiner Antwort nicht erkennen.
Der Server ist irgendwo stets erreichbar, dessen Adresse ist bekannt und er kann normalerweise auch über einen Proxy angesprochen werden. Der Punkt war, ob sich die dezentralen Systeme ebenso leicht erreichen lassen. Und ob man statt einem Server mit einem offenen Port nun viele Server mit je einem offenen Port betreiben muss - inklusive dem Einrichten von Portforwarding hinter Routern.
Halten wir fest: OHNE Zugang zum zentralen SVN-Server kann man mit SVN nicht arbeiten. Ohne Zugang zu einem als zentral definierten Git-Server kann man aber sehr wohl arbeiten.
Ohne Zugang zu einem zentralen Server kann ich genauso gut, schlecht oder gar nicht arbeiten wie ohne Zugang zu einem dezentralen Server, nämlich nur mit dem Zeug, was bereits auf meiner Platte ist oder eben fehlt. Einzig privates Versionieren ist bei einem verteilten System ohne Zugang zu anderen Servern zusätzlich möglich.
Was ist mit den netzwerktechnischen Argumenten?
Und die Verfügbarkeit eines Online-Zugangs schwankt durchaus!
Eine Alles-und-Nichts-Aussage.
Bei zentralen Systemen muss immer der zentrale Punkt erreichbar sein, egal was man tut.
Wenn ich den aktuellen Stand haben möchte, muss auch einer der dezentralen Punkte erreichbar und aktuell sein. Die Frage war, ob man in meinem Szenario vom dezentralen System irgendeinen Vorteil hat oder eine Infrastruktur wie beim zentralen System benötigt.
Der dezentrale Punkt liegt auf der eigenen Platte.
Das tut er ja nicht aus heiterem Himmel sondern muss erste einmal dorthin gelangen und irgendwann auch wieder zurück zu den anderen.
Dorthin kann ich mir alle Entwicklungszweige der Mitarbeitenden zusammenziehen und lokal so arbeiten, als wäre ich mit dem zentralen Server verbunden. Ich muss aber kein einziges Byte online versenden, um so arbeiten zu können, d.h. ich kann mir dann, wenn ich online bin, alle anderen Entwicklungszweige holen.
Gilt vor allem für's Versionieren. Ich bin aber nicht komplett arbeitsunfähig, wenn ich bei einem zentralen System grad keinen Zugang habe. Arbeiten kann man schon, nur eben nicht versionieren.
Bei dezentralen Systemen wie git kann ich lokal arbeiten, wenn der zentrale Punkt (z.B. der "Hauptentwicklungszweig", an dem sich alle Teilbäume wieder vereinigen (sollen)) nicht verfügbar/erreichbar ist.
Da hab ich aber keinen aktuellen Stand.
Es gibt ja auch nicht "den aktuellen Stand" in einem verteilten Entwicklungssystem. Und die neuesten Entwicklungen und Commits in den Zweigen der Mitarbeitenden interessieren in der Regel auch nicht, solange diese nicht freigegeben und in die aktuelle Codebasis eingearbeitet wurden.
Also gibt es den aktuellen offiziellen Stand und viele nicht freigegebene.
Man kann vielleicht weiterarbeiten, wenn man Arbeitsteilung hat und wenigstens der von einem selbst bearbeitete Teil lokal verfügbar ist. Das war in meinem Szenario nicht gegeben. Dazu bräuchte man einen Laptop oder nur einen Arbeitsort.
Git ist darauf ausgelegt, lokal zu arbeiten und obendrein noch gut strukturierte Netzwerkkommunikation zur Codeverteilung anzubieten.
Schön, wenn man es braucht. Und wenn nicht? Ist es dann trotzdem immer noch uneingeschränkt empfehlenswert?
Subversion _kann_ das Repository auch lokal ablegen, aber das war's dann auch, damit ist man festgelegt auf genau diesen einen Ort des Repositories. Lokal arbeiten und optional mit anderen Servern, das geht mit Subversion nicht.
Ein verteiltes System hat also Vorteile, wenn man die Arbeit unter mehreren Leuten aufteilen will. Ihr weicht aber aus und beschreibt immer wieder nur Vorteile beim Arbeiten mit mehreren Personen. Warum bewertet ihr nicht mal die Eigenschaften eines dezentralen Systems für das von mir aufgeführte Szenario? Auch wurden die obigen Fragen noch nicht beantwortet.
Lo!
Hallo
Der Server ist irgendwo stets erreichbar, dessen Adresse ist bekannt und er kann normalerweise auch über einen Proxy angesprochen werden. Der Punkt war, ob sich die dezentralen Systeme ebenso leicht erreichen lassen. Und ob man statt einem Server mit einem offenen Port nun viele Server mit je einem offenen Port betreiben muss - inklusive dem Einrichten von Portforwarding hinter Routern.
Halten wir fest: OHNE Zugang zum zentralen SVN-Server kann man mit SVN nicht arbeiten. Ohne Zugang zu einem als zentral definierten Git-Server kann man aber sehr wohl arbeiten.Ohne Zugang zu einem zentralen Server kann ich genauso gut, schlecht oder gar nicht arbeiten wie ohne Zugang zu einem dezentralen Server, nämlich nur mit dem Zeug, was bereits auf meiner Platte ist oder eben fehlt. Einzig privates Versionieren ist bei einem verteilten System ohne Zugang zu anderen Servern zusätzlich möglich.
Das ist ja der Vorteil. Jeder der mitarbeitenden kann seinen eigenen Stand ohne Serverzugang pflegen. Zum Abgleich aller Stände braucht man dann natürlich wieder diesen Zugang oder eine andere Abgleichsmöglichkeit. An _dieser Stelle_ gleicht das Vorgehen dem zentraler Systeme.
Bei zentralen Systemen muss immer der zentrale Punkt erreichbar sein, egal was man tut.
Wenn ich den aktuellen Stand haben möchte, muss auch einer der dezentralen Punkte erreichbar und aktuell sein. Die Frage war, ob man in meinem Szenario vom dezentralen System irgendeinen Vorteil hat oder eine Infrastruktur wie beim zentralen System benötigt.
Der dezentrale Punkt liegt auf der eigenen Platte.Das tut er ja nicht aus heiterem Himmel sondern muss erste einmal dorthin gelangen und irgendwann auch wieder zurück zu den anderen.
Siehe oben.
Dorthin kann ich mir alle Entwicklungszweige der Mitarbeitenden zusammenziehen und lokal so arbeiten, als wäre ich mit dem zentralen Server verbunden. Ich muss aber kein einziges Byte online versenden, um so arbeiten zu können, d.h. ich kann mir dann, wenn ich online bin, alle anderen Entwicklungszweige holen.
Gilt vor allem für's Versionieren. Ich bin aber nicht komplett arbeitsunfähig, wenn ich bei einem zentralen System grad keinen Zugang habe. Arbeiten kann man schon, nur eben nicht versionieren.
Mit dezentralen Systemen kannst du das. Du versionierst vor dich hin und gleichst den Stand dann 'irgendwann' mit den anderen Beteiligten ab.
Bei dezentralen Systemen wie git kann ich lokal arbeiten, wenn der zentrale Punkt (z.B. der "Hauptentwicklungszweig", an dem sich alle Teilbäume wieder vereinigen (sollen)) nicht verfügbar/erreichbar ist.
Da hab ich aber keinen aktuellen Stand.
Es gibt ja auch nicht "den aktuellen Stand" in einem verteilten Entwicklungssystem. Und die neuesten Entwicklungen und Commits in den Zweigen der Mitarbeitenden interessieren in der Regel auch nicht, solange diese nicht freigegeben und in die aktuelle Codebasis eingearbeitet wurden.Also gibt es den aktuellen offiziellen Stand und viele nicht freigegebene.
sozusagen;
Man kann vielleicht weiterarbeiten, wenn man Arbeitsteilung hat und wenigstens der von einem selbst bearbeitete Teil lokal verfügbar ist. Das war in meinem Szenario nicht gegeben. Dazu bräuchte man einen Laptop oder nur einen Arbeitsort.
Git ist darauf ausgelegt, lokal zu arbeiten und obendrein noch gut strukturierte Netzwerkkommunikation zur Codeverteilung anzubieten.Schön, wenn man es braucht. Und wenn nicht? Ist es dann trotzdem immer noch uneingeschränkt empfehlenswert?
Meiner Meinung nach ja.
Subversion _kann_ das Repository auch lokal ablegen, aber das war's dann auch, damit ist man festgelegt auf genau diesen einen Ort des Repositories. Lokal arbeiten und optional mit anderen Servern, das geht mit Subversion nicht.
Ein verteiltes System hat also Vorteile, wenn man die Arbeit unter mehreren Leuten aufteilen will. Ihr weicht aber aus und beschreibt immer wieder nur Vorteile beim Arbeiten mit mehreren Personen. Warum bewertet ihr nicht mal die Eigenschaften eines dezentralen Systems für das von mir aufgeführte Szenario? Auch wurden die obigen Fragen noch nicht beantwortet.
Das dezentrale System hat in deinem Szenario (ein Coder an mehreren Rechnern) keine Nachteile. Bin ich auf Arbeit, versioniere ich da, bin ich zuhause, dann halt dort. Der Abgleich der Stände erfolgt z.B. über ein zentrales Repository auf einem von beiden Orten aus zugänglichen Server, kann aber auch per Email erfolgen (habe ich aber noch nicht gemacht).
Tschö, Auge
Schön, wenn man es braucht. Und wenn nicht? Ist es dann trotzdem immer noch uneingeschränkt empfehlenswert?
Meiner Meinung nach ja.
Also hat es die gleiche oder bessere Unterstützung als Subversion bei
?
Wenn du das alles mit "ja" beantworten kann, glaub ich dir deine Aussage, ansonsten muss ich sagen, ich bleib bei svn, weil mir die Umstellung zuviel Zeit und damit Geld kostet.
Denn um ein neues System einzuführen muss sich das nicht nur gefühlstechnisch sondern auch finanziell lohen und zwar nicht erst in 10 Jahren sondern kurzfristig.
Moin!
Schön, wenn man es braucht. Und wenn nicht? Ist es dann trotzdem immer noch uneingeschränkt empfehlenswert?
Meiner Meinung nach ja.
Also hat es die gleiche oder bessere Unterstützung als Subversion bei
- post- und pre-commit scripts
- dbus bzw. dcop-unterstützung
- trac-ähnliches Frontend?
- einfache Einbindung in Apache
- vollständige integration meiner IDE (Quanta+ und KDevelop)
- übernahme meiner Shellscripte
?
Wenn du das alles mit "ja" beantworten kann, glaub ich dir deine Aussage, ansonsten muss ich sagen, ich bleib bei svn, weil mir die Umstellung zuviel Zeit und damit Geld kostet.
Denn um ein neues System einzuführen muss sich das nicht nur gefühlstechnisch sondern auch finanziell lohen und zwar nicht erst in 10 Jahren sondern kurzfristig.
Hast du mit SVN schon mal zwei Branches gemerged? Mehr als einmal?
Abgesehen davon kann man SVN- und GIT-Infrastruktur recht problemlos parallel laufen lassen.
- Sven Rautenberg
Hast du mit SVN schon mal zwei Branches gemerged? Mehr als einmal?
Nein, hab ich bisher nicht gebraucht. Daher auch keine meiner Anforderungen.
Abgesehen davon kann man SVN- und GIT-Infrastruktur recht problemlos parallel laufen lassen.
Dann bleibt aber immer noch die Integration in das bestehende System. Wie geschrieben, hab ich da eine Reihe an Anforderungen und ich hab bisher noch keine konkreten Hinweise gefunden, dass ich meine Anforderungen mit GIT erfüllen kann.
Somit ist die Aussage "uneingeschränkt empfehlenswert" für mich schlichtweg falsch, solange mich niemand vom Gegenteil überzeugt. Ich hab ca. 1 Jahr gebraucht, bis mein Subversion so automatisiert gelaufen ist, wie jetzt. Mit GIT würde ich nicht nochmal soviel Arbeit investieren, da ich zu 99,9% alleine Arbeite und die Versionskontrolle hauptsächlich als "Backup mit Rollbackmöglichkeit" nutze.
Kann es sein, dass es mit GIT und Subversion so ist wie beim Browserkrieg oder beim Vergleich von Windows und Linux?
Hi,
Kann es sein, dass es mit GIT und Subversion so ist wie beim Browserkrieg oder beim Vergleich von Windows und Linux?
Nein. Abgesehen von deiner eigenen Umgebung (*) bietet git eine klare Übermenge an Funktionen ggü. svn.
*: nach eigener Konfiguration, eigenen speziell auf svn abgestimmten Skripten, ...
Diese müsste man (offensichtlich) auf git abstimmen statt auf svn.
Deshalb ist die Fragestellung eine andere:
Vor Beginn der Einrichtung eines VCS ist git "besser", in einem Zustand wie deinem _kann_ svn besser sein, weil Protierungsaufwand hinzukommt.
Bis die Tage,
Matti
Vor Beginn der Einrichtung eines VCS ist git "besser", in einem Zustand wie deinem _kann_ svn besser sein, weil Protierungsaufwand hinzukommt.
Ok, daraus lese ich, dass für mich git nicht genügend Vorteile bringt um einen Umstieg zu rechtfertigen. Das ist eine Aussage mit der ich was anfangen kann :)
Hi!
Das dezentrale System hat in deinem Szenario (ein Coder an mehreren Rechnern) keine Nachteile. Bin ich auf Arbeit, versioniere ich da, bin ich zuhause, dann halt dort. Der Abgleich der Stände erfolgt z.B. über ein zentrales Repository auf einem von beiden Orten aus zugänglichen Server,
Wenn es sowieso ein zentrales Repository benötigt, dann sehe ich keinen wirklichen Vorteil eines dezentralen Systems (für meinen Anwendungsfall - welchen Anwendungsfall der OP hat, wissen wir ja leider noch nicht).
kann aber auch per Email erfolgen (habe ich aber noch nicht gemacht).
_Das_ wäre allerdings eine Möglichkeit auf ein zentrales Repository zu verzichten und trotz ausgeschalteten oder anderweitig nicht direkt erreichbaren Rechnern einen Abgleich vornehmen zu können.
Lo!
Hallo,
Ich habe mit Subversion bislang sehr gute Erfahrung gemacht (privat und auf der Arbeit im Einsatz).
CVS muss ich hie und da auch benutzen, und finde es nicht besonders schön, sondern an vielen Punkten einfach sehr umständlich.
GIT habe ich noch nicht probiert, ich kenne aber sehr viele die darauf schwören (bin bislang nur noch nicht zum installieren gekommen).
=> GIT oder Subversion wäre mein Tipp.
Hallo
bis jetzt habe ich noch nie mit einer Versionierungssoftware gearbeitet! Daher frage ich euch: Welche Erfahrungen habt Ihr damit? und welche Versionierungssoftware(Subversion, Git, CSV) würdert Ihr empfehlen?
Ich nutze Git und bin damit sehr zufrieden. Einen guten Einstieg in Git erhältst du mit dem CRE-Podcast verteilte Versionskontrollsysteme, den hier Sven Rautenberg schon mal empfohlen hat (dem ich hiermit dafür ausdrücklich danke).
Tschö, Auge
Hallo Gemeinde,
vielen Dank für euch tips.
Ich starte mit Git :)
Gruß
Sipatshi
Ich starte mit Git :)
Hi,
ist sicher eine vernünftige Entscheidung, wenn auch nicht meine ;-)
Git arbeitet sehr sauber, gerade die merges sind wirklich gut, dennoch bin ich wieder von Git weggegangen und habe mich für mercurial entschieden.
Hauptgrund war für mich, dass mercurial das Einzige nicht zentrale System war, dass mir ein Template in den Dateien füllen konnte. Es ist (für meinen Zweck) sehr wichtig, eine Datei bspw. auf dem Server öffnen zu können und dem Quelltext anzusehen, welche Version diese Datei hat.
SVN kann das und eben mercurial. Git kann das nicht.
Wenn Du darauf verzichten kannst, ist Git allerdings sicher eine sehr gute Wahl, alleine weil Du viel mehr Anleitung im Web dazu bekommst als zu mercurial.
Gruß, Kjorni
