Privaten SVN Server einrichten!

[Mavarik]

Hallo Zusammen!

Ich möchte auf meinem Internetserver einen SVN Server einrichten...

Und zwar diesen...

Ich will den Server "nur" privat nutzen und meine Daten - auf keinen Fall - anderen zugänglich machen.

Mein Server hat kein SSL Zertifikat. Reicht das erzeuge Zertifikat aus?

Kann ich trotzdem den Server mit ausreichender Sicherheit betreiben? Was muss ich beachten?
Wer kennt sich damit aus?

Grüsse Mavarik

[Bbommel]

Erstmal Fragen über Fragen: Was heißt denn "auf deinem Internetserver"? Was machst du bisher damit? Laufen darauf auch ganz normale Webseiten? Ist das eine echte Maschine, die irgendwo steht, oder ein normales Web-Hosting-Paket oder eine virtuelle Maschine bei einem Provider?

Als Anhaltspunkt vielleicht mal wie ich das gelöst habe: Ich habe bei 1&1 einen virtuellen Server, der nur für interne Zwecke benutzt wird. Auf diesem laufen also keine öffentlich abrufbaren Webseiten. Nach außen hin ist dieser Server per Firewall komplett dicht, nur SSH und OpenVPN sind von außen erreichbar. Erst wenn man per VPN mit dem Rechner verbunden ist, kann man die weiteren Dienste nutzen, die also nur lokal in dem VPN verfügbar sind. Dann kann man auch auf Dateifreigaben zugreifen oder eben auf Subversion.

Bis denn
Bommel

[Lemmy]

und von mir: Das Ding sieht arg nach Windows aus - ist das ein Windows-Server? Und wenn da eh schon Apache/IIS laufen - lassen die sich abschalten bzw. dein bevorzugter VisuelSVN entsprechend Konfigurieren damit die sich nicht beißen?

[Mavarik]

Also!

Es ist ein "echter" Windows Server 1" Rack. Ja, Es laufen Webseiten darauf und natürlich IIS, FTP, MySQL usw...

Mavarik

[daywalker9]

In den Einstellungen kannst du Https deaktivieren - und einen belobigen Port wählen auf dem der Svn Server läuft. Hatte den so auch eine zeit lang, bin mittlerweile aber bei git und bitbucket.org gelandet

[Mavarik]

Warum sollte ich https deaktivieren wollen?

Das geht doch ganz prima mit dem Self-Signing-Zertifikar...

Mavarik

[Elvis]

Der Elephant im Raum ist wohl die Frage nach SVN selbst.
Wenn du nicht gerade die krasseste code history mit zig Umbenennungen hast, kannst du deine SVN repos sehr einfach zu Git oder Mercurial konvertieren.

Danach hast du immer alles zur Verfügung, sogar wenn dein Server nicht da ist.
SVN heißt ja, dass ALLES über den Server gehen muss. Das ist im lokalen Netzwerk schon lahm, aber über's Internet? :shock:


Es gibt ein paar sehr coole Lösungen, die ein verteiltes VCS wie Git oder Mercurial mit einem Issue-Tracker kombinieren.
Ich würde ohne solch eine Kombination gar nicht mehr arbeiten wollen.


Bei Bitbucket musst du es nicht einmal selbst hosten.
https://bitbucket.org/features
Wenn du das willst, gibt es Gitlab:
http://gitlab.org/gitlab-ce/

Ich benutze beruflich Kiln:
http://www.fogcreek.com/kiln/
Das ist standardmäßig private und kostet erst ab 3 Benutzern.
Kiln bietet sogar ein Tool um alte SVN repos zu importieren.

[vagtler]

Da muss ich Elvis beipflichten. Aber sowas von.

Heutzutage würde ich - wenn es nicht wirklich sehr gute Gründe geben sollte - auch nicht einmal mehr ansatzweise daran denken, ein zentrales Quellcodeverwaltungssystem wie es SVN darstellt einzusetzen. Und Systeme wie Kiln, BitBucket aber auch gitHub bieten darüber hinaus das gesamte No-Worries-Programm an - wozu noch den Aufwand eines selbst administrierten Servers?

[hstreicher]

Gibts da auch was Europäisches ,
bei dem ich zumindest die Hoffnung auf etwas Datenschutz habe ?

[jfheins]

Du kannst dir auch git auf einem eigenen Server einrichten. Ich habe selbst auf meinem NAS ein git laufen, da kann ich mich von überall (über einen dynDNS-Service) per SSH verbinden.

Das Zeug ist aber vermutlich auf Linux leichter einzurichten. Unter Windows sollte es aber prinzipiell ebenso funktionieren. Ich habe auch schon mit dem Gedanken gespielt, das ganze ins schneller Internet zu verlagern. (Mein DSL hat ja nur 1 MBit Upload). Für "nur git" würde sich dann das kostenlose RasPi Hosting anbieten, da dann ne ordentliche SD-Karte hinein und schon hat man einen "eigenen git Server".
Ist aber eher nix für einen richtigen, kommerziellen Gebrauch.

Für Windows gibt es aber sicher auch etwas, mal so auf die schnelle: http://bonobogitserver.com/

[grl]

Also, SVN auf einem Linux-Server ist blitzartig eingerichtet.

Und nein - die diversen Angebote, die's da in der "Cloud" gibt kommen nicht in Frage - schließlich verteil ich nicht meine Sourcecodes (die immerhin das Kapital meiner Firma darstellen) in der Weltgeschichte....

GRL

[vagtler]

Zitat:

Zitat von grl (Beitrag 1233261)

Also, SVN auf einem Linux-Server ist blitzartig eingerichtet. [...]

Nicht schneller oder langsamer als ein dezentrales System wie z.B. git (Server im klassischen Sinn gibt's da nicht).

Zitat:

[...] Und nein - die diversen Angebote, die's da in der "Cloud" gibt kommen nicht in Frage - schließlich verteil ich nicht meine Sourcecodes (die immerhin das Kapital meiner Firma darstellen) in der Weltgeschichte.... [...]

Klar. Diese uns angeborene pauschalisierende Sicht hat uns schon oft die Weltmarktführerschaft gekostet. Warum sollte es bei den aktuellen Entwicklungen anders sein?

Damit sollten Bedenken bzgl. Datensicherheit und Datenhoheit nicht heruntergespielt werden, nur habe ich schon oft gesehen, dass die selbst mit teilweise hohem Aufwand betriebenen Systeme auf Grund der mangelnden Qualifizierung und Spezialisierung der beteiligten Ressourcen eher unsicher im Vergleich zu den kommerziellen Angeboten sind - oft ist nunmal Bargeld bei der Bank sicherer aufgehoben als in der Schublade des Büroschreibtischs.

Gerade weil in unserer Branche eine hohe Sensibilität auf das Betriebskapital (also den Quellcode) gelegt werden muss, ist ein Blick auf die Angebote davon lebender Anbieter sinnvoll - nicht umgekehrt.

[grl]

Zitat:

Zitat von vagtler (Beitrag 1233264)

Zitat:

Zitat von grl (Beitrag 1233261)

Also, SVN auf einem Linux-Server ist blitzartig eingerichtet. [...]

Nicht schneller oder langsamer als ein dezentrales System wie z.B. git (Server im klassischen Sinn gibt's da nicht).

Und was willst du damit sagen? Die Frage von Mavarick war nach SVN - also gibts eine Antwort zu SVN. Mir geht das tierisch auf den Keks, wenn man konkret nach etwas fragt und dann nur Antworten bekommt, die mit der Frage nix zu tun haben sondern nur erklären, daß man doch eigentlich ganz falsch liegt und alles doch ganz anders machen soll.

Zitat:

Zitat von vagtler (Beitrag 1233264)

Zitat:

[...] Und nein - die diversen Angebote, die's da in der "Cloud" gibt kommen nicht in Frage - schließlich verteil ich nicht meine Sourcecodes (die immerhin das Kapital meiner Firma darstellen) in der Weltgeschichte.... [...]

Klar. Diese uns angeborene pauschalisierende Sicht hat uns schon oft die Weltmarktführerschaft gekostet. Warum sollte es bei den aktuellen Entwicklungen anders sein?

Damit sollten Bedenken bzgl. Datensicherheit und Datenhoheit nicht heruntergespielt werden, nur habe ich schon oft gesehen, dass die selbst mit teilweise hohem Aufwand betriebenen Systeme auf Grund der mangelnden Qualifizierung und Spezialisierung der beteiligten Ressourcen eher unsicher im Vergleich zu den kommerziellen Angeboten sind - oft ist nunmal Bargeld bei der Bank sicherer aufgehoben als in der Schublade des Büroschreibtischs.

Gerade weil in unserer Branche eine hohe Sensibilität auf das Betriebskapital (also den Quellcode) gelegt werden muss, ist ein Blick auf die Angebote davon lebender Anbieter sinnvoll - nicht umgekehrt.

Kein Kommentar - wenn einer sein Betriebskapital aus der Jurisdiktion des eigenen Landes bewegt ist das sein eigenes Vergnügen und auch sein eigenes Problem - Viel Vergnügen damit wenn's mal wo hakt...

GRL

[vagtler]

Zitat:

Zitat von grl (Beitrag 1233268)

[...] Und was willst du damit sagen? Die Frage von Mavarick war nach SVN - also gibts eine Antwort zu SVN. Mir geht das tierisch auf den Keks, wenn man konkret nach etwas fragt und dann nur Antworten bekommt, die mit der Frage nix zu tun haben sondern nur erklären, daß man doch eigentlich ganz falsch liegt und alles doch ganz anders machen soll. [...]

Mavarik möchte SVN auf Windows installieren und Du erwähnst, dass SVN auf Linux schnell eingerichtet sei... :gruebel: :wall:
Da bekommt Dein oben zitierter Beitrag einen amüsanten und vor allem entlarvenden Touch. Aber sowas von. :mrgreen: :party:

Zitat:

Zitat von grl (Beitrag 1233268)

[...] Kein Kommentar - wenn einer sein Betriebskapital aus der Jurisdiktion des eigenen Landes bewegt ist das sein eigenes Vergnügen und auch sein eigenes Problem - Viel Vergnügen damit wenn's mal wo hakt... [...]

Ich habe mit keiner Zeile geschrieben, dass man zwangsweise zu einem nicht-inländischen Anbieter gehen solle, um die Vorteile von Cloud-basierten Lösungen in Anspruch zu nehmen. Es gibt auch professionelle Anbieter mit Sitz, Serverstandort und Gerichtsstand in Deutschland.

[Elvis]

Gitlab kann man bei sich installieren. Und sollte auch nix kosten.
Siehe Link in meinen ersten Beitrag.

Kiln kann man kaufen und dann selbst installieren. Es gibt sogar eine installierbare Version von GitHub.

Ein VCS-Server ohne Issue-Tracker ist IMO nur sehr begrenzt sinnvoll.

@GRL
SVN im Internet ist falsch.
Das ist so nervig und lahm, dass man bestenfalls einmal die Stunde einen Commit macht.
Wie will man denn so effektiv arbeiten?
Das ist eine so offensichtliche Gegenfrage, dass es an unterlassene Hilfeleistung grenzen würde, sie nicht zu stellen.

[Daniel]

Der Hinweis auf Alternativen ist ja grundsätzlich richtig. Und jeder Entwickler sollte von Zeit zu Zeit einen Blick über den Tellerrand werfen.
Dennoch gibt es Projektphasen, in denen eine Umstellung der gesamten Code-Verwaltung eher ungelegen kommt und man - aus welchem Grund auch immer - mit den bisherigen Werkzeugen fortfahren möchte.

Und die reine Installations-Zeit eines Werkzeuges ist i.A. irrelevant gegenüber der Zeit, die man für die Einarbeitung braucht oder die man bei der regulären Benutzung gewinnt oder verliert. Ich würde mich also nicht für ein System entscheiden, nur weil es schnell eingerichtet ist. Das war die Quellcode-Verwaltung mit ZIP-Files auch. ;-)

[Mavarik]

Also!

Die Installation auf meinem Windows Server hat keine Minute gedauert! Das SSL Zertifikat könnte ich noch installieren... Muss man aber nicht, da man beim 1. Zugriff das Zertifikat anhand des Fingerprints akzeptieren kann...

Fertig...

Und "Nein" Linux werde ich mit Sicherheit nicht nehmen, da ich mich damit überhaupt nicht auskenne und ich 3 Windows - Server im Rechenzentrum habe.

Und SVN...? ich bin die letzten 31 Jahre auch ohne SVN ausgekommen... Wenn ich einen Versionstand speichern wollte hab ich nen ZIP per Batch auf gerufen. Hat immer gereicht.

Aber:

Zitat:

Zitat von Daniel (Beitrag 1233321)

.. jeder Entwickler sollte von Zeit zu Zeit einen Blick über den Tellerrand werfen.

Daher habe ich das jetzt mal installiert und teste SVN.

Der Grund ist... Ich werde nach und nach unser Projekt auf Unicode umstellen. Bin gespannt wie gut das klappt, die Änderungen
der produktiven Version von Zeit zu Zeit in die auf Unicode geändert Version zu Mergen. (Das soll ja gehen, oder)

Ich werde berichten, wenn es jemanden interessiert.

Grüsse Mavarik

[Elvis]

Wenn du Versionierung testen/lernen willst, dann überspringe SVN.
Das benutzt man nur noch, weil man noch nicht zu Mercurial oder Git wechseln konnte.

Hier wird Git erklärt
https://www.atlassian.com/de/git/tut...t-basics#!init

Hier gibt es eine sinnvolle GUI dafür (die einzige, bei der man nicht ständig eine Konsole aufhaben muss)
http://www.sourcetreeapp.com

Vor allem kannst du da lokal versionieren, und ab & zu mit dem Server sync'en.
Gerade wenn du etwas umstellen willst, wäre SVN mit seinen dämlichen Merging ein Klotz am Bein.

Sorry, falls ich hier penetrant bin, aber heutzutage SVN lernen ist so sinnvoll wie die Win16 API zu lernen: Möglich, und man wird vllt. sogar Resultate sehen. Aber komplett unsinnig.

[Phoenix]

Da gebe ich Elvis 100% recht. Gerade wenn Du noch keine Versionierung eingsetzt hast, dann lass die Finger von SVN.
Das wäre das gleiche, wie wenn jemand, nur weil er in der Vergangenheit noch kein Auto hatte, sich heute noch einen Dampfbetriebenen Wagen holen würde.

Wenn Du auf der EKON bist, schau mal in meine Git session rein. Die ist bezeichnenderweise gleich hinter der SVN-Session eingeplant. Also erstmal lernt man Versionierung und dann, wie man das heute richtig macht ;-)

Gerade wenn Du hiervon redest:

Zitat:

Zitat von Mavarik

Der Grund ist... Ich werde nach und nach unser Projekt auf Unicode umstellen. Bin gespannt wie gut das klappt, die Änderungen
der produktiven Version von Zeit zu Zeit in die auf Unicode geändert Version zu Mergen. (Das soll ja gehen, oder)

Wenn Du nach jedem einzelnen Commit mergest, dann mag das gehen.
Wenn Du eine größere Zeitspanne abwartest, dann wirst Du Dich mit SVN zu tode mergen, da Du bei jedem merge einen riesen-Stapel an Konflikten zu bearbeiten haben wirst. Bei Git oder Mercurial/Hg sieht das anders aus. Die können einen echten 3-Way-merge fahren weil dort mehr Informationen über die Historie beider Zweige vorhanden sind und nicht nur diffs, sondern komplette Snapshots abgelegt werden.

Mit SVN tut sich heute niemand mehr einen gefallen. Du wirst feststellen, das das mit dem mergen nicht so klappt wie Du es Dir vorstellst und das läuft dann auf "Versionierung ist mist!" raus, obwohl eigentlich nur SVN seine Probleme offenbart.

Hau Dir Gitlab drauf (ist kostenlos), SourceTree als Client, und dann teste lieber gleich mit dem Mercedes, und nicht mit dem Trabi.

[Sherlock]

Jetzt muss ich allen SVN Gegnern beipflichten. Mavarik hat ja klar gesagt, daß er Versionierungsanfänger ist. Da sollte man nicht mit der Steinzeit anfangen, sondern mit "State of the Art". Und das ist nunmal Mercurial oder eben Git. ICh habe mich übrigens für Mercurial entschieden. Möge der Glaubenskrieg beginnen (SVN hat eh von Anfang an keine Chance gehabt).

Sherlock

[Phoenix]

Zitat:

Zitat von Sherlock (Beitrag 1233364)

ICh habe mich übrigens für Mercurial entschieden. Möge der Glaubenskrieg beginnen (SVN hat eh von Anfang an keine Chance gehabt).

Ich glaub so einen GLaubenskrieg wird das nie auslösen ;-)

Mercurial war von Anfang an etwas besser im Tooling (insb. auf Windows). Da hat Git aber inzwischen gut aufgeholt. Vom Featureset ist Git ein klein wenig besser, aber das sind Edge-Cases, die man im normalen Entwicklungsalltag normalerweise nicht spürt.

Mit Kiln gibt es inzwischen schon Server, die sogar beides können, und bei denen der eigentlich genutzte Client (ob jetzt Git oder Hg) auch vollkommen wurscht ist. Ud wenn man Kiln nicht kaufen mag, dann kann mit automatisierten Git/Hg-Bridges das auch selber hinbasteln.

Und wenn man z.B. Sourcetree als Client nutzt, kann man damit auch Git und Hg Repos verwenden.

[Lemmy]

Guten Morgen,

@Mavarik:

Zitat:

Zitat von Mavarik (Beitrag 1233331)

Der Grund ist... Ich werde nach und nach unser Projekt auf Unicode umstellen. Bin gespannt wie gut das klappt, die Änderungen
der produktiven Version von Zeit zu Zeit in die auf Unicode geändert Version zu Mergen. (Das soll ja gehen, oder)

auch wenn ich manchen Aussagen hier nicht zustimme: Lass in diesem (Anwendungs)Fall die Finger von svn. Das Merging in git/Mercirual ist besser.

Grüße

[sh17]

Hör auf Elvis :warn: :-D

[Mavarik]

Boh ey...

Jetzt hab ich mich erfolgreich Jahre lang darum gedrückt...
Jetzt hab ich das ganze Wochenende getestet um das Ganze zu verstehen...
Jetzt hab ich meine laufenden Projekte ALLE auf SVN umgestellt...
Jetzt soll ich schon wieder was neues machen...

Frei nach LW1-4 OK OK OK ich werde es mir anschauen...

Danke für Euer Feedback...

Mavarik

[Daniel]

Ja, das mag ärgerlich sein - aber umsonst war das WE gewiss nicht: Bei aller Schelte, die SVN einstecken muss, die Grundprinzipien von Versionsverwaltungen sind geblieben. Wenn Du also verinnerlicht hast, wie man mit Branches und derlei arbeitet, geht es bei einer Umstellung auf ein neues System lediglich um die Frage des "Wie geht das dort?" und nicht mehr um das "Was ist das überhaupt?".

[Mavarik]

Zitat:

Zitat von Daniel (Beitrag 1233435)

Ja, das mag ärgerlich sein - aber umsonst war das WE gewiss nicht: Bei aller Schelte, die SVN einstecken muss, die Grundprinzipien von Versionsverwaltungen sind geblieben. Wenn Du also verinnerlicht hast, wie man mit Branches und derlei arbeitet, geht es bei einer Umstellung auf ein neues System lediglich um die Frage des "Wie geht das dort?" und nicht mehr um das "Was ist das überhaupt?".

Gebe ich Dir Recht... Aber nur weil ich das NIE eingesetzt habe bedeutet es ja nicht, dass ich mich nicht zwischendurch mal damit beschäftigt haben... Hatte lokal auch schon einen SNV Server eingerichtet, aber nur für Datensicherung...

Aber was den nun:

Mercurial oder Git?

TortoiseHg oder SourceTree?

Mavarik

PS: Echt jetzt? Anleitung als Commandline tool?

[Mavarik]

Also... Nachdem ich mich ein bisschen eingelesen habe...

Ist ja gruselig, dass alle Anleitung für Commandozeilen sind.

Ob das Mergen so viel besser geht, bezweifele ich erst mal. Wenn zwei Leute die Parameter einer Procedure geändert haben,
kann keine Automatik das Mergen übernehmen.

Also wo soll der Vorteil zu SVN sein? Aus den Anleitungen kann ich da keinen sehen.

Und die lokale Kopie des Repository... Macht es eher schwerer den Überblick zu behalten, oder?
Nicht nur Commit sondern auch noch Push and Pull?

Und das GUI... Viele bunte Striche...

Da finde ich den Revisionsgraph von TortosieSVN übersichtlicher...

Also bisher kann mich das noch nicht überzeugen... Mal in der Praxis ein paar Tests machen...

Mavarik

[Daniel]

Wenn Du eine konkrete Stelle hast, an der in der einen Datei ein Zeichen "A" lautet und in einer anderen Datei "B", dann musst Du den Konflikt per Hand lösen.

Das Mergen wird aber oftmals dadurch lästig, weil die Versionsverwaltung die unterschiedlichen Stände nicht mehr nahtlos zusammenfügen kann und buchstäblich den Überblick verloren hat, welche Code-Abschnitte zusammengehören und wo sich Dinge einfügen ließen. Und genau da gibt es Systeme, die aufgrund der Informationsmenge, die sie vorhalten, zielsicherer ans Werk gehen können als SVN.

[Lemmy]

Zitat:

Zitat von Mavarik (Beitrag 1233472)

Ist ja gruselig, dass alle Anleitung für Commandozeilen sind.

daher finde ich die Kommandozeile "einfacher", weil du da zig Anleitungen findest

Zitat:

Zitat von Mavarik (Beitrag 1233472)

Ob das Mergen so viel besser geht, bezweifele ich erst mal. Wenn zwei Leute die Parameter einer Procedure geändert haben,
kann keine Automatik das Mergen übernehmen.

ist so. Ein Beispiel:


SVN Repository, 3 Entwickler. 2 Davon hatten die gleiche Datei in Bearbeitung (pas + dfm). Der eine ändert was in einer Prozedur, der andere löscht einen Button und die dazugehörige OnClick Methode. Der Entwickler, der den Button gelöscht hat macht als erster den Commit, dann kommt der zweite daher und wie auf magische Weise ist der Button + OnCLick Event wieder da (automatischer Merge). Passiert ist mir das nachweislich mind. 2x 2006-2008 - kann sich aktuell daher schon gebessert haben, wenn die das Merging aber nicht komplett umgestellt haben ist das immer noch ein Problem - da kann git einfach mehr.

[Mavarik]

Zitat:

Zitat von Daniel (Beitrag 1233473)

Und genau da gibt es Systeme, die aufgrund der Informationsmenge, die sie vorhalten, zielsicherer ans Werk gehen können als SVN.

OK.. Verstehe... Aber ist das nicht eher ein Fall für "Bejond Compare" als für eine Entscheidung wie Files in History gespeichert werden?

Beispiel:

Ich sichere jetzt meinen Versionstand (TAG) und zwei Leute arbeiten von diesem Punkt aus weiter.

Der eine programmiert neues Zeug und behebt Bugs der andere stellt um auf Unicode... (Ändert also nahezu jede Unit)
nach 3 Monaten soll ein Merge noch funktionieren? Oder muss man zwischen durch immer wieder aktualisieren?

Bei den reinen *.pas Dateien mag das ja noch passen, aber was ist mit den DFM Files? Was ist mit Komponenten, die je nach Brache andere Properties haben? Die also je nach Branch auch jeweils neu im Delphi installiert werden müssen...

Da gibt es noch viele viele viele viele offene Fragen... Nicht nur nach dem "richtigen" Tool, sondern auch einer konformen
Arbeitsweise...

Mavarik

[Mavarik]

Zitat:

Zitat von Lemmy (Beitrag 1233475)

SVN Repository, 3 Entwickler. 2 Davon hatten die gleiche Datei in Bearbeitung (pas + dfm). Der eine ändert was in einer Prozedur, der andere löscht einen Button und die dazugehörige OnClick Methode. Der Entwickler, der den Button gelöscht hat macht als erster den Commit, dann kommt der zweite daher und wie auf magische Weise ist der Button + OnCLick Event wieder da (automatischer Merge). Passiert ist mir das nachweislich mind. 2x 2006-2008 - kann sich aktuell daher schon gebessert haben, wenn die das Merging aber nicht komplett umgestellt haben ist das immer noch ein Problem - da kann git einfach mehr.

Aber hätten die 3 Entwickler nicht auf Ihrem eigenen Branch arbeiten müssen?

Mavarik

[mquadrat]

Der Vorteil der Pull-Requests liegt darin, dass du die genehmigen kannst. So kann dir niemand deine Sourcen "kaputt commiten". Insbesondere bei offenen Repos wichtig. Wir arbeiten aber aktuell auch "nur" mit SVN und es funktioniert größtenteils.

[Lemmy]

Zitat:

Zitat von Mavarik (Beitrag 1233478)

Aber hätten die 3 Entwickler nicht auf Ihrem eigenen Branch arbeiten müssen?

haben wir mal versucht, aber der Aufwand beim Mergen steigt dann - vor allem wäre auch da dieses Problem entstanden... zumindest wüsste ich nicht, wie das dieses Problem hätte lösen sollen....

Und obwohl ich sehr gerne SVN einsetze: Auf so was würde ich mich nicht einlassen. Wenn Du viel mit Branches arbeiten willst in Kombination mit mehreren Entwicklern, ganz klar git (oder Mercurial - da habe ich nur wenig praktische Erfahrung).

[Elvis]

Git & Mercurial (ab jetzt schreib' ich einfach DVCS) kennen alle Changesets aller Branches, die bei dem Merge zusammenkommen. Und zwar konsequent: Sie wissen für jede Zeile woher sie kam.

Wenn du also eine neue Methode einfügst, hast du die Zeilen drumrum nicht geändernt. Ein DVCS weiß das.
Wenn jetzt dein Kollege auch etwas hinzugefügt hat, wird dich das DVCS mit 95%-iger Wahrscheinlichkeit nichtmal nach einer Konfliktlösung fragen. Du hast dann einfach eine Datei mit beiden Methoden.

Wenn dein Kollege seine Änderung an einen anderen Kollegen weitergab und der etwas in der einen Methode änderte wird auch der 2. Kollege in keine Merge-Hölle geraten, wenn er das auf eure kombinierten Änderungen anwenden will.
Das DVCS weiß genau woher welche Zeile kam, und wenn es den Konflikt vllt nicht immer autom. lösen kann. Es kann dir und deinem Difftool schon sehr gut unter die Arme greifen.

Und nun zu den Commandline tutorials:
Die wollen dir das jeweilige DVCS zeigen. Das geht am besten wenn du genau weißt was passiert.
Das geht nicht mit einer GUI, die 30 Befehle hinter einem einzigen Button versteckt.
Du *musst* dein VCS nicht nur verstehen, sondern jederzeit vorhersehen was es tun wird (natürlich in den Grenzen der Features, die du bereits beherrschst).
Ansonsten bekommst du irgendwann Magengeschwüre von all der Unsicherheit.
Ein Commandline Tutorial bringt dich zeitlich viel schneller von 0 zu fundierten Grundlagen.
Da haben Vorurteile absolut keinen Platz. (Die haben sie in unserer Branche eh nicht)

btw: Eines sollte man aber tunlichst sein lassen: Große binary Files.
Die wandern sonst ständig über den Äther. Ein DVCS macht kein Diff für Änderungen von binary files. Jede Änderung führt zu eine kompletten Kopie.
Das ist cool für Bildchens, die alle 3 Jahre (oder nie) geändert werden. Aber packt da keinen großen und/oder veränderlichen Binärkrams rein(*Hust* Word/Excel/PDF-Files).

[Mavarik]

OK nochmal die Frage:

Mercurial oder Git?
TortoiseHg oder SourceTree?

Wo liegt der Unterschied zwischen Mercurial und Git?

Mavarik

[Meflin]

Zitat:

Zitat von Mavarik (Beitrag 1233583)

Mercurial oder Git?
TortoiseHg oder SourceTree?

Ob Mercurial oder Git ist reine Glaubensfrage und ich denke es macht keinen großen Unterschied. Ich nutze Git, hauptsächlich weils doch n Stück populärer ist und man daher auch mehr Ressourcen dafür findet (sei es Hilfe oder Hosting -> GitHub). Mercurial hat aber denke ich die etwas durchdachtere Befehlsstruktur, da ist Git ziemlicher Wildwuchs. TortoiseHg soll nicht so das wahre sein, persönlich habe ich es aber noch nicht ausprobiert (ich benutze git auf der Kommandozeile, ist auch kein Problem).

[Mavarik]

Zitat:

Zitat von Meflin (Beitrag 1233586)

Ob Mercurial oder Git ist reine Glaubensfrage und ich denke es macht keinen großen Unterschied. Ich nutze Git, hauptsächlich weils doch n Stück populärer ist und man daher auch mehr Ressourcen dafür findet (sei es Hilfe oder Hosting -> GitHub). Mercurial hat aber denke ich die etwas durchdachtere Befehlsstruktur, da ist Git ziemlicher Wildwuchs. TortoiseHg soll nicht so das wahre sein, persönlich habe ich es aber noch nicht ausprobiert (ich benutze git auf der Kommandozeile, ist auch kein Problem).

Also Kommandozeile geht mal gar nicht.

Die Git download/win Homepage ist tot

und Mercurial bringt eine Fehlermeldung und läßt sich nicht installieren...

Mavarik

[Meflin]

Zitat:

Zitat von Mavarik (Beitrag 1233588)

Also Kommandozeile geht mal gar nicht.

Wieso? Weil du nicht tippen kannst ;) ? Dachte ich auch lange, habe mich aber eines besseren belehrt... Aber jedem das seine.

Zitat:

Die Git download/win Homepage ist tot

http://git-scm.com/download/win geht (wieder)

[schlecki]

Also ich nutze SourceTree in Kombination mit der Konsole :) Ein Vorteil bei SourceTree ist auch, dass es ein embedded Git/Mercurial hat, so dass man gar nichts weiter installieren muss.

[Mavarik]

Zitat:

Zitat von Meflin (Beitrag 1233593)

Zitat:

Zitat von Mavarik (Beitrag 1233588)

Also Kommandozeile geht mal gar nicht.

Wieso? Weil du nicht tippen kannst ;) ? Dachte ich auch lange, habe mich aber eines besseren belehrt... Aber jedem das seine.

Nein... Aber 1. leben wir doch nicht mehr in den 80ern und 2. war das für mich einer der Gründe warum ich bisher nie SVN genutzt haben, weil ich keine vernünftige Oberfläche gefunden habe.

Tortoise war mir immer zu Abstract. Das einzige was ich da gut finde ist die grafische Übersicht.


http://git-scm.com/download/win geht (wieder)

Gibt es bei git keinen unterschied zwischen Server und lokalem Rechner?

Mavarik

PS.: Für die Server sind das ganz andere Seiten?

PPS: Update (2013-06-20): Due to unresolvable issues with OpenSSH on certain Windows installations, we are discontinuing WindowsGit maintenance

LOL