VCS für dämliche Entwickler ;-)

[gmc616]

Das sich aus diesem Thread 2 Netzwerkkarten, die schnellere Verbindung nutzen ein neues Thema entwickelt hat, setze ich diese Thema hier fort:

Zitat:

Zitat von BUG (Beitrag 1067548)

Zitat:

Zitat von gmc616 (Beitrag 1067541)

Kurze Antwort: Ich bin zu dämlich ein VCS zu installieren.

Tipp: TurtoiseSVN macht auch dämliche Entwickler glücklich :mrgreen: [...]

Zitat:

Zitat von s.h.a.r.k (Beitrag 1067549)

Alternativ: msysgit mit TortoiseGit. Wenn du kein eigenes Git-Repo anlegen willst, dann kannst auch ProjectLocker nutzen. Dort sind auch closed Projects erlaubt ;)

Ich möchte eine VCS, die in meinem Netz (meinem Server) läuft. Da bin ich 'n bissl eigen, ich möchte nicht, das meinen Sourcen im Web liegen.

Was nutzt ihr um eure Projekt zu verwalten?
Kennt ihr Howto's, die auch funktionieren?
Als Basis nutze ich Windows. Ich habe kein Interesse an gswin, oder anderen Linux/Unix-Emu's

Meines Wissens ist SubVersion veraltet und der neue/aktuelle Trend geht zu Gilt, was auch immer der (technische) Unterschied ist.

Was und wie nutzt ihr?

[Assarbad]

Bazaar, Git, Mercurial. Alle drei haben auch eine Windows GUI, dank entsprechendem Tortoise-Projekt ;)

[himitsu]

Man kann sich auch Delphi XE kaufen und hat das direkt eingebaut. :stupid:

[gmc616]

Zitat:

Zitat von himitsu (Beitrag 1067564)

Man kann sich auch Delphi XE kaufen und hat das direkt eingebaut. :stupid:

Was? Einen TurtoiseSVN-Client? Und mit welchen Server arbeitet der?

Läßt sich der TurtoiseSVN-Client nicht auch in Delphi 2009 bzw 2006 IDE einbauen? Ich dachte da mal was gelesen zu haben.

[Sir Rufo]

Um nochmal auf den Ausgangspunkt zu kommen bzgl. NAS und einem VCS ...

Was für ein NAS hast du denn im Betrieb?

Auf einem NAS von QNAP kannst du ein SVN installieren
Allerdings geht das bei einigen anderen bestimmt auch (auf jeden Fall bei den besseren ;) )

[s.h.a.r.k]

Naja, bei Git brauchst ja keinen Server an sich. Da reicht es ja ein Repo auf dem Server anzulegen und man kann davon dann ja auschecken.

[Sir Rufo]

Das geht mit TortoisesVN ja auch ... der Vorteil bei einem echten Server ist ja die Benutzerverwaltung und der Zugriff über ein eigenes Netzwerkprotokoll (wenn man auch aus dem Internet drauf zugreifen möchte und einem der SMB-Zugriff via Internet zu unsicher erscheint :mrgreen: )

Als Hauslösung reicht definitiv die Lösung ohne Server, da bin ich ganz bei dir ;)

[gmc616]

Zitat:

Zitat von Sir Rufo (Beitrag 1067567)

Um nochmal auf den Ausgangspunkt zu kommen bzgl. NAS und einem VCS ...

Was für ein NAS hast du denn im Betrieb?

Eine Buffalo Terastation 2. Dafür gibt es ne gehackte Firmaware, die letztendlich auch nur ein Linux ist. Per Telnet hat man dann kompletten Zugriff auf das System. Ein SVN zu installieren sollte (für nicht dämliche Entwickler) kein Problem sein. Das ganze ist mir aber zu unredundant, da ich dann immer von dieser NAS abhängig wäre. Und wer weiß was die Zeit bringt!

Da ich ausschließlich für Windows entwickle, hab ich für mich das Thema Linux abhakt. Also hab ich zZ. nur Windows im Einsatz. Daher suche ich eigentlich eine VCS-"KlickiBunti"-Installation.

Die VCS darf von mir aus auch Geld kosten, aber den Preis für Borland StarTeam z.B., einer Software, die ich im Prinzip nach meinen Vorstellung und Anforderungen in wenigen Monaten selbst schreiben könnte, halt ich für übertrieben.

All zumal ich zukünftig Anwendungen für Windows Mobile bzw Windows Phone entwickeln werde/soll, und ich mit Emba in dieser Richtung keine Zukunft sehen (geschweige denn 64Bit Anwendung) werde ich eher über Kurz als bis Lang auf MS Visual Studio übergehen.
Und natürlich will ich meine Delphi-Anwendungen genauso wie meine anderen Projekte (VS, Delphi, PHP, usw. ) per VCS verwalten können wollen.

[Sir Rufo]

Wenn du einen EasyToInstall-VCS-Server suchst, dann nimm VisualSVN
Einfacher geht es da nicht mehr ... alles KlickiBunti

Als Client TortoiseSVN

Die Frage ist aber, ob du wirklich einen Server brauchst.

BTW: Ein SVN-Server unter Linux, Windows oder whatever unterscheidet sich nur durch die Binaries.
Die zugrundeliegenden Daten mit dem ganzen versionierten Geraffel sind bei allen gleich und können von a nach b verschoben/umkopiert werden.
Selbst die Daten, die man mit TortoiseSVN erzeugt (Arbeiten ohne Server) kann man irgendwann auch direkt einem Server unterschieben und ab da geht es per Server weiter.

Wenn man also jetzt mit einem SVN-Server unter Linux anfängt und übermorgen mit einem Windows-SVN-Server und nächsten Monat gar keinen Server mehr ... ist völlig Latte ;)

Und eine SVN-Server (wie auch Git und die anderen) verarbeiten alles an Dateien ... am besten allerdings Text-Dateien ... somit also egal, was, wie und womit ich entwickle ... dem CVS ist das egal (auf Borland Star-Team kann man getrost verzichten)

[s.h.a.r.k]

Dann sind die Tortoise-Produkte genau das richtige für dich! Denn damit bekommst du ein einfach zu nutzendes Interface, direkt in das Popup-Menü des Explorers. Anbei mal ein Screenshot. Und nein, es ist nicht so kompliziert wie es aussieht ;)

Auf welchem NAS läuft denn kein Linux? Soweit ich das gesehen ist ist auf 99% auf Linux installiert -- mal mehr, mal weniger angepasst. Und wenn du einen Telnet-Zugriff hast, dann würde ich mir SSH installieren. Ich traue bei sowas nicht mal meinem eigenen Netz :mrgreen:

Hab leider noch kein Git unter Linux installiert, also als "Server"-Software, sonst könnte ich da evtl. Hilfe anbieten. SVN war damals nicht so toll... Hatte es als Apache-Modul mal probiert, aber es gibt eben ein paar Hürden zu nehmen. Das will ich nicht nochmal machen :) Vielleicht gibts ja passende Pakete für das installierte Linux?!

PS: Geld für ein VCS brauchst eigentlich keines ausgeben. Gibts ausreichend gute, die kostenlos sind. Einarbeiten muss man sich immer etwas.

Für SVN kenne ich eine Server-Software für Windows, die leicht zu bedienen ist: VisualSVN.

[Assarbad]

Zitat:

Zitat von Sir Rufo (Beitrag 1067575)

Und eine SVN-Server (wie auch Git und die anderen) verarbeiten alles an Dateien ... am besten allerdings Text-Dateien ... somit also egal, was, wie und womit ich entwickle ... dem CVS ist das egal (auf Borland Star-Team kann man getrost verzichten)

SVN ist da zwar besser, aber immernoch nicht so toll. So sehr ich auch die "CVS keywords" (ursprünglich nur CVS aber in SVN verfügbar) an sich schätze, ein VCS hat gefälligst nie an meinen Daten rumzufummeln sondern die originalgetreu zu speichern und wieder rauszurücken. Weder SVN noch CVS halten sich da dran. Wenn ich schon das Rumgefummel mit den Zeilenumbrüchen sehe, kommt mir das Brechen ...

Bei SVN wird es auch sehr schnell sehr langsam. Wer einmal mehr als ein Release von Boost verwaltet hat und ohnehin schon ein großes Repo mit mehreren hundert Dateien und tausenden Revision hat, der wird die Geschwindigkeit von SVN nicht gerade schätzen. Einer der Gründe ist übrigens, daß in der Working Copy (daran wird wohl gearbeitet) immer diese .svn-Verzeichnisse mit Metadaten herumliegen. Und das nicht wie bei Git oder Mercurial nur auf der obersten Ebene sondern in jedem einzelnen Verzeichnis ...

Zitat:

Zitat von s.h.a.r.k (Beitrag 1067577)

Hab leider noch kein Git unter Linux installiert, also als "Server"-Software, sonst könnte ich da evtl. Hilfe anbieten. SVN war damals nicht so toll... Hatte es als Apache-Modul mal probiert, aber es gibt eben ein paar Hürden zu nehmen. Das will ich nicht nochmal machen :) Vielleicht gibts ja passende Pakete für das installierte Linux?!

Unter Debian und Ubuntu kinderleicht und selbst auf anderen Distros oder BSDs kein größeres Problem.

Das mit dem Apachemodul ist ein wenig ... nunja ... unglücklich. Denn wie auch Git oder Mercurial bietet SVN schon von Haus aus einen "serve"-Befehl, nämlich diesen. Nichts anderes passiert ja, wenn man einen SSH-Tunnel benutzt. Dort wird ja auch auf der entfernten Seite eine Instanz von svnserve gestartet um für den aktuellen Tunnel das Repo bereitzustellen. Ich denke also daß eine Erwähnung des Apachemoduls (mod_dav_svn, nehme ich mal an) nicht gerechtfertigt ist, da es beim Anbieten von Git und Mercurial über Apache ebenfalls Hürden gibt, die aber dann anderer Art sind (Proxy via mod_rewrite).

Bzgl. SVN via SSH-Tunnel kann man ja auch anderweitige Benutzung des Kontos direkt verbieten indem man das hier benutzt:

Code:

command="svnserve -t --tunnel-user=BenutzerName",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-dss AAA ...

[s.h.a.r.k]

Das mit diesen Unmengen an .svn-Ordnern kann ich auch irgendwie aus Design-Gründen nicht verstehen. Mag evtl. ganz nett sein, nur ein Pfad aus- und einchecken zu können, aber sonst sehe ich da keinen Sinn dahinter. Wobei das sehr auf Kosten des Nutzens und auch Geschwindigkeit geht. Allein schon das war ein Grund für mich auf Git umzusteigen. Da brauch ich mich auch nicht um irgendwelche versteckten Unterordner beim Upload auf meinen FTP scheren... Oder muss zuvor jedes mal noch exportieren.

[Lemmy]

Hi,

mal eine Frage an die Mercurial-Nutzer: Stimmt es wirklich dass Mercurial die Änderungen in unterschiedlichen Zweigen vernünftig mergen kann? Beispiel: Zweig 1 löscht einen Teil einer Methode bzw. die komplette Methode. Im Zweig 2 wird diese beibehalten. Beim Merge von 1 und 2 ist diese verflixte Methode dann auf einmal wieder da.

So wie ich die Tutorials von M. lese sollte es das können, habe es bei meinem kleinen Test aber nicht hinbekommen...

Grüße

[Assarbad]

Zitat:

Zitat von Lemmy (Beitrag 1067798)

mal eine Frage an die Mercurial-Nutzer: Stimmt es wirklich dass Mercurial die Änderungen in unterschiedlichen Zweigen vernünftig mergen kann? Beispiel: Zweig 1 löscht einen Teil einer Methode bzw. die komplette Methode. Im Zweig 2 wird diese beibehalten. Beim Merge von 1 und 2 ist diese verflixte Methode dann auf einmal wieder da.

Eigentlich schon. Aber Branches in Mercurial sind ohnehin etwas gewöhnungsbedürftig. Ich bevorzuge dafür einen lokalen Klon des Repos in dem ich wie in einer Branch weiterarbeitet und dann von upstream immer meine Änderungen pulle. Wenn ich dann bspw. ein Feature fertighabe, kann ich dann bequem alles pushen und das "entfernte" Repo hat auch die volle Versionshistorie.

Zitat:

Zitat von Lemmy (Beitrag 1067798)

So wie ich die Tutorials von M. lese sollte es das können, habe es bei meinem kleinen Test aber nicht hinbekommen...

Von welcher in welche Richtung? Kommandozeile oder TortoiseHg? Letzteres hat mir bei der Handhabung von Branches immer nur Kummer bereitet.

[s.h.a.r.k]

@Assarbad: Du schenist dich ja mit Mercurial auszukennen. Kennst du einen (guten) Artikel der die Unterschiede zwischen Git und Mercurial herausarbeitet?!

[Assarbad]

Zitat:

Zitat von s.h.a.r.k (Beitrag 1067808)

@Assarbad: Du schenist dich ja mit Mercurial auszukennen. Kennst du einen (guten) Artikel der die Unterschiede zwischen Git und Mercurial herausarbeitet?!

Keinen aktuellen, nein. Die älteren sind aber nicht mehr sinnvoll, weil sich beide eher annähern. Ein Beispiel wäre rebase, welches es in Mercurial vor einiger Zeit noch nicht gab.

[Lemmy]

@shark: Hier wird git kurz erwähnt.... http://hgbook.red-bean.com/read/how-...-get-here.html ALlerdings findet der Schreiber Mercurial toll ;-)

@Asserbad: Danke für den Hinweis. Ich habe die TortoiseHg verwendet, weil ich das unter SVN relativ gelungen finde.

[s.h.a.r.k]

Danke Lemmy! Ach, dass der Mercurial toll findet, überlebe ich dann wohl auch noch :mrgreen: Ist halt -- wie so oft -- eine Glaubensfrage, was man denn lieber nutzt. So wie neulich der Thread mit diesen verschiedenen Merge-Tools. Aber schön, wenn man wenigstens eine Wahl hat :)

[Assarbad]

Zitat:

Zitat von s.h.a.r.k (Beitrag 1067885)

Danke Lemmy! Ach, dass der Mercurial toll findet, überlebe ich dann wohl auch noch :mrgreen: Ist halt -- wie so oft -- eine Glaubensfrage, was man denn lieber nutzt.

Ich finde auch, daß es reine Geschmackssache ist. Wenn du Git derzeit benutzt und damit zufrieden bist, dann ist es doch nicht nötig zu wechseln. Git und Mercurial sind funktional sehr nah beieinander. Wenn du allerdings CVS benutzen würdest, könnte ich mich zu einer "Bekehrung" verleiten lassen :zwinker:

[s.h.a.r.k]

Ist aber immer interessant sich Alternativen anzuschauen und wie diese Arbeiten bzw. eben die Konzepte dahinter. Meinst du nicht mal, dass der Code von Git ein ziemliches "Gefrickel" sei?! Habe mir den noch nie angeschaut, ebenso von anderen OS-Systemen. Wobei ich dies bzgl eine Argumentation von Torvalds kenne, in der er eben gegen C++ mit OOP ist und für reines C stimmt -- soweit ich das noch weiß. Und Git wurde hier eben als Beispiel angeführt. Naja, das führt jetzt aber insgesamt wohl etwas in die falsche Richtung :)

[Assarbad]

Hier mal eine etwas einseitige, aber dennoch interessante Seite: http://de.whygitisbetterthanx.com/

[himitsu]

Zitat:

Git ist Schnell
...
Ein anderer Grund ist, dass Git in C geschrieben ist ...

sehr interessante Schlußfolgerung :shock:

[Assarbad]

Zitat:

Zitat von himitsu (Beitrag 1068866)

Zitat:

Git ist Schnell
...
Ein anderer Grund ist, dass Git in C geschrieben ist ...

sehr interessante Schlußfolgerung :shock:

In der Tat :lol:

Wäre für mich auch eher ein Nachteil. Denn der Flaschenhals ist nicht die Ausführungsgeschwindigkeit, sondern Transfer übers Netz und Plattenzugriffe. Aber wie gesagt, auch wenn es einseitig ist, es gibt auch Anhaltspunkte nach was man gucken kann. Und allemal sollte es nachweisen, daß die DVCS alle besser sind als alte VCS (CVS, Subversion, altes SourceSafe).