Freitag 13.Juli.2012, 8:19 von Mario
Ich weiß, das wissen wir alle schon länger, aber ich durfe gerade eine svn Workingcopy unter Linux auschecken, nur um einen Symlink anlegen zu können und diesen anschließend auch ins Repository commiten zu können.
Darüber ob Symlinks im svn gut sind läßt sich sicher streiten, aber manchmal muss es eben doch sein und frei nach Monty Python möchte ich einfach die prinzipielle Möglichkeit haben Babies zu bekommen, äh ich meine natürlich Symlinks anlegen zu können.
So, jetzt geht’s mir schon ein wenig besser :-)!
Freitag 12.November.2010, 18:30 von Mario
Es hat lange gedauert, bis es bei mir soweit war, das ich mich mit Git beschäftigen musste(keine Abneigung, aber bei SVN hat mir einfach nichts gefehlt), aber just diese Woche ergab sich die Gelegenheit.
Eine Library(PHPThumbs) die ich verwenden möchte hosted ihren Code auf github.com und da mir die Library gut gefällt, mir aber eine Funktion zum Erzeugen von Tiles aus einem Image gefehlt hat, habe ich das kurzerhand als Anlaß genommen, mir mal Git anzusehen, indem ich das Projekt forke, mein benötigtes Plugin implementiere und dann das ganze dann hoffentlich zurück fließen lassen kann. Das Plugin ist implementiert und den Pull-Request hab ich auch rausgeschickt und nun warte ich ganz gespannt, was als nächstes passiert, ich bin ja soooo aufgeregt :-).
Und weil mir das Ganze so gut gefallen hat mit dem social coding(und das obwohl ich nicht mal ein Facebook Acount habe, he, he) hab ich gleich mal meine Zend Framework Beispiel Applikation (urlino.com) nach Github migriert. Jetzt heißt es warten und schauen, wann ich zum ersten Mal geforkt werde. Ich hab schon mal das „Fork me on GitHub“ Ribbon anschraubt :-).
Ansich ist Git ja wirklich angenehm, wobei ich zumindest jetzt am Anfang noch keine unerwartete Offenbarung erfahren habe, ist halt ein SCM, scheint meinen Bedürfnisse zu erfüllen und ist auch recht intuitiv zu bedienen, aber eine Sache ist mir zumindest untergekommen, die mir momentan noch nicht gefallen will: Und zwar das Einbinden von externen Libraries von denen es kein Git Repository gibt, also quasi ein svn:externals für Git, welches nicht nur mit Git Repositories spricht(gibt es und wird über submodules realisiert), sondern es auch erlaubt entfernte SVN (Teil-)Repositories auch in Git einzuhängen, was umgekehrt, also Git Repos in SVN Repo, Klasse funktioniert. Falls da ich da was übersehen habe und jemand eine clevere Lösung hat, das wär schon was :-).
Donnerstag 26.August.2010, 17:45 von Mario
Alle paar Wochen laufe ich in die selbe Falle, beim Refactoring eins kompletten Stangs von Dateien die in einem svn Repository liegen, endet es in einem Tree Conflict der unerwartet ist, wenn man sich die Definition eines Tree Conflicts in der svn Dokumentation ansieht:
But what happens if your collaborators move or delete a file that you are still working on? Maybe there was a miscommunication, and one person thinks the file should be deleted, while another person still wants to commit changes to the file. Or maybe your collaborators did some refactoring, renaming files and moving around directories in the process. If you were still working on these files, those modifications may need to be applied to the files at their new location. Such conflicts manifest themselves at the directory tree structure level rather than at the file content level, and are known as tree conflicts.
Für mich als unbedraften Benutzer liest sich das erstmal so, als würde ich generell nur einen Tree Conflict bekommen können, wenn es mehrere Commiter auf einem Repository, bzw. um genau zu sein einem Teilstrang eines Repositories gibt. Dem ist leider nicht so.
Mir zum Beispiel passiert ein Tree Conflict regelmäßig beim Löschen von Verzeichnissen an denen ich nur selber arbeite und die Ursache in diesem Fall sind „mixed-revision working copies“. „mixed-revision working copies“ sind an sich eine feine Sache, da man anhand dessen in der Lage ist, jedes File und jedes Verzeichnis seines Checkouts einzeln upzudaten, wenn man es braucht. Und da ich das gelegentlich brauche, denke ich mal ich stehe da nicht alleine :-).
Bezüglich des Problems gibt es einen sehr interessanten Thread in der svn Developer Mailingliste, den ich zwar nicht in Gänze wiedergeben will, dessen Quintessenz aber lautet: Will ich einen Verzeichins löschen, so ist es Best Practice, lieber einmal zu viel als einmal zu wenig den Strang auf dem man gerade etwas löschen oder verschieben will upzudaten, damit man für diesen Strang eben nicht eine „mixed-revision working copy“ hat, sondern alle Verzeichnisse auf einer Revision sind.
Und falls es zur Vertiefung etwas Leküre fürs Regal sein soll, empfehle ich das folgende Buch: Versionskontrolle mit Subversion welches von den Entwicklern von svn geschrieben wurde.