Welches SCM benutzt ihr?
-
Hatte vorhin was irgendwie komisches.
Ich habe in dev an meinen Libraries geschraubt, die letzten Tests abgeschlossen und war berteit für den nächsten "Release".
Der vorgang war bisher immer der selbe dafür, also unter SVN.- Version in der cs erhöhen.
- Änderungen in die Changelog eintragen.
- Alles in dev submitten.
- Nach main zurück mergen.
- Labeln mit der Version
- exe Bauen und publizieren.Nun war es in Git so, ich submitte alles nach dev, und switche zu main, dann sag ich in main, Merge from dev.
Dann kahm ne komische Message box, dort las ich dann am ende das nichts submitted wurde.
Die Ordner waren auch als geändert markiert.
Ich war es von SVN gewohnt das ich nun submitten muss, also es passte von der gewöhnung her.
Geh dann also auf submit to main, und da seh ich -> Keine änderungen.
Habe mit die Logs angeschaut, dort ist der letzte submit für dev und main eingetragen und es existiert noch ein "änderungen an den dateien".
Dem war aber nicht so, habe alles überprüft, die Dateien wurden anscheinend korrekt nach main submitted beim mergen, nur der Ordner zeigte wieder änderungen die nicht da wahren, ein Revert änderte die markierung wieder wie erwünscht, habe danach die Dateien geprüft und alles war wie erwartet sodas ich dann Labeln konnte.
Ich fand das nur sehr komisch das ganze....ALso bisher hatte ich mit Git:
2x Wurde mit bereits änderungen an den Dateien markiert wo keine wahren (auch Explorer neustart brachte nichts)
1x Wurde mir gesagt das nach dem Merge nichts submitted wurde obwohl es doch geschah
-
CSL schrieb:
2x Wurde mit bereits änderungen an den Dateien markiert wo keine wahren (auch Explorer neustart brachte nichts)
Das dürfte ein TortoiseGit-Bug sein, das hat mir ein Kollege auch schon berichtet.
1x Wurde mir gesagt das nach dem Merge nichts submitted wurde obwohl es doch geschah
Die genaue Abfolge und genaue Fehlermeldung wäre hierfür interessant. Vielleicht können wir ja irgendwelche Missverständnisse aufklären.
-
Leider kenn ich den genauen Inhalt der Message Box nicht mehr, ist dies irgendwo nieder geschrieben?
Es sah aus wie ein report, etwas kryptisch für Windows user, ich las aber in der letzten zeile das nichts submittiert wurde.Steps:
- Letzte änderung nach dev submitted,
- Nach master Branch geswitcht,
- "Merge" aufgerufen, dort dann dev ausgewählt,
- Message Box erscheint
- Ordner ist als geändert markiert wobei alles normal submitted wurde,
- "Revert" aufgerufen damit die Ordner wieder korrekt aussehen (und das vertrauen wieder da ist),
- Dateien geprüft ob auch alles vorhanden ist (dem war auch so),
- Gelabelt mit der neuen Version,Von Subversion bin ich es gewohnt das die Dateien nach dem Merge noch manuell submitted werden müssen.
//Dazuedit
Im Reflog finde ich den Wortlaut der letzten Zeile:
"Fast forward (no commit created; -m option ignored)"
ist als Aktion "Merge dev" eingetragen.
-
@CSL
Ist mit auch aufgefallen bei den ersten Versuche. Ein Merge von Master zu einem Branch ist nicht das gleiche wie ein Merge von einem Brach zum Master. Ledenfalls hat bei mir das Switch zu Branch und dann Mergen zum Master geklappt.
-
In TortoiseGit kann man doch gar nicht zu einem anderen Branch mergen, man kann nur sagen von welchen branch man Mergen will.
Dh man ist in dem Ziel Branch und holt sich den Source Branch rein.
Wenn ich in dev bin kann ich nicht sagen "Merge to main", lediglich "Merge from dev"
Ist bei SVN ja das gleiche.Wenn ich mir den Merge Dialog nochmal an schau sehe ich, dort gibt es eine "No Submit" CheckBox.
Am Ende war also nur das "no commit created" was mich verwirren lies.
-
Joa, das können wir aufklären.
Er sagt, dass er keinen Commit erzeugen musste, weil es so einen Commit schon gab, nämlich der letzte Commit in der dev Branch.Nachdem du dev von master abgebranched hast, waren beide identisch. Anschließend hast du weitere Commits in dev vorgenommen, aber keine weiteren in master. Wenn du nun dev zurück nach master mergen möchtest, reicht es aus den Pointer des obersten commits in master auf den obersten commit in dev zu setzen. Das nennt sich dann fast forward. Es gab einfach keinen Grund, einen neuen Commit zu erstellen, denn der wäre ja exakt identisch zu dem letzten Commit in dev. Trotzdem ist im Endergebnis alles so wie du es dir von dem Merge erhofft hast.
-
nman schrieb:
;fricky schrieb:
was ist daran schlimm? meinste, wenn der server mal nicht ereichbar ist?
Nein, das schlimmste ist, dass jeder Commit auch ein Publishing-Vorgang ist.
nicht weiter schlimm, da du ja zum entwickeln und experimentieren branches anlegen kannst bzw. releases sowieso 'getaggt' sind.
nman schrieb:
- Ich darf nur committen, wenn ich mir sicher bin, dass ich für andere nichts kaputt mache...
da geht nix kaputt, es ist ja gerade das wesen eines jeden VCS, dass du beliebige stände wieder hervorholen kannst. ausserdem klappts doch sowieso nicht, wenn mehrere entwickler unkoordiniert ein modul (oder gar dieselben dateien) bearbeiten. das verteilen von aufgaben und zuständigkeiten kann dir das beste VCS nicht abnehmen.
nman schrieb:
- Wenn ich im Flieger sitze oder irgendwo mitten in der Pampa, wo ich keinen Internetzugang habe, kann ich nicht committen, nicht updaten, nicht vernünftig Regressionen debuggen oä.
stimmt allerdings, aber wenn du offline versionskontrolle brauchst, tut's ja ein lokales VCS, wobei du dann wieder vor den gleichen problemchen stehst, wie mit allen lokalen kopien: wenn die pestflatte den geist aufgibt, oder dein schlepptopp geklaut wird...
-
nman schrieb:
- Ich darf nur committen, wenn ich mir sicher bin, dass ich für andere nichts kaputt mache, statt dann zu committen, wenn ich gerade einen Zustand erreicht habe, den ich irgendwie dokumentieren und festhalten möchte, bevor ich irgendwas anderes mache.
- Dadurch committe ich entweder sehr selten und arbeite dazwischen ohne Versionskontrolle oder mit manueller Versionskontrolle à la foo.c, foo.c.working, foo.c.working.old, … oder ich committe regelmäßig und störe andere Entwickler beim Arbeiten.Sehr merkwürdig... sobald leute git benutzen, scheinen sie zu vergessen, dass auch SVN sehr wohl branches kennt.
Das ist doch quatsch was du schreibst. Auch bei git musst du doch irgendwann deinen code in den "master" bringen. Und da musst du auch vorher sicherstellen, dass danach noch alles funktioniert. Nur haste bei git eben dein zeugs lokal und bei SVN im branch auf dem server. Was wiederum den vorteil hat, dass da auch ein kollege mal weiterarbeiten kann wenn du zB krank bist und all deinen code nur auf deinem rechner hast an den kein anderer rankommt...nman schrieb:
- Wenn ich im Flieger sitze oder irgendwo mitten in der Pampa, wo ich keinen Internetzugang habe, kann ich nicht committen, nicht updaten, nicht vernünftig Regressionen debuggen oä., weil ich keinen Zugriff auf alte Versionen habe.
Was aber nur dann ein nachteil ist, wenn man in der pampa arbeitet. Was eher für die wenigsten zutrifft.
nman schrieb:
- Jedesmal wenn ich an einem Feature arbeite und dabei irgendwo einen Bug finde, habe ich die Wahl, den gleich zu beheben und mit dem Feature-Commit zu vermischen, oder irgendwoanders das Repo auszuchecken, den Bug zu beheben und das zu committen, anstatt einfach bequem von der Feature-Branch wegzuwechseln oä.
Wieso das repo woanders auschecken? Normalerweise implementiert man features doch in einem branch, und den trunk hat man so oder so ausgecheckt. Da kannste ja den bug dann beheben. Oder wenn du das nicht im trunk machen willst, legste eben vom trunk schnell nen branch an, switcht vom trunk auf den neuen branch (was, da die ja quasi identisch sind, fix gehen sollte) und baust da deinen bugfix ein. Kannst du bei git denn nur teile einer datei commiten oder wie verhinderst du da dann das "vermischen" von feature und bugfix?
Irgendwie hab ich manchmal das gefühl, dass git-jünger alles vergessen, wenn es um die "konkurrenz" geht. Da werden manchmal nachteile erfunden, die keine sind, nur um die vorteile (die git sicher hat) stärker hervorzuheben. Da bekommt man fast angst. Offenbar führt git dazu, dass man vergisst wie das mit den branches in SVN funktioniert.
-
Hört doch mal auf, SVN zu verteidigen.
-
MasterK schrieb:
Nur haste bei git eben dein zeugs lokal und bei SVN im branch auf dem server. Was wiederum den vorteil hat, dass da auch ein kollege mal weiterarbeiten kann wenn du zB krank bist und all deinen code nur auf deinem rechner hast an den kein anderer rankommt...
bestimmt hat git eine eingebaute möglichkeite, lokale repositories mit anderen repositories des gleichen projekts (automatisch im hintergrund?) abzugleichen. sonst wär's ja witzlos. oder glaubst du etwa, git-user schicken sich geänderte files gezippt per e-mail zu? *fg*
-
Mit git kann man mittels dem push Befehl die Änderungen an ein Remote Repository übermitteln. Vorher sollte man aber noch ein Rebase durchführen um das lokale Repository auf den aktuellsten Stand zu bekommen.
-
guenni81 schrieb:
Mit git kann man mittels dem push Befehl die Änderungen an ein Remote Repository übermitteln. Vorher sollte man aber noch ein Rebase durchführen um das lokale Repository auf den aktuellsten Stand zu bekommen.
an ein remote repository? meinem verständnis nach ist git doch ein dezentrales system, demnach müssten sich alle doch irgendwie selbst synchronisieren (könnte vielleicht mit ähnlichen protokollen wie filesharing-systeme arbeiten). sowas wie ein 'master repository' ist ja wohl nicht nötig, oder?
-
Ja, git ist ein dezentrales System, was aber nicht heißt das man dennoch ein Zentrales Repository einrichten kann (muß man aber natürlich nicht). In git ist es möglich ein oder mehrere Remote Repositorys einrichten. Dies geschieht beispielsweise bei einem Clone aus einem vorhandenen Repository automatisch. Soweit ich weiß werden mittels dem push, fetch und pull Befehl nur die Änderungen an die anderen Repositorys übertragen bzw. geholt. Also automatisch aktualisieren darf ein solches System natürlich nicht, das wäre ja Katastrophal.
-
MasterK schrieb:
Was wiederum den vorteil hat, dass da auch ein kollege mal weiterarbeiten kann wenn du zB krank bist und all deinen code nur auf deinem rechner hast an den kein anderer rankommt...
Du kannst deine Branches auch in ein anderes Repository (zB auf einem zentralen Server) pushen.
MasterK schrieb:
Kannst du bei git denn nur teile einer datei commiten oder wie verhinderst du da dann das "vermischen" von feature und bugfix?
Ja. Wenn du willst kannst du explizit auswählen, welche Teile eines diffs in den commit sollen (git add -i bzw. mit der GUI deiner Wahl)
;fricky schrieb:
an ein remote repository? meinem verständnis nach ist git doch ein dezentrales system, demnach müssten sich alle doch irgendwie selbst synchronisieren (könnte vielleicht mit ähnlichen protokollen wie filesharing-systeme arbeiten).
Nein, so funktioniert das bei git nicht.
-
guenni81 schrieb:
Ja, git ist ein dezentrales System, was aber nicht heißt das man dennoch ein Zentrales Repository einrichten kann (muß man aber natürlich nicht).
aber wie machen sie's denn, dass die projekte nicht divergieren? z.b. projektstarter A beginnt, B klont von A, C klont von B und gibt änderungen brav zurück, B gibt änderungen aber niemals an A weiter, so dass A von B und C nichts mitbekommt. d.h. B und C sind mit A dauerhaft 'out of sync'. da muss doch irgendein system dahinterstecken, das sowas auschliesst.
-
Naja, da kommt der Workflow ins Spiel, da muss man sich erstmal auf einen einigen. Eine Möglichkeit ist zum Beispiel der zentrale Server, so wie es aus SVN bekannt ist. Dort holen Anwender Änderungen ab und dort hinterlassen sie ihre eigenen. Weitere Möglichkeiten sind hier gezeigt: http://whygitisbetterthanx.com/#any-workflow
Was man dort zum Beispiel machen kann, ist einen öffentlichen Server aufzustellen, von dem sich alle Änderungen holen bzw. das sie initial clonen. Dort schieben sie ihre eigenen Änderungen aber nicht rein. Statt dessen gibt es einen Integrator, der sich bei den Leuten die Änderungen holt und sie dann zu einem funktionierenden Stand zusammenbastelt und auf den Server schiebt von dem alle ihre Änderungen holen (Wenn ihm das zu kompliziert ist, kann er auch sagen: "Du nimm mal den stand hier und integriere dein zeuch da rein" und sich erst dann den Stand holen). Das ist ne schicke Sache, denn an keiner Stelle schreibt einer in ein fremdes Repository. Man muss sich nicht um Zugriffsrechte kümmern. Sagen wir beispielsweise wir haben ein OpenSource Projekt. Möchte jetzt ein User beitragen so kann er das öffentliche Repo clonen, dort beliebig rumfuhrwerken und irgendwann mal sagen: "Hey schaut mal hier, ich hab was cooles gemacht, integriert das doch bitte". Dann kann sich ein Integrator die Änderungen holen und integrieren. Will der User keinen server für sein Repo betreiben schickt er eben einen Patch. Die kann git aus Commits erstellen und die können dann beim Integrator schnell wieder in einer branch zu Commits werden (als hätte er sie einfach beim User abgerufen). Statt einen einzelnen Integrator zu haben kann man natürlich auch ne ganze Hierarchie aufstellen, so wird das afaik beim Linux Kernel gemacht.
-
;fricky schrieb:
guenni81 schrieb:
Ja, git ist ein dezentrales System, was aber nicht heißt das man dennoch ein Zentrales Repository einrichten kann (muß man aber natürlich nicht).
aber wie machen sie's denn, dass die projekte nicht divergieren? z.b. projektstarter A beginnt, B klont von A, C klont von B und gibt änderungen brav zurück, B gibt änderungen aber niemals an A weiter, so dass A von B und C nichts mitbekommt. d.h. B und C sind mit A dauerhaft 'out of sync'. da muss doch irgendein system dahinterstecken, das sowas auschliesst.
Deswegen haben die Commits in Git einen Sha-Hash. Das zwei unterschiedliche Commits den gleich Hash haben ist so gut wie ausgeschlossen und wird auch in der Praxis wohl nie passieren. Mit deinem Beispiel sehe ich gar keine Probleme. Wenn das ganze irgendwas ge-merge wird, gibt es halt paar merge-conflicts.
Die Sha-Hashs haben schon etliche Vorteile, gegenüber einer einfachen Nummerierung. Weil Commit-Inhalt=Sha-Hash ist, ist auch merge sehr viel schneller in Git. Nach 300 commits hast du eh die Übersicht über die Nummern verloren.
Zu Branches in SVN, die musst du aber auch öffentlich auf den Server machen. Ausserdem ist Mergen sehr schwierig in SVN, wogegen in Git mergen in Sekunden geht.
-
HyperSonic schrieb:
Was man dort zum Beispiel machen kann, ist einen öffentlichen Server aufzustellen, von dem sich alle Änderungen holen bzw. das sie initial clonen. Dort schieben sie ihre eigenen Änderungen aber nicht rein. Statt dessen gibt es einen Integrator, der sich bei den Leuten die Änderungen holt und sie dann zu einem funktionierenden Stand zusammenbastelt und auf den Server schiebt von dem alle ihre Änderungen holen (Wenn ihm das zu kompliziert ist, kann er auch sagen: "Du nimm mal den stand hier und integriere dein zeuch da rein" und sich erst dann den Stand holen).
und der 'integrator' ist ein mensch, d.h. hier ist handarbeit gefragt? in dem fall wird git nur wie eine 'lokale history' benutzt (hey, manche IDEs haben sowas standardmässig eingebaut *fg*, intelliJ z.b.). ausserdem hat man dann ja doch wieder ein zentralisiertes system (das zudem noch einen einem verwalter 'ne menge arbeit beschert). naja, nichts für ungut, aber ich dachte, auch nach der ganzen schwärmerei, in threads wie in diesem, dass git irgendwie intelligenter wär. aber danke für die gute erklärung.
btw, ich hab' auch mal bei wikipedia geschaut, da steht z.b., dass manche git so benutzen:Die Übertragung in das „offizielle Repository“ eines Projekts erfolgt häufig in Form von Patches, die via E-Mail an den Entwickler oder eine Entwicklungs-Mailing-Liste geschickt werden.
^^ na denn...
DEvent schrieb:
Deswegen haben die Commits in Git einen Sha-Hash. Das zwei unterschiedliche Commits den gleich Hash haben ist so gut wie ausgeschlossen und wird auch in der Praxis wohl nie passieren.
commits sind auch in herkömmlichen VCSs eindeutig, anders würde es doch garnicht gehen.
DEvent schrieb:
Die Sha-Hashs haben schon etliche Vorteile, gegenüber einer einfachen Nummerierung. Weil Commit-Inhalt=Sha-Hash ist, ist auch merge sehr viel schneller in Git.
git ist schneller, weil alles nur auf deinem rechner passiert. die handarbeit des menschlichen 'integrators' (siehe oben), wird wohl alles andere als schnell sein. *fg*
-
@;fricky
Integratoren wirst Du ja auch nur dann benutzen, wenn Du nicht jedem Hansel erlauben willst, ins Repository zu commiten. Dont call us, we call you! Nimm z.B. ein Open Source Projekt mit 100en "Commitern". Wenn die alle wie sie lustig sind, ins Repo commiten können, könnte es ziemlich chaotisch ablaufen. Da wärs sehr hilfreich, wenn einer oder wenige die Kontrolle haben, wer was wann commitet.
Bei "normalen" Projektteams mit einer überschaubaren Größe wirds wohl eher so laufen, dass es ein Master-Repository gibt, in das jeder seine Features und Bugfixes commiten kann, wenn sie fertig sind. Von dem Repo. werden dann die Nightly Builds gemacht bzw. dann die Releases.
-
byto schrieb:
Bei "normalen" Projektteams mit einer überschaubaren Größe wirds wohl eher so laufen, dass es ein Master-Repository gibt, in das jeder seine Features und Bugfixes commiten kann, wenn sie fertig sind.
das denke ich auch, commit-rechte beim server haben in der regel nur projektmitglieder, also alles wie gehabt, nur dass das, was bei SVN 'commit', bei git 'push' heisst und SVNs 'update' heisst unter git 'rebase' oder so ähnlich. man kann git also auch als ganz gewöhnliches, server-basiertes VCS nutzen. vorteil aber auch nachteil von git ist, dass eine lokale history mitläuft, was vielleicht viele dazu bringt, seltener kontakt mit dem 'main-repository' aufzunehmen. andererseits braucht man keine backups vom main-repository anzulegen, weil es sowieso als kopie auf jedem entwicklungsrechner vorhanden ist, aber wenn lokal was schiefgeht, ist gleich die arbeit (eines entwicklers) von mehreren tagen futsch.