Stefan B. schrieb: > Falls jemand Interesse an Versionskontrollsystemen hat, kann ich dieses > frei verfügbare Online Buch http://www.ericsink.com/vcbe/index.html > empfehlen. Ich habe mal die ersten paar Seiten gelesen und das vorher erwartete bestätigte sich: Ich sehe keine Lösung für den typischen kleinkriminellen Hobbyprogrammierer, also Leute die: 1. nicht wissen, ob die erarbeitete (Teil-)Lösung sich bewähren wird 2. wenige KB Code schreiben 3. abundzu dran weiterarbeiten (und daher viel zwischenzeitlich vergessen) 4. mehrere Handlungsstränge aus der Not heraus gebähren. Wie manage ich damit ein Projekt, das in drei verschiedene Codes zerfallen ist, weil die populistisch 'besser' sind, die dann aber nach jeweils mehreren Subversionen wieder zusammengeführt werden sollen? Bislang mache ich das mit primitiven ASCII-Dateien, in denen die Änderungen reingeschrieben wurden inkl. Datum. Darafhin habe ich dann mehrere mehroderweniger komplette Projekte auf dem PC. Von ZeitzuZeit sortiere ich dann aus, führe zusammen durch Code kopieren, usw. Nicht professionell, aber vermutlich arbeiten die allermeisten im hardwareorientierten Bereich so. Daß man mit dieser Methodik ein Win12 nicht generieren kann, ist klar. Die Sache wird dadurch etwas einfacher, daß es immer nur einen Programmierer gibt. Im Studium wurde topdown-Entwicklung propagiert. Das war mir schon damals klar, daß das Blödsinn ist, denn in den allermeisten Projekten ist überhaupt nicht klar, ob man die entstehenden Teilschritte überhaupt sinnvoll aufgeteilt hat. Daher arbeiten sicherlich die meisten Leute in diesem Bereich nach von unten = Teillösungen, die dann auch testbar sind! nach_ _oben hin zum optionalen GUI. Für topdown müßte man extra Testcases realisieren, die logischerweise rein virtuell sind und damit enorm fehlerträchtig (abgesehen vom zeitlichen Aufwand Code fürs Nirwarna zu kreieren). FORTH basiert ja als ganze Programmiersprache auf diesem Ansatz. Was sind eure Meinungen? Daraufhin schrieben einzelne Teilnehmer: Re: Versionsmanagement Autor: A. B. (funky) Datum: 26.06.2012 23:08 ------------------------------------------------------------------------ -------- all das kannste damit ja genau so weitermachen wenn du unbedingt willst. dann wird halt immer ein neuer branch erzeugt. > 3.abundzu dran weiterarbeiten (und daher viel zwischenzeitlich > vergessen) da man sich den log der bisherigen änderungen anschauen kann, ist das für vergessliche ideal. die manuelle Arbeit des mergens wird nunmal immer bleiben...egal wie man sein Projekt nun pflegt...mit einer Versionierung oder indem man Ordner samt Files hin&her kopiert Neuer Versionierungssysteme als SVN sollen das ja besser können, wobei ich es noch nicht ausprobiert habe. Ich kann mir auch noch nicht vorstellen, wie man sowas gross automatisieren soll. Wenn ich zwei unterschiedliche Funktionen mit gleichem Namen habe, muss doch ein Mensch draufschauen und sagen was übernommen werden soll?! Autor: Abdul K. (ehydra) Datum: 27.06.2012 02:09 ------------------------------------------------------------------------ -------- Ich bin gespannt, ob sich in den letzten 15 Jahren eine verbesserte Methodik breit machte. Ich kann mich erinnern, damals auf einmal eine Validierung von größeren C-Projekten durchführen zu müssen (50KByte Binärcode), weil die Auftraggeber das für irgendwelche Zulassungen benötigten. Es war nicht mein Task die Software zu schreiben und zu validieren :-) Ich möchte natürlich nicht nur C-Fragmente, sondern z.B. auch Schaltungen in LTspice so behandeln. Geht das auch? Wenn eine neue Methodik, dann soll sie möglichst universell sein, wie z.B. das Datei- und Ordner-System im Filesystem. Was man für alles mögliche benutzen kann. Vielleicht mache ich ja was grundlegend umständlich und bin nie auf eine solidere Idee gestoßen? Ich denke das obige Argument "da muß ja ein Mensch nochmals drüber schauen und entscheiden, WAS nun übernommen wird und was nicht" bleibt? Z.B. zwei Funktionen, die unterschiedliche Dinge tun, aber auf ein zufällig gemeinsames Special Function-Register in einem Controller zugreifen, um ihre Funktion zu realisieren. Autor: Jürgen Liegner (jliegner) Datum: 27.06.2012 07:49 ------------------------------------------------------------------------ -------- Es ist wie immer. Es kommt darauf an was man von dem System erwartet. Bei uns arbeiten ca. 10 Leute seit ca. 10-12 Jahren mit cvs. Dabei geht es nur darum Änderungen an den gleichen Dateien von mehreren Leuten automatisch abgeglichen zu kriegen. Das ganze andere Geraffel wie verschiedene Entwicklungszweige u.s.w haben wir nie benutzt und werden es auch nicht. Wenn ein Release freigegeben wird bleibt es auf dem Stand stehen, wird kopiert für das nächste Release und neu eingecheckt. Mag sein das die neueren Systeme viel mehr können, das muss dann aber auch von allen sicher beherrscht werden. Das kostet auch Zeit und Geld. Deshalb ist für mich manchmal weniger mehr. Auch wenn man privat auf verschiedenen Rechnern was macht ist cvs für mich völlig ausreichend. Abdul: Das waren die Beiträge. Mich würde nun trotzdem das ganze Thema sehr abstrakt interessieren. Welche Lösungen habt ihr erarbeitet, um eure Versionskontrolle eurer Arbeit zu organisieren?
:
Verschoben durch Moderator
Hab da n etwas schnoddriges System für mich entwickelt. Mache einfach jeden Tag bevor ich am Projekt weiter arbeite ne Kopie des ganzen Projektordners und mich erst dann frisch ans Werk. Wenn dann im Programmverhalten irgendwelche unerklärliche Verhaltensweisen auftauchen lass ich "Beyond Compare" drüber laufen, dann seh ich alle Veränderungen des Tages und kann den Fehler leichter eingrenzen. Funktioniert auch wunderbar zwischen 2 lauffähigen Versionen des Programmcodes.
Abdul K. schrieb: > Welche Lösungen habt ihr erarbeitet, um eure Versionskontrolle eurer > Arbeit zu organisieren? Ich nehme größtenteils mittlerweile SVN. CVS hat doch hie und da ein paar Ecken und Kanten, die bei SVN verschwunden sind. Ja, manuell mergen geht nicht anders, wenn sich irgendwas weit auseinander entwickelt hat. Das Einzige, was dagegen hilft ist, Dinge nicht zu weit auseinanderdriften zu lassen. ;-) Funktion foo() sollte also nicht in einem Zweig was komplett anderes tun als im anderen, sodass man beim späteren Merge manuell entscheiden muss, was die nun gemeinsame Funktion foo() denn eigentlich tun soll. git habe ich für mich verworfen, weil es sowas von "wir machen vorsätzlich alles ganz anders als bisher" ist, dass mich das nervt. Mercurial benutze ich teilweise, einerseits weil es Projekte gibt, die sich dafür entschieden haben und an denen ich mitarbeite. Wirklich einfacher ist das Mergen bei Konflikten dort auch nicht. (Wie auch?) Zuweilen nehme ich Mercurial noch als "Overlay" über irgendwas anderes, was bereits versioniert ist (bspw. mit SVN). Ich habe dann also eine SVN working copy (ausgecheckter Stand) da liegen, mache darauf ein "hg init" und füge alle wesentlichen Dateien diesem so entstandenen Mercurial-Repo zu. Dann kann ich Änderungen im Mercurial für mich selbst in "kleinen Häppchen" einchecken, kann bei auftretenden Fehlern schnell ein Rollback machen usw. usf. Wenn die dergestalt gezimmerte größere Änderung dann in Sack und Tüten ist, wird alles als ein einziger Commit ins SVN zurückgeschrieben. (Die 25000 lokalen commit messages interessieren dann nicht mehr, dort ist nur noch das "big picture" von Interesse). Danach fliegt das Mercurial-Repo mit rm -rf .hg wieder weg. Letztlich habe ich aber immer irgendwo eine Stelle, die für ein bestimmtes Projekt autoritativ ist. Damit hat eine verteilte Versionsverwaltung für mich nur sehr begrenzt Sinn. (Ja, ich weiß, andere werden jetzt protestieren. ;-) Ein Backup des VCS-Repos sollte natürlich existieren, aber es ist dafür ziemlich wurscht, ob dieses Backup explizit (bspw. per svn dump) erzeugt worden ist oder als Clone des autoritativen Repositories.
ich versteh nur Bahnhof aber: ich verwende SVN tortoiseSVN das funktioniert mit Server, oder auch lokal beliebige viele Branch ist auch kein problem Merge ist eher "umständlich" mit + SVNMerge wenn man es mal verstanden hat, kein Problem, und auch kein Aufwand Projektgröße spielt da keine Rolle, wer "neu" beginnt, sollte sich aber vermutlich eher bei GIT umschauen (da ist das Merge besser gelöst?!) kenn ich aber persönlich nicht >Wie manage ich damit ein Projekt, gar nicht, mir Projektmanagement hat das nix zu tun..
Jörg Wunsch schrieb: > git habe ich für mich verworfen, weil es sowas von "wir machen > vorsätzlich alles ganz anders als bisher" ist, dass mich das nervt. git wurde nicht entwickelt um ein weiteres Versionskontrollsystem zu erfinden, sondern um Linux effizient zu weiterzuentwickeln. > Mercurial benutze ich teilweise, einerseits weil es Projekte gibt, die > sich dafür entschieden haben und an denen ich mitarbeite. Wirklich > einfacher ist das Mergen bei Konflikten dort auch nicht. (Wie auch?) > Zuweilen nehme ich Mercurial noch als "Overlay" über irgendwas > anderes, was bereits versioniert ist (bspw. mit SVN). Ich habe dann > also eine SVN working copy (ausgecheckter Stand) da liegen, mache > darauf ein "hg init" und füge alle wesentlichen Dateien diesem so > entstandenen Mercurial-Repo zu. Dann kann ich Änderungen im Mercurial > für mich selbst in "kleinen Häppchen" einchecken, kann bei > auftretenden Fehlern schnell ein Rollback machen usw. usf. Wenn die > dergestalt gezimmerte größere Änderung dann in Sack und Tüten ist, > wird alles als ein einziger Commit ins SVN zurückgeschrieben. (Die > 25000 lokalen commit messages interessieren dann nicht mehr, dort ist > nur noch das "big picture" von Interesse). Danach fliegt das > Mercurial-Repo mit rm -rf .hg wieder weg. Genau diesen Workflow führe auch ich durch, nur dass ich git benutze. git kann die eigene History umschreiben, sodass ich erst lokal alles kleinschrittig zusammenbasteln kann und dann bevor ich meine Änderungen publiziere kann ich die 10-100 commits in einen einzigen Commit, mit sinnvoller commit message umschreiben. Da ich gezwungenermassen auch mit SVN arbeiten muss, da die autoritative Stelle SVN nutzt, benutze ich git-svn zum exportieren, dh ich habe lokal ein git repository, welches in der Lage ist mit dem SVN Server reden zu können und meine Stände als svn commits in das System einpflegen kann. Jörg Wunsch schrieb: > Letztlich habe ich aber immer irgendwo eine Stelle, die für ein > bestimmtes Projekt autoritativ ist. Damit hat eine verteilte > Versionsverwaltung für mich nur sehr begrenzt Sinn. (Ja, ich weiß, > andere werden jetzt protestieren. ;-) Ein Backup des VCS-Repos > sollte natürlich existieren, aber es ist dafür ziemlich wurscht, ob > dieses Backup explizit (bspw. per svn dump) erzeugt worden ist oder > als Clone des autoritativen Repositories. Ein Versionskontrollsystem ist natürlich kein Backup. Die verteilten Versionskontrollsystem lassen natürlich auch work flows zu, die zentralistisch aufgebaut sind, mit angeschlossenem Backup ;) Man kann in den verteilten Versionskontrollsystemen auch so etwas wie ein 'local caching' sehen, also das vorhalten der relevanten Daten an den Stellen, die schnell zugänglich sind. Da bei einer Versionskontrolle aber nicht nur der aktuelle (meist nicht funktionierende :P ) Stand relevant ist, sondern die Frage, warum bestimmte Codestellen vor 3 Jahren genauso verbrochen wurden, muss natürlich die gesamte History mitgecached werden. PS: Entschuldigt mein grässliches Denglisch, ich habe über deutsche Umschreibungen nachgedacht, viele hörten sich nicht kompatibel an.
Abdul K. schrieb: > Ich habe mal die ersten paar Seiten gelesen und das vorher erwartete > bestätigte sich: > Ich sehe keine Lösung für den typischen kleinkriminellen > Hobbyprogrammierer, also Leute die: Gerade hier punkten die verteilten Versionskontrollsysteme:
1 | hg init |
alternativ auch
1 | git init |
ist weitaus einfacher als ein SVN/CVS Server aufzusetzen. (Pauschalbehauptung, ich habe noch nie einen solchen Server aufgesetzt.) Das ist ein Befehl zum Anfang. Dann regelmäßiges commiten (also Nutzen des VKS) nicht vergessen und schon ist auch ein kleines Projekt in guten Händen.
>>Gerade hier punkten die verteilten Versionskontrollsysteme: >hg init dass das "neu anlegen" 5 Minuten schneller ist hilft einem nix, wenn GIT (tendenziell) schwieriger zu verstehen/bedienen ist (gibt es so was wie tortoise für GIT ??, weil DAS ist wirklich anwendungsfreundlich)
Stefan B. schrieb: > git wurde nicht entwickelt um ein weiteres Versionskontrollsystem zu > erfinden, sondern um Linux effizient zu weiterzuentwickeln. Dafür wird es (vermutlich, ich bin da nicht involviert) gut taugen. Aber es hat einiges da drin, was meiner Meinung nach nur in diesem Lichte überhaupt interessant ist und sonst gar nicht. Was ich git übel nehme ist, dass alles anders heißt als bei anderen VCSen, sodass man, wenn man mit mehr als einem umgehen muss, jedesmal neu nachdenkt. Das macht Mercurial nicht, obwohl es im Großen und Ganzen sehr ähnliche Ansätze verfolgt (haben ja beide gemeinsame Wurzeln). Die Anpreisung von git scheint mir bei einigen seiner Protagonisten mittlerweile zu einer Art religiösem Glaubensbekenntnis geworden zu sein. ;-) Stefan B. schrieb: > ist weitaus einfacher als ein SVN/CVS Server aufzusetzen. > (Pauschalbehauptung, ich habe noch nie einen solchen Server aufgesetzt.)
1 | svnadmin create |
Nicht wirklich schwieriger. ;-) Wenn man es nicht anschließend in einen Apache integrieren will, kann man dann mit einer file:///-URL drauf zugreifen. Ansonsten kann man das primitiv-svnserve als netzwerkweiten Server benutzen, dürfte von der Feature-Armut her etwa vergleichbar sein mit den eingebauten Billig-HTTP-Servern von Mercurial und git. Letztlich ist auch eine Apache-Integration nicht schwierig (sofern man den Indianer an sich schon mal in den Fingern hatte), und sie bietet netzwerkseitig natürlich eine Schnittstelle, deren Funktion, Sicherheit und Zuverlässigkeit einen etablierten Standard darstellt.
Stefan B. schrieb: > ist weitaus einfacher als ein SVN/CVS Server aufzusetzen. > (Pauschalbehauptung, ich habe noch nie einen solchen Server aufgesetzt.) äpfel sind schwerer als birnen. ich hab noch nie eine birne gesehen. also manchmal fragt man sich wirklich...
Das klingt alles nach einer unbekannten Sprache. Klar, vom Himmel fällt die persönliche Erkenntnis nicht. Vielleicht sollte ich einfach bei dem bleiben was ich kann: kleine Dateien, alles Text, regelmäßig Backup, sinnvolle Kommentare (auch wenn sie länglich werden) und ne genaue PC-Uhrzeit.
Michael H. schrieb: > Stefan B. schrieb: >> ist weitaus einfacher als ein SVN/CVS Server aufzusetzen. >> (Pauschalbehauptung, ich habe noch nie einen solchen Server aufgesetzt.) > > äpfel sind schwerer als birnen. > ich hab noch nie eine birne gesehen. > > > also manchmal fragt man sich wirklich... Ok, also man muss den svn server aufsetzen mit 'svnadmin create'. Kann man auf dem Ordener dann arbeiten oder muss man dann erst in einem anderen Ordner das ding noch klonen mit 'svn checkout'? Die Frage stellt sich mir daher, weil svn unbedingt einen Server haben muss, also man arbeitet nur auf clients? (Daher auch meine Vermutung/ pauschale Behauptung.) Jörg Wunsch schrieb: > Die Anpreisung von git scheint mir bei einigen seiner Protagonisten > mittlerweile zu einer Art religiösem Glaubensbekenntnis geworden zu > sein. ;-) Ich hoffe das es bei mir noch nicht soweit gekommen ist ;) Obwohl ich durchaus gerne versuche Leute von verteilten Versionssystemen zu überzeugen. Das Konzept verteilter Versionskontrollsysteme ist einfach besser. Das trifft für Einzelbenutzer zu, denn dort braucht man keine Client/Server Architektur, sondern nur genau dieses eine Repository. Für das Arbeiten mit mehrern Leuten kann man sich aussuchen mit welchem Modell man arbeitet (siehe zb. die Bilder in http://git-scm.com/about/distributed Es gibt diese workflows auch für hg und bazaar) Ausserdem ist es schneller und macht das Fehlen eines Backups weniger kritisch. Da die verteilten VCS erst seit den letzten Jahren im Kommen sind, kann man sich über die Namen der einzelnen Aktionen streiten, welches Tool es denn nun 'richtig' benannt hat. Ich habe lange Zeit mit einer proprietären Versionsverwaltung gearbeitet (MKS) und dieses Tool ist dermassen von den Normen abgewichen, dass man git und Mercurial als 'gleich' ansehen kann. git im Vergleich zu hg und bazaar ist meiner Meinung nach ähnlich wie der Vergleich von c zu Basic: git ist dermassen mächtig und dadurch so 'gefährlich' für den anfänger, da man viel falsch machen kann. Wenn man allerdings die Tricks kennt, dann kann man sehr tief ins System eingreifen und somit in kurzer Zeit mächtige Operationen durchführen. (Made by engineers for engineers ;) git hat sich gerade im Open Source Bereich stärker durchgesetzt als hg und bazaar. Der Grund dafür ist hoffentlich nicht so wie hier beschrieben: worse is better http://www.jwz.org/doc/worse-is-better.html
Abdul K. schrieb: > Das klingt alles nach einer unbekannten Sprache. Klar ist das erstmal neu, es gibt aber das SVN-Buch (sogar auf deutsch): http://svnbook.red-bean.com/nightly/de/svn-book.pdf Nach den ca. ersten 20 Seiten kann es losgehen, den Rest schaut man an, wenn man es braucht. Bei mir läuft der SVN-Server lokal mit, jedoch auf der SSD und nicht auf der Arbeitsplatte. Damit betrachte ich das gleich als einfaches Backup. Stefan B. schrieb: > Ok, also man muss den svn server aufsetzen mit 'svnadmin create'. > Kann man auf dem Ordener dann arbeiten oder muss man dann erst in einem > anderen Ordner das ding noch klonen mit 'svn checkout'? Erst musst du den Ordner mit commit füllen, aus dem Arbeitsverzeichnis. Du arbeitest auf diesem weiter und rührst die SVN-Ordner nicht direkt an.
Stefan B. schrieb: > Ok, also man muss den svn server aufsetzen mit 'svnadmin create'. > Kann man auf dem Ordener dann arbeiten oder muss man dann erst in einem > anderen Ordner das ding noch klonen mit 'svn checkout'? Du musst dir eine working copy anlegen, da diese ja (naturgemäß) im Unterschied zu einem verteilten VCS nicht identisch mit dem Repository ist. Der Rest danach ist aber wirklich nicht mehr so grob unterschiedlich. > Die Frage stellt sich mir daher, weil svn unbedingt einen Server haben > muss, also man arbeitet nur auf clients? Jein. Ich schrieb ja, du kannst eine file:///-URL benutzen:
1 | $ svnadmin create /tmp/foo-repo |
2 | $ cd $HOME |
3 | $ svn co file:///tmp/foo-repo |
4 | Checked out revision 0. |
5 | $ cd foo-repo |
6 | $ echo hi > bar.txt |
7 | $ svn add bar.txt |
8 | A bar.txt |
9 | $ svn -m 'Test commit' commit |
10 | Adding bar.txt |
11 | Transmitting file data . |
12 | Committed revision 1. |
13 | $ svn info |
14 | Path: . |
15 | URL: file:///tmp/foo-repo |
16 | Repository Root: file:///tmp/foo-repo |
17 | Repository UUID: 6ee89915-6c09-4047-b1ee-05e843de7e13 |
18 | Revision: 0 |
19 | Node Kind: directory |
20 | Schedule: normal |
21 | Last Changed Rev: 0 |
22 | Last Changed Date: 2012-06-28 16:14:17 +0200 (Thu, 28 Jun 2012) |
Formal hast du natürlich eine URL, aber es gibt keinen wirklichen Server dahinter, sondern der Zugriff über das URL-Schema namens "file" weist den Client an, ein lokales Verzeichnis zu benutzen. > Obwohl ich durchaus gerne versuche Leute von verteilten Versionssystemen > zu überzeugen. Das Konzept verteilter Versionskontrollsysteme ist > einfach besser. Davon bin ich eben noch nicht überzeugt. > Das trifft für Einzelbenutzer zu, denn dort braucht man keine > Client/Server Architektur, sondern nur genau dieses eine Repository. Siehe oben. Der Unterschied ist eben nur, dass Repository und working copy getrennt sind. Für bestimmte Backup-Strategien kann das durchaus ein Vorteil sein. Gut, kann man mit einem DVCS auch haben (wenn ich nur mit hg push / hg pull einen Clone anlege und wieder aktualisiere, der aber nie selbst eine working copy erhält), aber dann mutiert ja letztlich das DVCS zu einem klassischen serverbasierten VCS. Im übrigen ist auch CVS komplett nicht-server-basiert. > Da die verteilten VCS erst seit den letzten Jahren im Kommen sind, kann > man sich über die Namen der einzelnen Aktionen streiten, welches Tool es > denn nun 'richtig' benannt hat. Mir geht's bei meiner Beschwerde bezüglich git nur darum, dass sie Dinge anders genannt haben als bei den klassischen VCS, auch wenn es sich um eine vergleichbare Aktion handelt. Mercurial hat das nicht getan, dort haben vergleichbare (zu CVS oder SVN) Aktionen den gewohnten Namen bekommen. Nicht-DVCS sind aber nun eindeutig älter, darüber muss man nicht streiten. :-) > Ich habe lange Zeit mit einer proprietären Versionsverwaltung gearbeitet > (MKS) und dieses Tool ist dermassen von den Normen abgewichen, dass man > git und Mercurial als 'gleich' ansehen kann. Das Anführen noch schlechterer Beispiele ist keine Entschuldigung. ;-) > git hat sich gerade im Open Source Bereich stärker durchgesetzt als hg > und bazaar. bazaar ist vermutlich mal einfach zu spät gewesen. Ansonsten halte ich die Verbreitung im Linux-Umfeld für viel mehr treibende Kraft als irgendeine Form architektureller Schönheit. So nach dem Prinzip: "Wenn Großwesir Linus das extra erfinden musste, weil ihm alles andere nicht gefallen hat, dann muss es ja gut sein."
Mein Werdegang:
1. Visual SorceSafe (A)
2. CVS (H)
3. Subversion (H, dann auch A)
4. Git (A, dann auch H)
A = Arbeit
H = Hobby
Einigermaßen Spaß hat die ganze Sache aber erst mit Subversion und (noch
mehr) mit Git gemacht. Mercurial und Darcs würde ich auch mal gerne
ausprobieren, habe aber bisher nicht die Zeit dazu gefunden. Die Vor-
und Nachteile solcher Systeme erkennt man leider erst, wenn man ein
nicht ganz triviales Projekt damit durchzieht.
Da ich nur etwa 50% der Features von Subversion und vielleicht 20% der
Features von Git benutze, kenne ich viele der Vorteile von Git gegenüber
Subversion nur vom Hörensagen. Im Wesentlichen benutze ich Git gleich
wie Subversion, arbeite aber etwas ungehemmter mit Branches und Merges,
wobei meine Anforderungen an diese Dinge nicht so hoch sind, als dass
man sie nicht auch mit Subversion erschlagen könnte.
Sehr praktisch finde ich Git (bzw.verteilte VCSe), wenn man auf mehreren
Rechnern arbeitet, die nicht ständig netzwerkmäßig untereinander verbun-
den sind, man aber ständig die Vorteile der Versionsverwaltung nutzen
will. Da habe ich für Subversion noch keine zufriedenstellende Lösung
gefunden.
Bei Git hat man jeweils einen lokalen Klon des kompletten Repositorys
auf dem Rechner (und vielleicht noch einen weiteren auf dem USB-Stick),
so dass fast alle Vorteile der Versionsverwaltung auch unterwegs verfüg-
bar sind. Natürlich müssen die Klons hin und wieder untereinander syn-
chronisiert werden. Das ergibt sich aber fast von selbst, wenn man
öfters den Arbeitsort bzw. den Rechner wechselt.
Je mehr aktive Repository-Klone im Umlauf sind, umso weniger Arbeit geht
im Falle eines Festplatten-Crashs (und kaputtgegangenem Backup ;-))
verloren.
Ich würde jetzt Git nicht bis aufs Blut verteidigen, zumindest nicht,
solange ich nicht etwas tiefer drin stecke und mir noch ein paar andere
VCSe genauer angesehen habe. Für den Moment erfüllt es aber meine
bescheidenen Anforderungen in mehr als ausreichendem Maß, so dass ich in
nächster Zeit sicher nicht wechseln werde.
Jörg Wunsch schrieb: > Was ich git übel nehme ist, dass alles anders heißt als bei anderen > VCSen, sodass man, wenn man mit mehr als einem umgehen muss, jedesmal > neu nachdenkt. Findest du? Die Basisoperationen, die wahrscheinlich 95% der Arbeit mit einem VCS abdecken, heißen doch bei Subversion und Git gleich und tun im Wesentlichen auch dasselbe: checkout add commit status rm mv diff Bei Subversion kommt als wichtiger Befehl noch update hinzu, den man bei Git nicht braucht, da sich das lokale Repository nicht ohne eigenes Zutun ändert. Bei Git gibt es noch pull und push, um das lokale Repository mit einem anderen abzugleichen. Diese Befehle werden wiederum bei Subversion nicht benötigt, da es dort nur eine einzelne (zentrale) Repository- Instanz gibt.
Ich werde wohl einfach das Betäubungsgewehr einpacken und in die Großstadt zum Wildern fahren. Dort lege ich auf Jörg an und wenn er aufwacht, ist er an einen Stuhl an einem neuen Schreibtisch neben meinem festgebunden. Dann hört er immer "Jörg, hier habe ich gerade die Konstante im Teiler geändert, weil die Frequenz laut Scope nicht paßte. Trag das mal ein.", "Jörg, mach dies und das", "Jörg, was hatte ich vor einer Stunde gändert und warum?", "Jörg, mach mal aus beiden vermutlich lauffähigen Sourcen vor 2 Jahren eine lauffähige mit den Vorteilen beider Sourcen. Ich brauch die in 5 Minuten!", "Jörg, mach Kaffe, aber sächsisch bitte!" ;-)
Yalu X. schrieb: > Findest du? Die Basisoperationen, die wahrscheinlich 95% der Arbeit mit > einem VCS abdecken, heißen doch bei Subversion und Git gleich und tun im > Wesentlichen auch dasselbe: Naja, also checkout und commit sind unterschiedlich. checkout bei git checked branches aus oder setzt einzelne Dateien zurück auf die bisherige Version in dem branch. svn checkout ist dagegen soetwas wie git clone. commit be git legt die Dateien nur in das lokale repo hinein, während bei svn die Dateien für alle sichtbar auf den Server 'gepushed' werden (git push wäre das analogon) siehe auch http://git.or.cz/course/svn.html
Yalu X. schrieb: > Bei Subversion kommt als wichtiger Befehl noch update hinzu, den man > bei Git nicht braucht, da sich das lokale Repository nicht ohne eigenes > Zutun ändert. hg wiederum hat ein update, mit dem die lokale working copy aktualisiert wird (bspw. nach einem hg pull oder einem hg push von außerhalb). > Sehr praktisch finde ich Git (bzw.verteilte VCSe), wenn man auf mehreren > Rechnern arbeitet, die nicht ständig netzwerkmäßig untereinander verbun- > den sind, man aber ständig die Vorteile der Versionsverwaltung nutzen > will. Da habe ich für Subversion noch keine zufriedenstellende Lösung > gefunden. Kann man schon irgendwie zaubern, aber wenn du genau das wirklich brauchst, dann ist ein DVCS natürlich auch genau das, was du willst. Ist bei mir aber eher die Ausnahme denn die Regel. In dem einen Projekt, in dem ich mitarbeite, welches mit Mercurial arbeitet, mache ich oft genug gleich nach dem commit ein push auf den autoritativen Server, damit ich eben nicht erst später gezwungen bin, noch einen Merge zu machen, weil zwischenzeitlich jemand anders auch noch etwas geändert hat. Damit bin ich letztlich bei der gleichen Verfahrensweise, wie wenn man gleich SVN nimmt.
Stefan B. schrieb: > Naja, also checkout und commit sind unterschiedlich. Ok, das ist natürlich eine Frage der Perspektive. Wenn man das zentrale SVN-Repository mit dem lokalen Git-Repository gleichsetzt und in SVN immer nur denjenigen Branch im Arbeitsverzeichnis hält, an dem man auch tatsächlich arbeitet, sind die Befehle schon sehr ähnlich: checkout kopiert einen Branch vom Repository ins Arbeitsverzeichnis, commit überträgt Änderungen vom Arbeitsverzeichnis ins Repository. Die Ebene der Remote-Repositories in Git hat nach dieser Betrachtungs- weise kein SVN-Äquivalent, das Gleiche gilt deswegen auch für push, pull und fetch. Jörg Wunsch schrieb: >> Sehr praktisch finde ich Git (bzw.verteilte VCSe), wenn man auf mehreren >> Rechnern arbeitet, die nicht ständig netzwerkmäßig untereinander verbun- >> den sind, […] > > Kann man schon irgendwie zaubern, aber wenn du genau das wirklich > brauchst, dann ist ein DVCS natürlich auch genau das, was du willst. Das passiert bspw. dann, wenn ich beruflich bei Kunden oder Projektpart- nern zu Besuch bin, um ein Stück Software (evtl. mehrere Varianten oder Versionen davon) vor Ort zu testen, zu debuggen und zu optimieren. Da hat man oft keinen Internetzugang, oder es ist aus firmenphilosophischen Gründen nicht gestattet, Sourcecode über das Internet zu übertragen (nicht einmal verschlüsselt). Man kann natürlich auch bei SVN eine Kopie des Repos mitnehmen, muss aber dann irgendwelche Änderungen, die man unterwegs macht und die man auf mehrere Commits verteilen will, hinterher wieder irgendwie in das Originalrepo hineinbasteln.
Ich muß eine meiner Fragen nochmal wiederholen: Ist irgendeines der Tools oder eine andere Methodik auch für andere Sachen als C-Code benutzbar? Ich erwähnte als Beispiel Simulationen in LTspice! Die muß ich ja auch verwalten.
Du kannst jede Art Datei damit verwalten. Bei einem Binary macht natürlich z.B. ein diff wenig Sinn, aber Versionsverwaltung soweit funktioniert.
Abdul K. schrieb: > Ist irgendeines der Tools oder eine andere Methodik auch für andere > Sachen als C-Code benutzbar? Praktisch alle VCSe arbeiten mit beliebigen Dateitypen, also bspw. auch LTspice-, Eagle-, LibreOffice- oder Bilddateien. Einschränkungen gibt es allerdings beim Versionsvergleich (diff) und beim Mergen von Branches (merge). Beides beschränkt sich auf reine Textdateien. Auch die ASC- Dateien von LTspice sind Textdateien, trotzdem entspricht die Ausgabe der Unterschiede zweier solcher Dateien sicher nicht deinen Erwartungen. Wenn man das akzeptiert, kann man mit Tools fast alles (mit Ausnahme vielleicht von Gigabytes großen Videos) verwalten.
Stefan B. schrieb: > Gerade hier punkten die verteilten Versionskontrollsysteme: > hg init > alternativ auch > git init > ist weitaus einfacher als ein SVN/CVS Server aufzusetzen. > (Pauschalbehauptung, ich habe noch nie einen solchen Server aufgesetzt.) svnadmin create mein_repository Da kann man dann lokal oder, wennn man einen ssh-Server laufen hat, per svn+ssh drauf zugreifen. Yalu X. schrieb: > Sehr praktisch finde ich Git (bzw.verteilte VCSe), wenn man auf mehreren > Rechnern arbeitet, die nicht ständig netzwerkmäßig untereinander verbun- > den sind, man aber ständig die Vorteile der Versionsverwaltung nutzen > will. Da habe ich für Subversion noch keine zufriedenstellende Lösung > gefunden. Man kann das ja auch in Kombination nutzen, also svn auf dem Server und lokal dann git. Dafür gibt's dann git-svn. Ich hab's bisher nur nicht eingesetzt, weil das verwendete svn-Repository, bei dem das in Frage käme, mit external links arbeitet und git-svn dafür keine einfache Lösung bietet. Yalu X. schrieb: > Praktisch alle VCSe arbeiten mit beliebigen Dateitypen, also bspw. auch > LTspice-, Eagle-, LibreOffice- oder Bilddateien. Einschränkungen gibt es > allerdings beim Versionsvergleich (diff) und beim Mergen von Branches > (merge). Beides beschränkt sich auf reine Textdateien. Das ist ja an sich nicht zwingend so, nur bräuchte man für diese beiden Operationen halt für jedes Binärformat ein eigenes Programm, das das kann. Bei Text ist dafür ein einfaches diff-Tool und ein Texteditor ausreichend, ideal ist ein Texteditor mit eingebauter diff-Funktion. Für die meisten Binärformate gibt's halt keine entsprechenden Tools, bzw. ist es auch nicht immer sinnvoll (z.B. bringt es nicht viel, bei PNG die geänderten Pixel mergen zu können). Bei denen ist es dann auch nicht sinnvoll, wenn mehrere Leute parallel dran arbeiten. Deshalb hat svn hierfür auch immer noch Unterstüzung für die klassische "lock-modify-unlock"-Methode.
ich hab gelesen bei GIT macht man "commit bevore merge" kann mir das jemand erklären? als SVN Nutzer, wüsste ich nicht wie das gehen soll (da macht man "merge bevore commmit" was irgendwie logisch ist, weil nach dem merge ja mal (normalerweise) eine menge Konflikte und sonstige "Probleme hat.. und man/ich ja auf keine Fall ein inkonsistenten stand im repo haben will
Robert L. schrieb: > ich hab gelesen > bei GIT macht man > > "commit bevore merge" > > kann mir das jemand erklären? > als SVN Nutzer, wüsste ich nicht wie das gehen soll (da macht man "merge > bevore commmit" Ich verstehe das so: Bei git hast du ein lokales Repository, also gibt's da nix zu mergen, wenn du da rein commitest. Späer synchronisierst du das dann mit einem remote-Repository, und erst dann mußt du mergen.
Rolf Magnus schrieb: > Später synchronisierst du das dann mit einem > remote-Repository, und erst dann mußt du mergen. Weiß nicht, wie das bei git gelöst ist, bei Mercurial muss man nach dem Merge dann erneut committen. Das finde ich echt lästig. (Ja, wirklich vermeiden lässt sich das bei diesem Modell nicht, ist mir schon klar.)
Also bei Mercurial (ist ja ähnlich wie GIT) wird durch den Commit dann eine Art Branch erzeugt. Synchronisiert man sich dann mit einem anderen Repository, in dem auch Ändereungen vorgenommen wurden, erhält man zwei Branches (den eigenen und den fremden). Die kann man dann mergen und hat dann wieder nur einen Branch. Bei SVN ist der Nachteil ja, daß man durch ein Update direkt in der Working Copy mergen muß. Dadurch hab ich mir schon so einiges zerschossen. Bei Mercurial sind erstmal alle Änderungen im Repository gesichert und man kann dann in aller Ruhe mergen, gucken ob es geht und im Notfall den Mergevorgang wiederholen.
auch Hans schrieb: > Bei Mercurial sind erstmal alle Änderungen im Repository > gesichert und man kann dann in aller Ruhe mergen, gucken ob es geht und > im Notfall den Mergevorgang wiederholen. Das ist natürlich wirklich mal ein Argument, das ich nachvollziehen kann und das für DVCS spricht (auch dann, wenn man das "D" eigentlich gar nicht braucht, weil es ohnehin ein zentrales, "autoritatives" Repository gibt, gegen das sich alle hin und wieder abgleichen müssen). CVS war in der Beziehung wohl besser als SVN: dort wurden bei einem Merge die bisherigen Dateien der working copy (sofern es lokale Änderungen gab) als .#<Dateiname>.<Version> beiseite gelegt, sodass man seine vorherige working copy immer noch einmal einsehen konnte.
vorweg: ICH meinte mit Merge was anders als ihr (das was SVNMerge macht, und svn selber garnicht kann, nämlich (teile) aus einem Branch z.b. zurück in den Trunk mergen, mehrfach usw. ) aber egal: >CVS war in der Beziehung wohl besser als SVN: dort wurden bei einem >Merge die bisherigen Dateien der working copy ein "ganz normales" svn update meinst du, das macht SVN natürlich genau so wenn nicht automatisch merged werden kann wird das ganze dann als Konflikt markiert, den man beheben muss man hat ein datei aus dem repo, und seine eingenen mit änderungen geht (wie gesagt) mit tortoise (und dem integrierten winmerge) alles bestens wüsste nicht wie man sich da was zerschießt..
Zerschießen kann man sich da was, wenn viele Zeilen Code im Repository und in der Working Copy geändert wurden . Da hilft mir dann auch WinMerge nur bedingt. Das ist unübersichtlich und fehleranfällig. Oder das Mergetool meint garkeinen Konflikt festzustellen und löscht mal fleißig irgendwas oder fügt Müll irgendwo ein, wo er nicht hingehört. Und dann darf man suchen gehen. Das ist bei Mercurial eleganter, da ich beide Versionen sicher im Repository habe und das so oft probieren kann wie ich will und nachträglich gegen beide ein Diff durchführen kann. Bei einem Mergevorgang zwischen zwei Branches gibt es keine Unterschiede, außer daß es mit Mercurial sehr einfach geht und ein Mergetracking mit drin ist. Subversion ist da ein Krampf (ich habe es jedenfalls mit statndard SVN Kommandos und TortoiseSVN noch nicht ordentlich hinbekommen).
Robert L. schrieb: > ein "ganz normales" svn update meinst du, > das macht SVN natürlich genau so Nein. > wenn nicht automatisch merged werden kann > wird das ganze dann als Konflikt markiert, den man beheben muss > man hat ein datei aus dem repo, und seine eingenen mit änderungen ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Aber bereits mit den Markierungen für die beim Merge aufgetretenen Fehlermeldungen. Die originale Datei der working copy hat man nicht mehr danach (bei CVS halt schon). > wüsste nicht wie man sich da was zerschießt.. Wenn die Änderungen hinreichend komplex waren (zwischen Repo und working copy), dann kann der Automatismus schon mal versagen und völlig falsche Stellen versuchen zu patchen. > vorweg: ICH meinte mit Merge was anders als ihr (das was SVNMerge macht, > und svn selber garnicht kann, nämlich (teile) aus einem Branch z.b. > zurück in den Trunk mergen, mehrfach usw. ) Ja, bei SVN sind das zwei Merges, bei git/hg dagegen ist ja beides dasselbe. Dort erzeugt man ja implizit mit seinen Änderungen erstmal einen Branch, immer. Wenn sich beim nächsten Abgleich mit einem anderen Repository dort ebenfalls etwas geändert hat, muss man dann einen Merge anwerfen, der logisch dem entspricht, was SVN beim "svn update" macht, aber letztlich eher so gehandhabt wird, wie man das bei "svn merge" machen würde. (Bei letzterem finde ich in den aktuellen Versionen das Konzept der svn:mergeinfo nicht schlecht, sofern man eine gewisse Disziplin an den Tag legt und sich auf bestimmte Basisverzeichnisse einigt, in denen man das svn merge ausführt.)
Abdul K. schrieb: > Welche Lösungen habt ihr erarbeitet, um eure Versionskontrolle eurer > Arbeit zu organisieren? Ich werfe hier mal noch einen Außenseiter in den Ring, der meiner Meinung nach jedem, der vor der Entscheidung für ein Versionskontrollsystem steht, einen Blick wert sein sollte: Fossil (http://www.fossil-scm.org) ist ein kleines aber feines Versionsverwaltungssystem, das der Autor von SQLite geschrieben hat. Man kann es sowohl lokal als auch verteilt einsetzen und es enthält neben der eigentlichen Versionsverwaltung noch ein Wiki und einen Ticket-Tracker. Das macht es as meiner Sicht ideal für Hobby-Projekte, die man ohne viel Aufwand selbst hosten will, was aber nicht heißen soll, daß es nicht auch für größere Projekte taugt. Es ist u.A. für Linux, Windows und Mac verfügbar (und natürlich im Quellcode) und besteht aus einer einzigen ausführbaren Datei, die man ohne Installation aufrufen kann. Neben der Kommandozeile ist ein grafisches Interface vorhanden, das über einen eingebauten Webserver realisiert wird. Außerdem kann man es als CGI in einen bestehenden Webserver einbinden. Das Repository und die Verwaltungsinformation einer Working Copy stecken jeweils in einer einzigen SQLite-Datei, und sind dadurch transaktionssicher und einfach zu archivieren. Neben SQLite und Fossil selbst werden z.B. auch die Sourcen von Tcl/Tk seit letztem Jahr mit Fossil verwaltet: http://www.fossil-scm.org/index.html/timeline http://www.sqlite.org/src/timeline http://core.tcl.tk/tcl/timeline?y=ci http://core.tcl.tk/tk/timeline?y=ci http://core.tcl.tk/
auch Hans schrieb: > Subversion ist da ein Krampf (ich habe es > jedenfalls mit statndard SVN Kommandos und TortoiseSVN noch nicht > ordentlich hinbekommen). Tortoise kenne ich nur vom Draufgucken, benutze ich nicht. Mit svn merge selbst funktioniert es so schlecht gar nicht. Eventuell könnte dir hier die Entwickler-Doku von FreeBSD helfen, die Zusammenhänge zu verstehen: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/subversion-primer.html (Runterscrollen bis 4.4.3)
>Aber bereits mit den Markierungen für die beim Merge aufgetretenen nein, das stimmt nicht man bekommt bei einem Konflikt (Bis zu?) 4 Dateien eine davon die xxxx.mine Datei (hab ich gerade ausprobiert) diese ist Original die eigene (wie der Name schon sagt) >Oder >das Mergetool meint garkeinen Konflikt festzustellen und löscht mal >fleißig irgendwas oder fügt Müll irgendwo ein, das ist mir noch überhaupt nie passiert, weiß nicht wie das gehen soll... >Wenn die Änderungen hinreichend komplex waren (zwischen Repo und >working copy), dann hat man aber was falsch gemacht: warum sollen 2 Programmierer am selben "komplexen" teil zugleich Änderungen vornehmen? ohne sich abzusprechen und WENN man schon "komplexe" Änderungen machen muss, macht man die in einem Branche und hat das Problem eh nicht (weil DANN ist vor dem merge von branche nach trunk ja alles im repo..)
Robert L. schrieb: > dann hat man aber was falsch gemacht: warum sollen 2 Programmierer am > selben "komplexen" teil zugleich Änderungen vornehmen? ohne sich > abzusprechen Dann fällt mir z.B. generierter Code ein. Da kann sich mal ganz schnell ganz viel ändern. Dann ändert sich auch schnell mal die Reihenfolge der Codeteile in einer Datei und niemand steigt mehr durch. > und WENN man schon "komplexe" Änderungen machen muss, macht man die in > einem Branche und hat das Problem eh nicht (weil DANN ist vor dem merge > von branche nach trunk ja alles im repo..) Genau so etwas tut man mit Mercurial und einem "Commit before Merge" ja auch. Was jetzt von beidem besser ist will ich nicht sagen. Ich verwende auch privat Subversion und Mercurial. Subversion hat den riesigen Vorteil mit großen Binärdateien umgehen zu können. Bei 300 MB war bei Mercurial (jedenfalls vor nem Jahr) Schluß und ich konnte die Dateiänderungen nicht mehr Pushen. Und Subversion hat Partial Checkouts. Mercurial ist halt toll, wenn man auf verschiedenen Rechnern arbeitet oder unterwegs ist und 'ne alte Version braucht, aber kein Internetzugang hat oder die Server nicht online verfügbar sind.
Robert L. schrieb: > eine davon > die xxxx.mine Datei (hab ich gerade ausprobiert) > > diese ist Original die eigene (wie der Name schon sagt) OK, stimmt, das hatte ich mittlerweile vergessen. Offenbar schon lange keine Merge-Konflikte mehr mit SVN gehabt. ;-)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.