t-no schrieb:
Leider ist der Zug wohl abgefahren - git ist einfach zu übermächtig, und die meisten schauen sich Mercurial gar nicht erst an, obwohl es in einigen Punkten besser ist (oder zumindest war... git bleibt ja auch nicht stehen).Hat aber natürlich auch Vorteile, wenn man sich nicht mit zwei Lösungen befassen muss (wobei ich glaube, dass die Unterschiede bei den meisten Anwender-Szenarien überhaupt nicht ins Gewicht fallen)matz schrieb:
Dito, wir hatten in der alten Firma Mercurial mercurial.selenic.com
Fand ich aber garnicht mal so schlecht.
Source Control deaktivieren
Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen
-
-
matz schrieb:
nussratte schrieb:
macmoonshine schrieb:
Ich kann mir das auf der Arbeit leider nicht aussuchen.
Das soll mal einer verstehenIch weiß nicht immer wovon ich rede aber ich weiß das ich Recht habe. -
nussratte schrieb:
matz schrieb:
nussratte schrieb:
macmoonshine schrieb:
Ich kann mir das auf der Arbeit leider nicht aussuchen.
Das soll mal einer verstehen
Heul leise und nerv mich nicht mit deiner Meckerei -
Du bist der der im anderen Thema rum meckert. Aber nichts beiträgt und es hier genau so macht.
Will nur wissen nach welchen Kriterien man sich halten muss.Ich weiß nicht immer wovon ich rede aber ich weiß das ich Recht habe. -
Du hast Probleme, großartig.
-
beage schrieb:
Ich kopiere und benenne bei größeren Änderungen oder Erweiterungen den Projektordner um. ProjektX-20150927-1 oder so. Ich weiss, dass das total dämlich, umständlich und nicht zeitgemäß ist...
Beim Commit, das ich sehr oft durchführe, schaue ich häufig noch einmal genau auf die geänderten Passagen. Nein, eine Qualitätskontrolle ist das nicht, aber als Solo-Entwickler hat es mir erlaubt, den ein oder anderen potentiellen Bug im Vorfeld zu erkennen.
Ich code nicht ohne ... SCM
MattesDiese Seite bleibt aus technischen Gründen unbedruckt. -
MyMattes schrieb:
Beim Commit, das ich sehr oft durchführe, schaue ich häufig noch einmal genau auf die geänderten Passagen. Nein, eine Qualitätskontrolle ist das nicht, aber als Solo-Entwickler hat es mir erlaubt, den ein oder anderen potentiellen Bug im Vorfeld zu erkennen.
ChrisMan macht einfach solange irgendwelche Dinge, bis man tot ist.
Und dann bekommen die anderen Kuchen. -
Von Xcode zur Versionsverwaltung kann ich auch nur abraten. Für SVN verwende ich Versions.app, für GIT hab ich kurze Zeit GitX verwendet, dann auch SourceTree (keine ahnung warum ich das vorher nicht verwendet habe). Für Perforce kann man wohl nur die fürchterlichen Perforce-tools verwenden
Aber ohne Versionsverwaltung geht gar nix, auch bei webdevelopment und co sehr praktisch! -
Aja, und ganz wichtig: bugtracking-system und version-control verknüpfen, also bei jedem commit die bug-id mit angeben (bei Versions.app kann man diese mit # markieren sodass bei einem klick in der history genau der bug im bugtracking-system im browser geöffnet - geht bei anderer version-control software sicherlich auch).
-
Na klar, und die Versionen- / Build- Informationen beim Build automatisch aus dem Repository generieren, z. B. auf Basis von Tags und Commit-Zahlen. Finde ich genial, aber das hatten wir schon wiederholt in anderen Threads...
MattesDiese Seite bleibt aus technischen Gründen unbedruckt. -
MyMattes schrieb:
Na klar, und die Versionen- / Build- Informationen beim Build automatisch aus dem Repository generieren, z. B. auf Basis von Tags und Commit-Zahlen. Finde ich genial, aber das hatten wir schon wiederholt in anderen Threads...
Mattes
-
gritsch schrieb:
bugtracking-system und version-control verknüpfen
Ich hab' schon Gerüchte gehört, dass es da auf der dunklen Seite jede Menge Schnickschnack gibt, um die IDE in solche Abläufe zu integrieren.
Brauch' ich jetzt nicht unbedingt, aber eher als einen 3D-Editor in der IDE... -
t-no schrieb:
gritsch schrieb:
bugtracking-system und version-control verknüpfen
Brauch' ich jetzt nicht unbedingt, aber eher als einen 3D-Editor in der IDE...
aber warum will man sowas in dr IDE? sowas will ich als externes programm, dann bin ich von keinem plugin abhängig das bei jeder Xcode-version nicht mehr funktioniert oder gar die IDE selbst instabil macht. Außerdem habe ich mit einem eigenen prgramm die volle kontrolle darüber welche daten Xcode "im geheimen" editiert etc... -
Es ist auch einfach schöner und flexibler, die Bug ID in der Commit Message einzugeben als sich irgendwas in irgendwelchen PlugIns irgendwie zusammenzuklicken.
Vor Allem ist es total unabhängig von der IDE. Commit Messages kann ich nämlich nicht nur in Xcode (Was habt ihr alle dagegen? Änderungen comitten und reverten geht damit super. Alles Andere ist mitunter auch bei SourceTree eine Qual – zumindest wenn man das CLI liebt.) oder SourceTree oder Versions einpflegen. Nein, das geht auch auf der Kommandozeile.
Ich persönlich bin ja nach wie vor der Meinung, dass die Nutzung eines Prozesses (Hier: Versionsverwaltung) wichtiger ist als die Verwendung eines Tools.
Eine Lösung soll immer gleichbleibend und toolunabhängig funktionieren.
Git jedenfalls ist mit seinen etlichen GitHooks genau darauf ausgelegt, unabhängig von der Wahl des Visualisierungstools Automatismen anzubieten.«Applejack» "Don't you use your fancy mathematics to muddle the issue!"
Iä-86! Iä-64! Awavauatsh fthagn!
kmr schrieb:
Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
-
was hat es mit der Bug ID auf sich? das benutze ich anscheinend bisher nichtIch weiß nicht immer wovon ich rede aber ich weiß das ich Recht habe.
-
nussratte schrieb:
was hat es mit der Bug ID auf sich? das benutze ich anscheinend bisher nicht
-
ich hab mit Bugtrackern noch nicht gearbeitet,
was bringt das denn? im Bugtracker wird ein Bug eingetragen und das wird dann an ein Commit geklemmt bei dem was am Code geändert wurde?Ich weiß nicht immer wovon ich rede aber ich weiß das ich Recht habe. -
nussratte schrieb:
ich hab mit Bugtrackern noch nicht gearbeitet,
was bringt das denn? im Bugtracker wird ein Bug eingetragen und das wird dann an ein Commit geklemmt bei dem was am Code geändert wurde?
man hat also eine dokumentation, milestones, etc... -
MileStones, Release etc. mach ich einfach ein Tag
ich glaub ich muss mir Bugtracker mal anschauenIch weiß nicht immer wovon ich rede aber ich weiß das ich Recht habe. -
nussratte schrieb:
MileStones, Release etc. mach ich einfach ein Tag
ich glaub ich muss mir Bugtracker mal anschauen
du verstehst das falsch: du hast 20 neue features und 5 bugfixes. die kannst du dann zb einer neuen version zuordnen etc. dann wissen die betatester auch gleich was testen und vor allem wie weil ja die ganze diskussion in den jeweiligen threads enthalten ist. es gibt nicht einen "bugtracker" sondern x verschiedene systeme.