|
|
|
|
Echt? Also ich bin nicht so'n Soljanka-Fan, hab da aber bisher nie solche Nebenwirkungen festgestellt
|
|
|
|
|
|
|
| Zitat von GH@NDI
Ist gekauft und als Boolean natural full-text search implementiert
| |
Lang lebe Ghandi \o/
e\ wird auch nach dem Rank-Wert sortiert? Mir kommt es irgendwie so vor, als seien recht irrelevante Posts oben
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von TriggerTG am 14.06.2011 18:32]
|
|
|
|
|
|
Erfolgserlebnis des Tages: Den gerissenen Bowdenzug der Gangschaltung gewechselt.
Und ich hab mich entschieden dass ich nicht mehr versuche in Linearer Algebra hinterherzuhecheln sondern jetzt bei den aktuellen Übungsblättern mitmache, dann kann ich mich wenigstens mit Anderen austauschen die die auch nicht verstehen.
|
|
|
|
|
|
|
Hab lang überlegt, wo ichs frage aber da hier schonmal gern über das Thema abgeraged wird, frag ich am besten hier:
Warum ist SVN eigentlich so scheiße wie alle immer behaupten und was macht git so genial?
|
|
|
|
|
|
|
Angeblich soll SVN langsam sein, da habe ich aber noch nie was von bemerkt.
|
|
|
|
|
|
|
Das branchen und mergen soll auch ziemlich beschissen sein. Wo jetzt das Problem beim branchen und taggen ist, habe ich bisher aber auch noch nicht verstanden.
|
|
|
|
|
|
|
Git ist einfach artsy!
|
|
|
|
|
|
|
| Zitat von Danzelot
Angeblich soll SVN langsam sein, da habe ich aber noch nie was von bemerkt.
| |
Hab bisher mal kurz mit SVN gearbeitet, war wohl nicht lang und tief genug um drüber abkotzen zu können.
|
|
|
|
|
|
|
Ich kann nur CVS und SVN vergleichen und CVS war dann doch deutlich langsamer.
|
|
|
|
|
|
|
Ach du liebe Güte... Once Upon a Time in America... knapp 4 Stunden. Meine Aufmerksamkeitsspanne beträgt doch grad mal 20 Minuten
Muss ich den Film auf 2 Wochen verteilen
|
|
|
|
|
|
|
@git vs. svn: in git ist dein workflow anders, weil committen einfach keine merkliche zeit braucht. das heißt du committest einfach dauernd.
durch die vielen kleinen commits kann git besser mergen.
und da alles lokal ist, ist branchen (und eben auch mergen) ganz normal, weil du es bei jedem „update“ (pull) und „commit“ (=push) zum ursprungsrepository tusts
am ende hast du halt keinen stress: das hauptrepository kann nicht abrauchen, weil alle, die kürzlich gepullt haben alle änderungen haben. und durch all das billie branchen/mergen entstehen auch vorteile.
abschließend: warum nicht? selbst wenn dir all das nix bringt, ist es immer noch schneller als svn und hat svn gegenüber trotzdem keine nachteile.
|
|
|
|
|
|
|
Sowas wollt ich hören, danke.
*chef git empfehl*
|
|
|
|
|
|
|
Ich würd' nix auf Basis von Hörensagen weiterempfehlen. Insbesondere wenn die ausschlaggebende Meinung (von Sheep) die Nicht-Existenz von jeglichen Nachteilen gegenüber SVN ohne (formulierte) Zweifel behauptet.
* * *
Ich glaub jedoch, dass er recht hat
Hab vorhin nur mal kurz bei Stackoverflow geguckt. Naja, die Leute sehen die Unterschiede da recht gelassen. Ist also nix, worüber man einen Feldzug ala "WAASS? DU NUTZT NOCH SVN? LOOOOOL" führen müsste.
* * *
Immer wenn ich an meinem fast noch brandneuen Lese-Tisch lese, fühle ich mich wie ein weiser, alter Professor
Ganz ohne PC und so
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von TriggerTG am 14.06.2011 21:48]
|
|
|
|
|
|
was reden bitte alle von langen Commits bei svn? Was zum Teufel dauert da so lang? Entwickelt ihr alle auf dem Smartphone?
|
|
|
|
|
|
|
Wooooooah, Neid auf den Bücherregal. Ich muss in meinem schon zwei-reihig stellen und für was größeres hab ich keinen Platz.
Ne, bei uns bricht kein Glaubenskrieg los. Nur bin ich der zweite Programmierer der Firma und wenn ihr jetzt gesagt hättet es wäre egal ob git oder svn hätten wir wohl eine Münze geworfen.
|
|
|
|
|
|
|
| Zitat von GarlandGreene
was reden bitte alle von langen Commits bei svn?
| |
Das frag ich mich auch die ganze Zeit. Bei mir ging das bisher immer raz faz...
|
|
|
|
|
|
|
wahrscheinlich gehts bei git 2 Sekunden schneller. Wahnsinn. Da entwickelt man Stunden an einer Anwendung und dann freut man sich, daß man beim Commit das Dialogfeld ne Sekunde weniger lang sehen muss. Das nennt man Prioritäten setzen.
|
|
|
|
|
|
|
Bei git werdet ihr sagen: "Verdammt, schon wieder mit einem falschen Befehl das Repository zerschossen!"
Bei svn werdet ihr sagen: "Verdammt, schon wieder ein dämlicher vermeidbarer Konflikt beim Mergen!"
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Danzelot am 14.06.2011 22:02]
|
|
|
|
|
|
ich hab keine Konflikte mit mir selbst. Und ich hab in bald 10 Jahren noch keine Branches benötigt. Auch wenn ich da tatsächlich einen Zweck unterstellen kann.
|
|
|
|
|
|
|
Na klar, wenn man nur alleine arbeitet gibts keine Konflikte. Wobei, das habe ich auch schon hingekriegt...
|
|
|
|
|
|
|
Wie verhält sich git beim refactoring?
Ist das mergen da leichter wenn die Klasse umbenannt und in ein neues package gezogen wurde?
Bei sowas verzweifle ich immer mit SVN und mach das von Hand.
Das passiert leider sehr häufig...Struktur bedingt.
|
|
|
|
|
|
|
| Zitat von GarlandGreene
wahrscheinlich gehts bei git 2 Sekunden schneller. Wahnsinn. Da entwickelt man Stunden an einer Anwendung und dann freut man sich, daß man beim Commit das Dialogfeld ne Sekunde weniger lang sehen muss. Das nennt man Prioritäten setzen.
| | meinst du jetzt commits oder pushes?
| Zitat von Danzelot Bei git werdet ihr sagen: "Verdammt, schon wieder mit einem falschen Befehl das Repository zerschossen!"
Bei svn werdet ihr sagen: "Verdammt, schon wieder ein dämlicher vermeidbarer Konflikt beim Mergen!" | | wie denn das? rm -R .git ?
| Zitat von Danzelot Na klar, wenn man nur alleine arbeitet gibts keine Konflikte. Wobei, das habe ich auch schon hingekriegt... | | mehrere branches gehen auch bei einem soloprojekt. und das funzt gut. warum von einem gefailten projekt reverten, wenn man auch branches wechseln kann
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von flying sheep am 14.06.2011 22:26]
|
|
|
|
|
|
| Zitat von jdo_O Wie verhält sich git beim refactoring?
Ist das mergen da leichter wenn die Klasse umbenannt und in ein neues package gezogen wurde? | | kein ding. git verfolgt dateiinhalte, nicht namen, also kannste das rumschieben, wie du lustig bist.
|
|
|
|
|
|
|
| Zitat von GarlandGreene
beim Commit das Dialogfeld
| |
|
|
|
|
|
|
|
Ach ja. Warum git auch noch uber ist: Bisect.
¤: Die beschreiben da ja gar nicht [url=http://kernel.org/pub/software/scm/git/docs/git-bisect.html]bisect run. Das ist das geilste Feature von allen. Letztes Semester mit 60 Leuten an einem Projekt gesessen. Einer macht was kaputt. Lässt du einmal git bisect run rake spec laufen und schon sagt dir Git, welcher Commit Scheiße war. Ein Traum.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von [Dicope] am 14.06.2011 22:35]
|
|
|
|
|
|
Gut, brauch ich jetzt bei zwei Leuten nicht. Wenn du es nicht warst und alles hin ist, weisst du wohin deine Kaffeetasse zu fliegen hat.
|
|
|
|
|
|
|
das einzig "komische" find ich das branche wechseln bei git. da wechselt man die datein im verzwichniss und bei svn checkt man einfach alles parallel aus...
|
|
|
|
|
|
|
Rotzt git eigentlich auch alles mit .git -Ordnern voll?
|
|
|
|
|
|
|
| Zitat von Noch_ein_Kamel das einzig "komische" find ich das branche wechseln bei git. da wechselt man die datein im verzwichniss und bei svn checkt man einfach alles parallel aus... | | wie meinst du das? | Zitat von cms Rotzt git eigentlich auch alles mit .git -Ordnern voll? | | nö. du kannst keine teilbäume auschecken, aber dafür gibt’s pro projekt nur einen .git-ordner im stammverzeichnis.
folge: du hast trotz lokalem repo tlw. kleinere clones als die entsprechende svn-arbeitskopie wäre.
|
|
|
|
|
|
|
| Zitat von TriggerTG
Was ist nochmal das Thema bei dir, Achsel?
| |
Entwicklung eines Softwaresystems zur Duplikaterkennung und
semiautomatischen Datenfusion
|
|
|
|
|
|
Thema: Gehirnsalat ( wir unter uns ) |