nicht angemeldet
Was sollte ein gutes Version Control S können?Welches nutzt ihr?
hi,
mich interessieren mal eure Meinungen zu VC-Systemen:
Was sollte ein gutes VCS können? Welche Eigenschaften sollte es haben? Wie sollte die Grundarchitektur sein? (Auch auf reinen PHP-Severn laufen können, schnell, dezentral, leicht erweiterbar ...)
Wofür benützt ihr VC-Systeme? (PHP-Code, Binärdaten ...)
Welche(s) VCS benutzt ihr? Welches System würdet ihr gerne benutzen? (bzr, hg, ng, git, svn, cvs, phpvc, darcs, asvcs ...)
Was fehlt euch an eurem System?
Wie gleicht ihr die Defizite eures VCS aus?
Sonst noch etwas?
Ich beantworte diese Umfrage dann gleich mal selbst.
Grüße von den Hunden.
2,0
-
hi,
Was sollte ein gutes VCS können? Welche Eigenschaften sollte es haben? Wie sollte die Grundarchitektur sein? (Auch auf reinen PHP-Severn laufen können, schnell, dezentral, leicht erweiterbar ...)
- alle Projektteilnehmer sollten gleichberechtigt sein (kein alleiniger zentraler Server)
- auch auf reinen PHP-Server laufen bzw. in PHP geschrieben sein - ist somit plattformunabhängig
- Möglichkeit, einfach Patches aus der Mitte der History (nicht nur den obersten) zu entfernen
- automatisches Bemerken von Umbennenungen, Verschiebungen im Baum
- leicht erweiterbar, flexibel
- Möglichkeit, Patches einmal zu schreiben und auf mehrere Branches anwenden zu können, d.h. man muss nicht jede Änderung in jedem Entwicklungszweig extra machen.
- offline arbeiten möglich
- ausgezeichnete Eclipse-Integration
- automatisches Update aller Repositorys der anderen Projektteilnehmer nach einem Commit
- Möglichkeit, nach Commits die Änderung automatisch auf über (S)FTP online zu stellen (für Webseiten)
(Geschwindigkeit ist mir nicht so wichtig)
Die restlichen Antworten folgen.
Grüße der Hunde.
2,0-
hi,
Wofür benützt ihr VC-Systeme?
- Kohana- bzw. PHP-Coding
- HTML, Graphiken etc.
Welche(s) VCS benutzt ihr?
Bazaar 2. Das ist das einzige, was auf meinem Server vorinstalliert ist - ist aber eh relativ gut.
Was fehlt euch an eurem System?
- keine gute Eclipse-Integration
- es ist nur eine linare History möglich, d.h. kein herausnehmen von Patches und eine Historyverzweigung nur unkomfortabel über Branches möglich.
- Keine Möglichkeit, Änderungen auf einmal bei mehreren Branches durchzuführen.
- Es sind nicht alle Projektteilnehmer gleichberechtigt.
Wie gleicht ihr die Defizite eures VCS aus?
Augen zu und durch.
Grüße der Hunde.
2,0 -
- [..]in PHP geschrieben sein - ist somit plattformunabhängig
*schüttel*
und was ist, wenn ich auf meinem Rechner kein PHP will? Dann läufts auf meiner Plattform schonmal nicht.Um noch auf die Frage einzugehen: hg auf der Kommandozeile
grüße
mechthild-
hi,
erstmal danke für die zwei Antworten.[...]wenn ich auf meinem Rechner kein PHP will[...] läufts [...] schonmal nicht.
Aber ob du einen PHP-Server aufsetzt (wobei ich mal glaube, dass so ziemlich jeder, der sich mit Webdesign/Webprogrammierung beschäftigt einen ZendCE oder was derartiges am laufen hat) und dort die Scripte draufspielst oder ein normales EXE-Version-Control-System (oder eben ein GNU/Linux- oder Mac/OSX-Äquivalent) installierst kommt doch ca. auf den gleichen Aufwand.
Sonst fällt mir eigentlich kein Grund ein, kein PHP zu installieren, ich meine, es bringt ja keine Nachteile mit sich, PHP installiert zu haben.lg.
-
Hallo,
[...]wenn ich auf meinem Rechner kein PHP will[...] läufts [...] schonmal nicht.
Aber ob du einen PHP-Server aufsetzt (wobei ich mal glaube, dass so ziemlich jeder, der sich mit Webdesign/Webprogrammierung beschäftigt einen ZendCE oder was derartiges am laufen hat) und dort die Scripte draufspielst oder ein normales EXE-Version-Control-System (oder eben ein GNU/Linux- oder Mac/OSX-Äquivalent) installierst kommt doch ca. auf den gleichen Aufwand.
Sonst fällt mir eigentlich kein Grund ein, kein PHP zu installieren, ich meine, es bringt ja keine Nachteile mit sich, PHP installiert zu haben.Ehrlich gesagt höre ich das Wort "PHP-Server" heute zum ersten Mal. Was genau meinst du damit?
"EXE-Version-Control-System" habe ich auch noch nie gehört.
Mercurial ist in Python geschrieben (übrigens wie Bazaar auch). Performancekritische Teile wie diff sind in C implementiert. Ob das bei Bazaar auch so ist, weiß ich nicht. Wäre aber nicht ungewöhnlich.
Eine Versionskontrolle durchweg in PHP geschrieben kenne ich nicht.
Mechthil
-
hi,
Ehrlich gesagt höre ich das Wort "PHP-Server" heute zum ersten Mal. Was genau meinst du damit?
Einen Server, der die Interpretation von PHP-Code unterstützt (durch ein Apache-Modul oder durch was auch immer).
"EXE-Version-Control-System" habe ich auch noch nie gehört.
Damit meinte ich ein Version-CS, welches in Form einer EXE-Datei vorliegt. Meist müssen EXE-Programme erst installiert werden. Aber auch Python-VCS muss man erst installieren (außer man hat den Interpreter bereits installiert).
Mercurial ist in Python geschrieben (übrigens wie Bazaar auch). Performancekritische Teile wie diff sind in C implementiert. Ob das bei Bazaar auch so ist, weiß ich nicht. Wäre aber nicht ungewöhnlich.
Ja, prinzipiell finde ich es auch gut in anderen Sprachen als PHP zu coden. Sie sind oft schöner und vor allem schneller. Nur ist der meiste angebotene Webspace nicht dafür ausgelegt, Nicht-PHP-Scripte auszuführen. Deshalb denke ich, dass für PHP-basierte Version-Control-Systeme mehr potentielle Orte für ein 24-h verfügbares Repo zur Verfügung stehen.
Eine Versionskontrolle durchweg in PHP geschrieben kenne ich nicht.
Es gibt zwar PHPVC und ähnliche, aber kein wirklich prominentes so wie bzr, hg, svn, git etc. mit wirklich aktiver Community (letztes Commit bei PHPVC 2009!).
lg.
-
Nur ist der meiste angebotene Webspace nicht dafür ausgelegt, Nicht-PHP-Scripte auszuführen. Deshalb denke ich, dass für PHP-basierte Version-Control-Systeme mehr potentielle Orte für ein 24-h verfügbares Repo zur Verfügung stehen.
Ein "normaler" Webspace ist generell nicht dafür ausgelegt, um ein VC zu hosten. Dafür gibt es speziallösungen, die entsprechend ausfallsicher sind. Ohne Backup usw. ist ein VC-Setup grob fahrlässig und IMO unbrauchbar.
Es gibt zwar PHPVC und ähnliche, aber kein wirklich prominentes so wie bzr, hg, svn, git etc. mit wirklich aktiver Community (letztes Commit bei PHPVC 2009!).
Tja, dann überleg dir mal, woran das liegen könnte. Evtl. daran, dass der Ansatz schlichtweg unbrauchbar ist im produktiven Einsatz?
Ein Server mit der nötige Redundanz eines VC bietet auch die Möglichkeit, ein "richtiges" VC zu installieren.
-
-
-
-
Moin,
Gabs das Thema nicht neulich erst? Naja, sei's drum:Was sollte ein gutes VCS können? Welche Eigenschaften sollte es haben?
- Passable GUI, um auch Changes an vielen Dateien im Auge zu behalten
- Branches
- Tagging
- Brauchbare Methoden/Tools für Merges & Konflikt-Auflösung
- Möglichkeiten, eigene Aktionen mit Checkin/Checkout usw. zu verknüpfen
("Hooks")
Wie sollte die Grundarchitektur sein? (Auch auf reinen PHP-Severn laufen können, schnell, dezentral, leicht erweiterbar ...)
- Zugriff auch über Webserver (Apache) o.ä. wäre schön
Wofür benützt ihr VC-Systeme? (PHP-Code, Binärdaten ...)
- Source-Code (HTML/CSS/JS/AS/Perl/Java/...)
- Binärdateien, sofern Teil des Codes (Bilder in HTML-Seiten o.ä.)
- Dokumente, sofern viele Benutzer häufig Änderungen durchführen müssen
Welche(s) VCS benutzt ihr?
Daheim: SVN
Arbeit: SVN
Kunden: CVS/Alfresco (wenn man das im weitesten Sinne als VCS bezeichnen kann)Welches System würdet ihr gerne benutzen? (bzr, hg, ng, git, svn, cvs, phpvc, darcs, asvcs ...)
GIT, hauptsächlich weil so viele davon schwärmen und ich neugierig bin :)
SVN ist aber schon ganz ok.Was fehlt euch an eurem System?
SVN:
- ein vernünftiger GNOME oder KDE-Client wäre schön
- Mergen über mehrere Branches hinweg ist bisweilen etwas umständlich
Sonst bin ich ganz zufrieden.Wie gleicht ihr die Defizite eures VCS aus?
Automatisierte Shell-Skripte
Viele Grüße,
Jörg-
Was fehlt euch an eurem System?
SVN:- ein vernünftiger GNOME oder KDE-Client wäre schön
Was gefällt dir an rapitsvn und kdesvn nicht? Wenns webbasiert sein soll, nimm trac, da hast du gleich ein Wiki mit dabei.
-
Moin,
Was gefällt dir an rapitsvn und kdesvn nicht? Wenns webbasiert sein soll, nimm trac, da hast du gleich ein Wiki mit dabei.
rapitsvn kenn ich nicht, muss ich vielleicht mal probieren.
kdesvn nutze ich gegenwärtig, finde es aber ziemlich unperformant, wenn man große working copies verwaltet, wirklich gut integriert in KDE/Dolphin ist es IMO auch nicht und die Usability ist auch eher mäßig.->Wenn man es mit TortoiseSVN unter Windows vergleicht, ist es keine echte Alternative, sondern eben nur ein "weils unter Linux nix anderes gibt".
Viele Grüße,
Jörg