Aus gegebenem Anlass: Wie ist am besten damit umzugehen wenn jemand im
beruflichen Umfeld der auch mit Programmieren befasst ist vehement den
Standpunkt vertritt es sei zu umständlich die Bedienung eines VCS zu
erlernen, es "lohne" sich daher nicht. Wie geht Ihr mit sowas um?
Überzeugungsarbeit leisten? Auslachen, umdrehen und weggehen? Ignorieren
und Thema wechseln? Ich bin echt am Ende mit meinem Latein, über den
Chef kann ich nicht gehen (will ich auch nicht) denn der ist der selben
Meinung ("lohnt" sich nicht [für ihn]) und fällt mir damit quasi auch
noch öffentlich in den Rücken statt mit gutem Beispiel voranzugehen.
Grad heute wieder so eine Situation gehabt wo das Gespräch zufällig das
Thema gestreift hat und sie sich sofort gegenseitig angefangen haben mit
ihrem Irrglauben den Rücken zu stärken, hab dann sofort das Thema
umgebogen bevor es wieder ausartet und das Frühstück nicht mehr
schmeckt.
Ich versteh das echt nicht, das sind alles hochintelligente Menschen und
scheitern dennoch an so einer simplen Kosten-Nutzen-Rechnung. Ich
vermute sie überschätzen den Aufwand und erkennen keinen Nutzen (so wie
der Blinde keine Farben erkennen kann). Gibt es irgendeine Strategie wie
man diese irrationale Blockade von außen überwinden kann, wie man z.B.
den Nutzen auf eine Weise erkennbar machen kann die sie auch von
innerhalb ihres augenblicklich eingeschränkten Denkmodells schon
deutlich wahrnehmen können?
Uraltes Gebet, passt für jede Religion: Gib mir die Kraft, zu ändern, was ich ändern muss. Gib mir die Geduld, zu ertragen, was ich nicht ändern kann. Gib mir die Weisheit, zwischen beidem zu unterscheiden. VCS ist gut, wenn man damit umgehen kann, und relativ einfach zu lernen. Dein Umfeld ist aber anderer Meinung, insbesondere der Chef. Also wirst du damit leben müssen oder die Stelle wechseln müssen. Es gibt schlimmere Probleme.
Bernd K. schrieb: > Aus gegebenem Anlass: Wie ist am besten damit umzugehen wenn jemand im > beruflichen Umfeld der auch mit Programmieren befasst ist vehement den > Standpunkt vertritt es sei zu umständlich die Bedienung eines VCS zu > erlernen, es "lohne" sich daher nicht. Wie geht Ihr mit sowas um Es gibt nicht ein VCS-Tool, es gibt viele. Und Computer-Tools sind nicht der einzige Weg Versionen zu verwalten, lass Dir doch vom VCS-Skeptiker seine preferierte Methode vorführen. Du kannst ihn/ihr ja ein Reinschnuppern ermöglichen, indem du ihm mal eins installierst und damit arbeiten lässt. Wenn er/sie keinen Vorteil erkennt da versuchts halt mit einem andere Frontend. Tortoise wäre IMHO ein Versuch auch bei VCS-Muffeln wert. Oder man lässt sich die Sourcen wie vom Muffel beliebt liefern und übernimmt das einchecken/builtflow selbst. Das da ja eh scripte machen ist der Extra-Aufwand gering und der Bürofrieden gerettet.
Abgesehen von der Befriedigung, die du dabei erfährst, in dem du hier deinem Ärger ein wenig Luft machst, bist du ja sicher an einer Lösung interessiert, aber es gibt so wenige Optionen, dass du sie dir quasi auch schon selbst beantworten kannst ;-) a) Ignorieren. Nimm es hin, du bekommst dein Geld trotzdem. Sieh es als teil deiner bezahlten Arbeit hin, gewisse Dinge einfach zu akzeptieren. Es hängt nicht allein an dir das Unternehmen groß zu machen! Und nun die passioniertere Variante: b) Versuche nachzuvollziehen, wo die Verständnisprobleme bei deinem Chef und deinen Kollegen bestehen. Versuche ihnen durch Beispiele zu erklären, wo, wann und warum eine Versionskontrolle sinnvoll ist. Untermauere das ganze ggf. mit einer kurzen Demonstration, wie einfach es ist, das zu erlernen. Letzendlich kannst du ja ganz klar darlegen, dass man einmal ein paar Stunden an Zeit investiert und dann dauerhaft von der Zeitersparnis profitieren kann. Am Ende der Diskussion hast du die beiden entweder überzeugt oder sie überzeugen dich, in dem sie stichhaltige Argumente bringen. Mach das ganze nicht in der Kaffeepause sondern bestelle sie zu einem Termin ein.
So ziemlich jede anständige IDE integriert doch heutzutage die Versionsverwaltung. Commit in Git oder SVN geht damit per Mausklick, ohne daß man sich in irgendwelche kruden Kommandozeilenbefehle einarbeiten muß. Und der Rest kommt dann ganz von alleine. Einer muß dann natürlich den Verwaltungstools-Admin und -Poweruser machen ;) Oliver
bitwurschtler schrieb: > Oder man lässt sich die Sourcen wie vom Muffel beliebt liefern und > übernimmt das einchecken/builtflow selbst. Das da ja eh scripte machen > ist der Extra-Aufwand gering und der Bürofrieden gerettet. Dann ist man irgendwann der Depp für alles... Wie wärs damit, für dich ein VCS zu benutzen, und so zu tun als würde der Kollege auch eins benutzen und als ob sein e-Mail Konto die Benutzeroberfläche wäre? Jedes Mal wenn du Einblick in eine alte Version brauchst, Versionen vergleichen oder mergen möchtest schreib ihm eine Mail dass er das für dich tun soll... Wenn er davon irgendwann genervt ist weise ihn freundlich darauf hin dass du das alles selbst tun könntest, wenn es ein zentrales Gitlab o.ä. gäbe!
Dann führe doch einfach ein VCS für Deine eigenen Arbeiten ein. Gerade Git lebt ja auch davon, dass eigentlich jeder Anwender seine eigenen Repositories verwendet, so dass man auch keinen "richtigen" Server aufsetzen muss. Eventuell stellen dann Deine Kollegen fest, dass Du damit tatsächlich viel bessere Auskünfte über Deine Arbeit liefern kannst und wollen dann irgendwann auch mitmachen. Schwierig wird es nur, wenn der Chef Dir explizit verbieten sollte, ein VCS einzusetzen. Ebenso schwierig kann es werden, wenn Du das VCS einführen sollst und Deine Kollegen wie die Aasgeier nur darauf warten, dass Du dabei einen winzigen Fehler machst, um anschließend die Nichtverwendung eines VCS für alle Zeiten in Stein zu meißeln.
Oliver S. schrieb: > Commit in Git oder SVN geht damit per Mausklick, > ohne daß man sich in irgendwelche kruden Kommandozeilenbefehle > einarbeiten muß. Wenn es ein VCS gibt, dann braucht man aber auch jemanden, der das administriert. Und das kann nur jemand sein, der sich richtig gut damit auskennt. * Auch und gerade auf der Command-Line. * Server-Seitig * Den Anwender bei Problemen hilft -- merge-Konflikte -- aus Versehen nen branch gelöscht -- was falsch eingecheckt -- Soll --force erlaubt sein? -- Wie wird committet / gepusht: wenn jemand nach jeder geänderten Zeile einen commit macht dann ist das für ihn lokal i.O., aber in der globalen Projekthistorie kann sowas zu sehr unübersuchtlich werden. Die sollte unabhängig von den Präferenzen einzelner Mitarbeiter sein. -- Wie werden Änderungen auf VCS-Ebene dokumentiert, und wie sind sie auuffindbar? u.v.a.m. Wenn man also vorschlägt, sowas wie GIT einzuführen, und es gibt niemanden, der als Administrator infrage kommt, dann ist der Vorschlag nicht sehr solide.
Frag doch Deinen Chef wie euer workflow sein soll. Wie viele Leute arbeiten gleichzeitig sm Code und wie werden derzeit die Ergebnisse zusammengesetzt? Nicht immer ist ein vcs noetig.
Moin,
ich dachte, die beratungsrenitente Spezies, was VCS angeht, sei langsam
in Pension gegangen..
Ist nun über 10 Jahre her, da gabs beim damaligen Arbeitgeber div.
Qualitätsprobleme und eine Menge Gewurschtel. Spätestens als man
angefangen hat, sich um Zuordnung von Revisionen/Chargen/Seriennummern
und Testreports kümmern musste (ISO 9000-Schiessmichtot), stand das
Wasser an den Hälsen.
Das lässt sich dann bisschen als Druckmittel hernehmen, wenn auch
schliesslich eine Menge Papier ausgedruckt wird, und die VCS keinen
Zertifizierer interessiert (hat).
Wenn der Chef die einfache Amortisationsrechnung betr. VCS nicht
hinbekommt, und sogar Tortoise für Windows als "zu kompliziert" gilt,
würde ich einfach für meinen eigenen Code ein git-Tracking einrichten.
Und renitente Kollegen kann man ruhig mal auflaufen lassen ("Nicht meine
Baustelle"). Irgendwann muss dann auch ein Chef seine Aufgaben
übernehmen, spätestens dann, wenn wochenlang nach einem Fehler gesucht
werden muss, weil man irgendwo was verändert, aber vergessen hat.
Bei ner kleinen Bude kann man schon mal forsch sagen "Chef, ich will
SOFORT ein SVN". Bei ner verkrusteten Abteilung hilft wohl nur: Klappe
halten und rumpimmeln wie die andern :-)
Bernd K. schrieb: > Wie ist am besten damit umzugehen wenn jemand im > beruflichen Umfeld der auch mit Programmieren befasst ist vehement den > Standpunkt vertritt es sei zu umständlich die Bedienung eines VCS zu > erlernen, es "lohne" sich daher nicht. Wie geht Ihr mit sowas um? Er hat recht. Bernd K. schrieb: > Überzeugungsarbeit leisten? Auslachen, umdrehen und weggehen? Ignorieren > und Thema wechseln? Ich bin echt am Ende mit meinem Latein, Bewundere ihn für seine Standhaftigkeit. Nicht daß Versionskontrollsysteme und Archivierungssysteme schlecht wären, es ist super nützlich wenn die Arbeit gesichert ist und man jederzeit nachgucken kann welche Änderungen man wann gemacht hat. Aber die aktuellen Implementationen, von SourceSafe über CVS und GIT sind - extrem umständlich in der Bedienung, teilweise mit völlig hirnlosem Konzept (wie kommt man z.B. auf die krankte Idee, bei jedem Einchecken Kommentare schreiben zu müssne, Kommentare stehen schon im eingecheckten code, und damit dort wo sie hingehören und man sieht sie sofort beim Verleich und nicht nur dann) - wimmeln vor Fehlern, sind also defekt - beliebt z.B. der Bug von CVS mit Gross/Kleinschreibung - beliebt bei Git die Eclipse Oberfläche die nur halb funktioniert - beliebt das Veränderung von Datei-timestamps - langsam, es werden teilweise Dateien doppelt übertragen, oder übertragen obwohl nicht nötig - bringen wenig Nutzen und machen viel Arbeit und erlauben oftmals mit wenigen 'unbedachten/verweifelten' Klicks eine komplette Zerstörung Das müsste gar nicht sein, es gab mal ein schlicht und einfach gut funktionierendes System, das kopierte still und leise im Hintergrund die Arbeitsverzeichnisse weg, so daß in der täglichen Arbeit KEINERLEI Zusatzaufwand anfiel, und wenn man wirklich mal (was ja selten vorkommt) die Änderungshistorie und Altversionen haben wollte, konnte man die mit einem Tool jederzeit (leicht in ein anderes Verzeichnis) auschecken. Leider unter DOS. Nur wenn wirklich mal 2 Leute gleichzeitig was geändert hatten, gab es eine Meldung. Branches hat man gemacht, in dem man im Arbeitsverzeichnis das Directory kopiert hat und später händisch zuückmergte, da hat sich also das System rausgehalten. Bloss den Namen hab ich vergessen, MVS ? Ich glaube mich zu erinnern, daß es Novell erforderte.
Michael B. schrieb: > Er hat recht. Was für Kraut baust du eigentlich in deinem Garten an? Oder ist die Chlordosierung in deinem Swimming Pool zu hoch eingestellt? Michael B. schrieb: > Aber die aktuellen Implementationen, von SourceSafe über CVS und GIT > sind Unglaublich, dass Millionen von Entwicklern auf dem Globus verteilt ohne Probleme damit umgehen können und große Softwarebuden Repositories mit 10^9 LOC und mehr verwalten können. Aber der Öff Öff des Forums weiß es wie immer besser.
Michael B. schrieb: > Aber die aktuellen Implementationen, von SourceSafe über CVS und GIT > sind ... völlig veraltet. Visual SourceSafe wurde von Microsoft schon vor vielen Jahren ersatzlos in die Tonne gekloppt. Und CVS ist nun auch nicht mehr allzu frisch, d.h. seit etwa 15 Jahren setzt man damit keine neuen Repositories mehr auf, sofern es keinen zwingenden Kompatibilitätsgrund gibt. Allerdings setzt noch einer unseren Kunden tatsächlich CVS für viele Aufgaben ein, wobei dessen Projekte Schritt für Schritt nach Git migriert werden. Subversion hat sich auch als CVS-Nachfolger sehr bewährt, wobei recht viele Leute diese Nachfolge einfach als neue Programmversion ansahen und sich dann lauthals beschwerten, als sie feststellen mussten, dass Subversion teilweise andere Kommandos und Konzepte als CVS hat. Allerdings halte ich den verteilten Ansatz von Git auch nur dann für sinnvoll, wenn man tatsächlich verteilt arbeiten muss. Ansonsten bringt Git für viele Normalanwender nur einen unnötigen Overhead mit und ist erklärungsbedürftig. Der einzige Vorteil in zentralisierten Umgebungen besteht darin, dass man auch rein lokal einchecken kann, ohne dass alle Vorgänge gleich auf dem zentralen VCS sichtbar werden. Die ganz große Gefahren bestehen meines Erachtens aber darin, dass entweder vergessen wird, einen Push durchzuführen, oder ganze Entwicklungszweige auf einem nicht der zentralen Datensicherung unterworfenen Rechner liegen und bei einem Defekt oder einer Neuinstallation unwiederbringlich verlorengehen können.
Wenn du die Möglichkeit hast: -Verwalte deinen Kram in einem VCS deiner Wahl -Lass deinen Kollegen seinen Kram halten wie er will -Wenn dir der Kollege zuarbeitet, versioniere seinen Kram in einem Ordner bei dir, unabhängig von deinem Du kannst in Ruhe arbeiten, und alles ist schick. Wenn es Probleme gibt und du von deinem Kollegen wissen willst was er vor drei Wochen geändert hat weil etwas nicht mehr läuft, läßt du ihm das dann auf die Füße fallen bzw. die Änderungen manuell suchen. Du wirst ihm NICHT deine VCS-Kopie seiner Arbeit zur Verfügung stellen-er darf sich dann selber seinen Mist zusammenreimen. Wenn du die Möglichkeit nicht hast, würde ich mal den Arbeitsmarkt sondieren. Mir persönlich widerstrebt diese Art von Unprofessionalität. Und sowas wie SVN zu 'erlernen' sollte definitiv nicht zuviel verlangt sein, jedenfalls nicht von Ingenieuren. Für derlei Verweigerungshaltung fehlt mir das Verständnis. Wir haben bei uns das gleiche Problem, allerdings zwischen Mechanikabteilung und Elektronikentwicklung. Die Mechaniker nutzen zur Versionssicherung lieber die Unterordnerfunktion des Windowsexplorers, während wir sämtliche Projektdateien (für Altium, LTSpice, ggb. Labview und wasweißichnichtnochalles) lieber in einem SVN-Repository halten und haben im letzten Jahr da unser eigens Ding aufgezogen.
Bernd K. schrieb: > Überzeugungsarbeit leisten? Nur, wenn Diskussionsbereitschaft vorhanden ist. Sonst nicht. > Ich versteh das echt nicht, das sind alles hochintelligente > Menschen Das besagt gar nichts. C ist auch von hochintelligenten Menschen entwickelt worden... > Gibt es irgendeine Strategie wie man diese irrationale > Blockade von außen überwinden kann, Kurze Antwort: Nein. Längere Antwort: Meine Mutter pflegte immer zu sagen "Erziehung ist Beispiel und Liebe". Es hat sehr lange gedauert, bis ich erkannt hatte, dass das nicht einfach ein Spruch ist, sondern eine Weisheit (die übrigens von Fröbel stammt). Teilaspekt "Liebe": * Verstehen, warum Deine Kollegen Vorbehalte haben. Scheuen sie wirklichen den Aufwand? Oder sehen sie den Nutzen nicht? Möchten sie sich evtl. nur nicht bloßgestellt fühlen, weil sie ja am Anfang keine Ahnung vom VCS haben und Hilfe benötigen werden? * Alles vermeiden (aufrichtig! nicht nur zum Schein!), was nach Konfrontation, Eskalation, Sieg&Niederlage aussieht. * Geduld haben. Ich habe früher dem kindlichen Irrglauben angehangen, eine Wirklich Gute Idee (tm) würde sofort von allen als solche erkannt und begeistert begrüßt. Normalerweise ist aber das genaue Gegenteil der Fall. > wie man z.B. den Nutzen auf eine Weise erkennbar machen > kann die sie auch von innerhalb ihres augenblicklich > eingeschränkten Denkmodells schon deutlich wahrnehmen > können? Durch das persönliche Beispiel. Niemand wird gern seine eigene Arbeitsweise ändern, nur weil Du ihm klarzumachen versuchst, dass seine Arbeitsmethodik veraltet und überholt ist. Wenn Du aber ein VCS verwendest, gute Arbeit leistest und die Kollegen gern mit Dir zusammenarbeiten, sind die Vorbehalte nicht mehr ganz so groß. Wenn das VCS die Arbeit WIRKLICH erleichtert, werden die Kollegen -- ganz ohne dass Du ihnen das ständig unter die Nase reibst -- merken, dass ein VCS etwas bringt. Im günstigsten Falle wollen sie es dann selbst einsetzen, im nicht ganz so günstigen nehmen sie in ihrer Arbeit Rücksicht auf Dich und Dein VCS (aber auch das wäre ja ein Fortschritt). Es hat letztlich wenig Sinn, von anderen Änderungen zu verlangen -- wirksamer ist, selbst voranzugehen und zu versuchen, die Anderen mitzunehmen.
Wühlhase schrieb: > Wenn es Probleme gibt und du von deinem Kollegen wissen > willst was er vor drei Wochen geändert hat weil etwas > nicht mehr läuft, läßt du ihm das dann auf die Füße > fallen bzw. die Änderungen manuell suchen. Du wirst ihm > NICHT deine VCS-Kopie seiner Arbeit zur Verfügung stellen - > er darf sich dann selber seinen Mist zusammenreimen. Ja, das ist der optimale Weg, sich als unkollegialer Stänkerer zu profilieren. > Wir haben bei uns das gleiche Problem, allerdings > zwischen Mechanikabteilung und Elektronikentwicklung. Das ist recht witzig. Ich kenne die Reibereien zwischen Mechanik und Elektronik auch. > Die Mechaniker nutzen zur Versionssicherung lieber die > Unterordnerfunktion des Windowsexplorers, während wir > sämtliche Projektdateien (für Altium, LTSpice, ggb. > Labview und wasweißichnichtnochalles) lieber in einem > SVN-Repository halten und haben im letzten Jahr da unser > eigens Ding aufgezogen. Dass eure Mechaniker vielleicht eure kollegiale Hilfe statt des Hochmutes gebraucht hätten, kommt Dir nicht in den Sinn?
Possetitjel schrieb: > das ist der optimale Weg, sich als Mit der ISO 9000-Geschichte sollte man eigentlich seine Arbeiten zur Qulitätssicherung dokumentieren müssen. Wahrscheinlich kämpft das obige Unternehmen noch mit der Zertifizierung?
Possetitjel schrieb: > Dass eure Mechaniker vielleicht eure kollegiale Hilfe statt > des Hochmutes gebraucht hätten, kommt Dir nicht in den Sinn? Die wollen die Ratschläge der Software-Experten doch offenbar nicht hören. Das kenn ich von Ingenieuren auch, die machen alles mit Excel und Dropbox und nehmen softwaretechnische Ratschläge von Informatikern am Allerwenigsten an - es sei denn etwas funktioniert nicht, dann heißt es "Wie geht das in VBA"?
Bernd K. schrieb: > Ich versteh das echt nicht, das sind alles hochintelligente Menschen und > scheitern dennoch an so einer simplen Kosten-Nutzen-Rechnung. Ich > vermute sie überschätzen den Aufwand und erkennen keinen Nutzen (so wie > der Blinde keine Farben erkennen kann). Ich denke genau das ist der springende Punkt. Dein Kollege denkt sich:"Git ist doch nur irgendein Kommandozeilenvodoo was kein Mensch versteht." (Siehe Johanns Post mit dem xkcd Comic) Und dein Chef denkt sich:"VCS, das ist doch nur wieder mit zusätzlichem Aufwand und damit Kosten verbunden. Da kann ich dann gleich noch einen Datenbankadministrator einstellen, der alles verwaltet." Beide haben irgendwie ein bisschen Recht, obwohl sie eigentlich falsch liegen. Ich habe letztens zwei Kollegen ein bisschen mit Git vertraut gemacht, die davon schonmal etwas gehört hatten und grundsätzlich wissbegierig waren (was ja definitiv eine gute Voraussetzung ist). Beides waren jedoch typische Windowsnutzer und als ich anfing ihnen Git zu zeigen wie ich es hauptsächlich benutze (nämlich aus der Konsole heraus) haben beide nur mit den Augen gerollt. Zum Glück hat dann einer gefragt "ob es da nicht auch irgendwas mit einer GUI" gäbe und beide waren happy als ich ihnen dann den Rest anhand des Git-GUI erklärt habe. Das war definitiv ein Fehler meinerseits, das nicht gleich so zu machen und ich kann mir gut vorstellen, dass ich andere Leute in dem Moment schon "verloren" hätte. Was auch bei beiden sehr gut ankam (und ich erinnere mich, dass mich das selbst sehr positiv überrascht hatte als ich in deren Situation war), war die Tatsache, das die komplette Historie einfach lokal in einem .git-Ordner liegt und man somit den Projektordner wie man möchte kopieren, verschieben oder sichern kann, ohne das die Historie verloren geht. Außerdem fanden es beide sehr positiv, das man keinen Server oder ähnliches aufsetzen muss. Was ich damit sagen will ist, dass man eben manchmal auch über den Tellerrand hinaus schauen muss und sich in den anderen hineinversetzen, so wie das Possetitjel ganz treffend beschrieben hat. Wenn du deinen Kollegen davon überzeugen kannst, das Git nicht weh tut und auch kein Hexenwerk in der Bedienung ist (sofern man denn nur ganz grundsätzliche Funktionen nutzt, also nur wie SVN ein Commit nach dem nächsten) und das es z.B. mit TortoiseGit auch für einen Anfänger sehr leicht bedienbar ist, dann hast du eventuell eine Chance. Was den Chef angeht fallen mir als erstes direkt die Stichworte "Kostenreduzierung" und "Risikominimierung" ein. Ich meine der absolute Klassiker ist doch, dass man irgendwo eine Änderung vornimmt und dann auf einmal nichts mehr funktioniert und man sich einen Wolf sucht, bis man wieder da ist, wo man ja eigentlich schon vorher war, was eindeutig unnötige Kosten verursacht. Der andere Vorteil ist, dass durch die Commit-Messages (wenn sie denn vernünftig sind) eine grundlegende Dokumentation vorhanden ist. Was passiert denn wenn ein Kollege morgen auf tragische Weise bei einem Autounfall stirbt? Ja, klingt vielleicht ein bisschen übertrieben aber ich denke, dass das die Sachen sind mit denen man einen typischen BWLer überzeugen kann.
Andreas S. schrieb: > Dann führe doch einfach ein VCS für Deine eigenen Arbeiten ein. Gerade > Git lebt ja auch davon, dass eigentlich jeder Anwender seine eigenen > Repositories verwendet, so dass man auch keinen "richtigen" Server > aufsetzen muss. Mach ich bereits seit 2 Jahren. > Eventuell stellen dann Deine Kollegen fest, dass Du > damit tatsächlich viel bessere Auskünfte über Deine Arbeit liefern > kannst und wollen dann irgendwann auch mitmachen. ALLE finden es natürlich vorteilhaft daß ich den irrsinnigen und wachsenden Berg von Code und Daten (noch) im Griff habe und aus dem Handgelenk ein dutzend Projekte mit teilweise unterschiedlichen Varianten und unterschiedlichen noch in Produktion befindlichen alten Zweigen noch pflegen kann und bei jeder popeligen Änderung der letzten Jahre exakt nachvollziehen kann wann ich sie gemacht habe, WARUM ich sie gemacht habe, wann sie in Produktion gegangen ist, auf welcher Hardwareversion das war (samt Schaltplan und Layout) und ob es geregnet oder geschneit hat an dem Tag, aber NIEMAND interessiert sich dafür wie ich das mache und warum ich es so mache wie ich es mache. Ich erwarte nicht daß sich alle zu absoluten git-Experten entwickeln die mit einer Hand auf den Rücken gebunden 2 Kernel branches mergen konnten. Wenn jemand Mergekonflikte hat komm ich gerne und biege das wieder gerade. Das zeigt mir wenigstens daß derjenige zumindest versucht das Tool zu benutzen, mithin also Interesse daran zeigt zu verstehen wie man das macht und was da vor sich geht! Aber ich erwarte zumindest daß wenn mich jemand fragt "wo ist denn dies oder jenes von xyz projekt" daß ich dann einfach antworten kann: "das findest du [wie immer] im xyz repository in diesem branch in jenem ordner" und dann nicht gleich noch als zweites eine Bitte kommt wie "Äh, das ist mir jetzt zu kompliziert, das kann ich doch nicht, kannst Du mir das bitte schnell auschecken und auf das netzlaufwerk legen und mir dann bescheid sagen? Danke!". Hallo? Wenn alle die es wissen müssten wissen wie das funktioniert und wo was ist erleichtert es mir die Arbeit und ich kann entspannter in Urlaub fahren! Wohlgemerkt, es geht um Leute die selbst auch mit Entwicklung befasst sind, nur von denen erwarte ich zumindest minimales Interesse daran was das für ein Ding ist das das alles noch zusammenhält und wie man es wenigstens grundlegend benutzt, das würde auch schon reichen. Aber es ist immer gerade "jetzt" zu kompliziert. Jedesmal ist es genau jetzt zu kompliziert! Und danach ist es wieder "nicht nötig". Wo ist der Wissensdrang geblieben? Was neues gesehen: rausfinden was das ist, was es macht, versuchen zu verstehen wie es funktioniert! Ausprobieren wollen! Wo ist das alles geblieben? Ich habs noch. Warum habens die anderen verloren?
Dr. Sommer schrieb: > Possetitjel schrieb: >> Dass eure Mechaniker vielleicht eure kollegiale Hilfe statt >> des Hochmutes gebraucht hätten, kommt Dir nicht in den Sinn? > > Die wollen die Ratschläge der Software-Experten doch offenbar nicht > hören. Das kenn ich von Ingenieuren auch, die machen alles mit Excel und > Dropbox und nehmen softwaretechnische Ratschläge von Informatikern am > Allerwenigsten an - es sei denn etwas funktioniert nicht, dann heißt es > "Wie geht das in VBA"? Oder einfach nur eine CAD-Software, die eine Versionskontrolle untrstützt?! Wenn man eine Bohrung ändert, dann ändert, dann ändern sich bei manchen CAD-Programmen alle Dateien. Da treibt einen JEDE Versionskontrollsoftware zum Wahnsinn.
Bernd K. schrieb: > Wo ist das alles geblieben? Ich habs noch. Warum > habens die anderen verloren? Sie haben bestimmt Angst alles in einen "Write Only-Speicher" zu versenken, wovor sie später hilflos stehen (weil SW od. DB defekt). Eine irgendwasProjekt.txt in einem Ordner schieben wäre denen wahrscheinlich lieber. Frage ist bloß wer DORT Ordnung schafft. Solche Ordner sehen später schlimmer aus, als die Kaffeeküche zum Feierabend. Die KK kann jede Putzfrau aufräumen, für einen Ordner braucht es dagegen Sachkenntnis was man wirklich wegwerfen kann.
So einen Chef hatte ich auch mal. Habe dann einfach ein svn repository für mein Zeug aufgesetzt.
Für unsere alte Software (vb6) nutzen wir traditionell sourcesafe, für neue Projekte (Python) nutze ich (für mich) git. Ich habe auch schon Mal das sourcesafe Projekt nach git konvertiert, aber daran hatte niemand ein richtiges Interesse. Hauptsächlich erstelle ich SPS Software (Siemens step7). Und da gibt es meines Wissens leider keins komfortable Möglichkeit zur Versionübung. Dafür wird in alter Ingenieursmanier good old Excel verwendet. Ich kann nicht fassen, dass Siemens nicht Mal in der Neuentwicklung der SPS software (tia Portal) irgendeine Art der "modernen" Versionortung vorgesehen hat. Eigentlich machen wir alles in Excel: To-Do, Projekttagebuch, Versionshistorie, Maschinenübersicht, flowcharts ... ALLES :( Der Abteilungsleiter verlangt sogar zusätzlich zum sourcesafe eine versionierungsübersicht als ..... Richtig! Excel-Tabelle autsch das hat man, wenn der Chef aus der SPS Ecke kommt ..
Christopher J. schrieb: > Ich habe letztens zwei Kollegen ein bisschen mit Git vertraut > gemacht, die davon schonmal etwas gehört hatten und grundsätzlich > wissbegierig waren (was ja definitiv eine gute Voraussetzung ist). > Beides waren jedoch typische Windowsnutzer und als ich anfing ihnen Git > zu zeigen wie ich es hauptsächlich benutze (nämlich aus der Konsole > heraus) haben beide nur mit den Augen gerollt. Zum Glück hat dann einer > gefragt "ob es da nicht auch irgendwas mit einer GUI" gäbe und .... Ich bin vor ziemlich genau zehn Jahren von CVS, das ich bis dahin über viele Jahre hinweg unter unixoiden OS sowie unter Windows per Kommandozeile benutzt hatte, auf Mercurial umgestiegen, genauer gesagt, auf das schon damals unter Windows sehr gut funktionierende GUI TortoiseHg. Ein auch nur halbwegs brauchbares Git für Windows, insb. aber ein GUI dafür war damals noch Zukunftsmusik. Auch heute ziehe ich Mercurial für eigene, kleine Projekte Git vor. Wenn es darum geht, plattformübergreifend ohne viele Umstände gleich mit einem DVCS starten zu können, ist das m.E. immer noch die bessere, weil genau so leistungsfähige, aber unkompliziertere Wahl. Falls sich ein kleines Projekt dann auswächst und man deswegen dem Trend hinterherlaufen muß, kann man immer noch unter Erhalt der Historie konvertieren. Auch von meinen alten, nach Mercurial migrierten CVS-Projekten - die ich nur bei Bedarf konvertiere - habe ich deren Historie natürlich noch. Zu dieser Herangehensweise habe ich in den vergangenen zehn Jahren ebenfalls den einen oder anderen Windows-Nutzer aus meinem Dunstkreis motivieren können. Zu bedenken ist, daß viele Entwickler heutzutage keine Kernel-Entwickler sind, ja nicht mal wirklich Entwickler im Wortsinne - das Herumschrauben an Software ist ja häufig nur sekundäres Mittel zu einem primären Zweck - Bildbearbeitung, Konstruktion, Tonstudio, scientific computing etc. pp. Da sind die Leute Experte, nicht, was Softwareentwicklungswerkzeuge angeht. Erster Schritt war dann einfach der Vorschlag, aus einem Projektverzeichnis erst mal ein Repository zu machen, sich zu überlegen, welche Dateien man versionieren möchte und dann einfach mit einer linearen Historie loszulegen, d.h. zu einem geeigneten Zeitpunkt einen Commit zu starten. Schon der im Gui präsentierte graphische Diff war für Neulinge auf diesem Terrain gelegentlich ein regelrechter Lichtblick und motivierend. Manchmal ergibt sich dann auch die Gelegenheit, das D in DVCS zu demonstrieren, entlang von "da müsste ich mal genauer reinschauen, darf ich mir gerade mal einen Clone ziehen? Wenn ich den Fehler bzw. eine Lösung finde, schick' ich Dir den Patch". Das zieht dann die Frage "was mach' ich denn dann damit?" nach sich und schon ist man bei der Frage, was ein "Merge" ist. Ab dem Punkt kommen die Leute dann meistens von ganz alleine zurecht. Motivation ist alles. :-)
Possetitjel schrieb: > Wühlhase schrieb: > >> Wenn es Probleme gibt und du von deinem Kollegen wissen >> willst was er vor drei Wochen geändert hat weil etwas >> nicht mehr läuft, läßt du ihm das dann auf die Füße >> fallen bzw. die Änderungen manuell suchen. Du wirst ihm >> NICHT deine VCS-Kopie seiner Arbeit zur Verfügung stellen - >> er darf sich dann selber seinen Mist zusammenreimen. > > Ja, das ist der optimale Weg, sich als unkollegialer > Stänkerer zu profilieren. So unkollegial bin ich gar nicht wie das da oben rüberkam. Aber wie gesagt, für Stümperei und mangelndem Willen, etwaige Schmerzen abzustellen, hab ich wenig Verständnis. Wenn jemand unbedingt meint einen Faustkeil zu benutzen, obwohl andere ihm für wenig oder gar kein Geld einen prima Werkzeugkasten entwickelt haben...ich kann das nicht nachvollziehen. Und durch Schmerz lernt der Mensch am intensivsten...zumindest intensiv. Und wenn ich lese was der TS weiter schreibt und Git fleißig für seine Kollegen bedient, dann scheint es höchste Zeit zu sein etwas zu ändern. Den Wert eines VCS scheinen seine Kollegen ja oft genug vorgeführt zu bekommen. Possetitjel schrieb: >> Wir haben bei uns das gleiche Problem, allerdings >> zwischen Mechanikabteilung und Elektronikentwicklung. > > Das ist recht witzig. > Ich kenne die Reibereien zwischen Mechanik und Elektronik > auch. > >> Die Mechaniker nutzen zur Versionssicherung lieber die >> Unterordnerfunktion des Windowsexplorers, während wir >> sämtliche Projektdateien (für Altium, LTSpice, ggb. >> Labview und wasweißichnichtnochalles) lieber in einem >> SVN-Repository halten und haben im letzten Jahr da unser >> eigens Ding aufgezogen. > > Dass eure Mechaniker vielleicht eure kollegiale Hilfe statt > des Hochmutes gebraucht hätten, kommt Dir nicht in den Sinn? An kollegialer Hilfe hätte es nicht gemangelt. Ich persönlich gebe mein Wissen gerne weiter, allerdings war das Thema schon durch bevor ich in dieser Firma angefangen habe. Und SVN zu bedienen ist nun wahrlich nicht so schwer. Das ist in wenigen Minuten erklärt.
Bernd K. schrieb: > ALLE finden es natürlich vorteilhaft daß ich den irrsinnigen und > wachsenden Berg von Code und Daten (noch) im Griff habe und aus dem > Handgelenk ein dutzend Projekte mit teilweise unterschiedlichen > Varianten und unterschiedlichen noch in Produktion befindlichen alten > Zweigen noch pflegen kann und bei jeder popeligen Änderung der letzten > Jahre exakt nachvollziehen kann wann ich sie gemacht habe, WARUM ich sie > gemacht habe, wann sie in Produktion gegangen ist, auf welcher > Hardwareversion das war (samt Schaltplan und Layout) und ob es geregnet > oder geschneit hat an dem Tag, aber NIEMAND interessiert sich dafür wie > ich das mache und warum ich es so mache wie ich es mache. Na wenn die Sache so aussieht, dann sollte es doch ein leichtes sein, deinen Chef davon zu überzeugen. Frag ihn einfach mal ob er weiß was ein Busfaktor ist und erkläre ihm dann, das dieser bei euch ziemlich genau exakt 1 beträgt (in Worten EINS ;) Bernd K. schrieb: > Wenn jemand Mergekonflikte hat komm ich gerne und biege das wieder > gerade. Das zeigt mir wenigstens daß derjenige zumindest versucht das > Tool zu benutzen, mithin also Interesse daran zeigt zu verstehen wie man > das macht und was da vor sich geht! Ich denke der erste Schritt sollte sein, dass einfach jeder seinen Kram überhaupt versioniert. Wenn jeder vor der Mittagspause und vor Feierabend einen Commit mit einer vernünftigen Commit-Message macht, dann währe das meiner Meinung nach ein erster Schritt. Zwar ein ganz kleiner Schritt aber auch ein sehr wichtiger. Branch, Merge, Rebase und was Git sonst noch alles kann, das würde ich machen wenn der erste Schritt getan ist. Wolfgang S. schrieb: > Ein auch nur halbwegs brauchbares Git für Windows, insb. aber ein GUI > dafür war damals noch Zukunftsmusik. Auch heute ziehe ich Mercurial für > eigene, kleine Projekte Git vor. Mercurial habe ich selber nie benutzt aber ich kann mir gut vorstellen das es mit Git gut vergleichbar ist. Das einzige andere VCS was ich längere Zeit effektiv genutzt habe war SVN. Ist zwar sehr einfach zu bedienen, kann aber halt auch nicht so viel. Von CVS habe ich nur Schaudergeschichten gehört und von SourceSafe kannte ich nicht mal den Namen aber ich möchte allen die das beruflich nutzen müssen hiermit mein herzliches Beileid aussprechen ;)
Johann L. schrieb: > Wenn man also vorschlägt, sowas wie GIT einzuführen, und es gibt > niemanden, der als Administrator infrage kommt, dann ist der Vorschlag > nicht sehr solide. Du kannst ja mal raten, wenn ich dafür im Sinn hatte. Da muß der TO halt durch. Oliver
Jupp. Und außerhalb der Softwerker-Welt nutzt "man" Office im "Änderungen nachverfolgen"-Modus (und hält das schon für absolut genial). Irgendeine arme Sau verbringt dann Tage damit, die Änderungen von 20 Leuten in das Master-Dokument einzupflegen, und ausgerechnet die wichtigste Änderung vom Chef geht verloren. That's life. Aber Menschen verdienen Geld nicht damit, eine Aufgabe besonders effizient zu erledigen, sondern sie effektiv zu verkaufen. MfG, Arno
Dr. Sommer schrieb: > Possetitjel schrieb: >> Dass eure Mechaniker vielleicht eure kollegiale >> Hilfe statt des Hochmutes gebraucht hätten, kommt >> Dir nicht in den Sinn? > > Die wollen die Ratschläge der Software-Experten doch > offenbar nicht hören. Aus bitterer Erfahrung. Was nützt ein Ratschlag in einer hermetisch verschlossenen Geheimsprache? > Das kenn ich von Ingenieuren auch, die machen alles > mit Excel Und warum ist das kritikwürdig? Ich wollte mich vor Monaten doch mal einen Schritt weiter- entwickeln und habe angefangen, mich mit LibreOffice Base zu befassen. Wegen unbrauchbarer Dokumentation und störender Bugs habe ich das bald wieder bleibenlassen. Der nächste Versuch wird mit Tcl und sqlite stattfinden. Könnte die Einstiegsschwelle nicht ETWAS niedriger sein? > und Dropbox und nehmen softwaretechnische Ratschläge > von Informatikern am Allerwenigsten an Natürlich nicht. Informatiker leben in einer eigenen Welt (viele wenigstens).
Possetitjel schrieb: > Aus bitterer Erfahrung. Was nützt ein Ratschlag in einer > hermetisch verschlossenen Geheimsprache? Alles erscheint wie eine Geheimsprache, wenn man nicht hinhört und "Lalala ich kann dich gar nicht hören" singt. Dies könnte einer grundlegenden Abneigung gegenüber dem Unbekannten entspringen: Possetitjel schrieb: > Natürlich nicht. Informatiker leben in einer eigenen > Welt (viele wenigstens).
Arno schrieb: > Irgendeine arme Sau verbringt dann Tage damit, die Änderungen von 20 > Leuten in das Master-Dokument einzupflegen, Und welche Alternative gibt es? Word Dokument im svn von allrn gleichzeitig bearbeiten lassen? Bekommt man die Konflikte noch aufgeloest?
Dumdi D. schrieb: > Und welche Alternative gibt es? Word Dokument im svn von allrn > gleichzeitig bearbeiten lassen? Bekommt man die Konflikte noch > aufgeloest? Word 365 kann das sogar glaube ich, ähnlich zu Google Documents. Alternativ LaTeX Code in git einchecken... ;-)
Kommt auf das VCS an. So einen kranken Schmarrn wie Git würde ich auch ablehnen. SVN mit Tortoise hingegen gerne.
Wühlhase schrieb: > Possetitjel schrieb: > >> Ja, das ist der optimale Weg, sich als unkollegialer >> Stänkerer zu profilieren. > > So unkollegial bin ich gar nicht wie das da oben > rüberkam. Okay. Ich kenne Dich ja nicht. > Wenn jemand unbedingt meint einen Faustkeil zu benutzen, > obwohl andere ihm für wenig oder gar kein Geld einen > prima Werkzeugkasten entwickelt haben...ich kann das > nicht nachvollziehen. Ich schon. Ein primitives Werkzeug, das man beherrscht, ist wesentlich nützlicher als ein leistungsfähiges, das man nicht beherrscht. >>> Die Mechaniker nutzen zur Versionssicherung lieber >>> die Unterordnerfunktion des Windowsexplorers, während >>> wir sämtliche Projektdateien (für Altium, LTSpice, >>> ggb. Labview und wasweißichnichtnochalles) lieber in >>> einem SVN-Repository halten und haben im letzten Jahr >>> da unser eigens Ding aufgezogen. >> >> Dass eure Mechaniker vielleicht eure kollegiale Hilfe >> statt des Hochmutes gebraucht hätten, kommt Dir nicht >> in den Sinn? > > An kollegialer Hilfe hätte es nicht gemangelt. Ich > persönlich gebe mein Wissen gerne weiter, allerdings > war das Thema schon durch bevor ich in dieser Firma > angefangen habe. Ja, naja... es hat ja wenig Sinn, wenn Du Partei in einer Sache ergreifst, die lange vor Deiner Zeit versaut wurde. > Und SVN zu bedienen ist nun wahrlich nicht > so schwer. Das ist in wenigen Minuten erklärt. Das ist nur ein Teil der Wahrheit. Falls ein zentraler Server notwendig ist, muss der administriert werden -- also werden die Mechaniker vom Administrator (der "natürlich" ein Elektroniker sein wird) abhängig. Nicht schön -- aus ihrer Sicht.
Ich könnte mir Leben ohne VCS nicht mehr vorstellen. In einem Team Environment wäre "Ohne" ein absoluter Horror. Ich finde es macht fruchtvolle Zusammenarbeit erst möglich. Nur meine 2 cents...
Bernd K. schrieb: > ALLE finden es natürlich vorteilhaft daß [...] aber > NIEMAND interessiert sich dafür wie ich das mache > und warum ich es so mache wie ich es mache. Okay... das ist aber nicht (primär) ein technisches Thema, sondern es betrifft eure Zusammenarbeit, eure Arbeitsteilung. > Wenn alle die es wissen müssten wissen wie das > funktioniert und wo was ist erleichtert es mir > die Arbeit und ich kann entspannter in Urlaub > fahren! Hmm. Das klingt danach, dass Du in eine Rolle hinein- gewachsen bist, die Du nicht wirklich auf Dauer ausfüllen willst, und in der Du auch keine Unterstützung durch den Chef hast. Keine guten Voraussetzungen. > Wo ist der Wissensdrang geblieben? Der hat sich zwischen nervtötenden Bugs, mangelhafter Dokumentation, gräuslicher Ergonomie, Profitstreben und ideologischen Grabenkämpfen totgelaufen.
Gerhard O. schrieb: > Ich könnte mir Leben ohne VCS nicht mehr vorstellen. In einem Team > Environment wäre "Ohne" ein absoluter Horror. Nicht nur in einem Team, auch alleine. Typische Anwendungen: - man bekommt aus dem Feld Rückmeldung, daß eine bestimmte Software-Version sich fehlerhaft verhält. Welcher Sourcecode gehört dazu? - man erbt ein Projekt und setzt die Toolchain auf. Wie überprüft man deren Korrektheit? Indem man den Sourcecode auscheckt, das Binärfile baut und mit dem ebenfalls ausgecheckten vergleicht, modulo Zeitstempel und sowas. - irgendein Feature geht nicht mehr, das fällt im Test auf. In der Vorversion ging das aber noch. Welcher Commit hat den Fehler reingebracht? Binäre Suche führt hier sehr schnell zum Ziel. Wo ich VCS nicht besonders mag: mit mehreren Leuten auf denselben Codeteilen arbeiten. Mergekonflikte sind nicht nur nervig, sondern viel schlimmer ist, daß Automerge nicht zwangsläufig korrekt funktioniert. Abhilfe: sich verständigen, wer an welchen Teilen arbeitet. Geht jedenfalls in übersichtlichen Teams sehr gut.
Christopher J. schrieb: > > Von CVS habe ich nur > Schaudergeschichten gehört und von SourceSafe kannte ich nicht mal den > Namen aber ich möchte allen die das beruflich nutzen müssen hiermit mein > herzliches Beileid aussprechen ;) Sag mal, ist Dir das nicht selber peinlich, Dich mit Aussagen wie "ich habe zwar keine Ahnung, wovon ich rede, aber ich sage einfach mal... es MUSS Sch... sein" als absoluter Hohlblubberkopf zu outen? Ich habe gerade mal nachgesehen. Bei uns läuft Source Safe mit einer Codebasis, die heute noch gepflegt wird, seit 2003. Jeder neue Mitarbeiter kann in weniger als einer Stunde komplett damit arbeiten. Wir haben niemals irgendwelche Probleme mit der Versionsdatenbank gehabt. Es gehört für uns Alle zum täglichen Handwerkszeug, und alle Use Cases, die Nop weiter oben geschildert hat, können damit abgehandelt werden. Klar kann das System nicht dass, was ein "modernes" System kann, z.B. Integration in IDEs oder den Dateiexplorer, weltweit verteilte Projekte über die Cloud managen etc pp., und bekannte kleine Problemchen muss man halt solange umschiffen, bis das System irgendwann mal abgelöst wird. Lt. einem externen Integrator lässt sich eine bestehende VSS Datenbank komplett so in Git übernehmen, dass Alles in de Versionshistorie dann in Git genau so aussieht wie unter VSS. Es ist halt wie der Lada im Firmenwagenpark, der zwar das hässliche kleine Entlein ist, aber dafür seit Ewigkeiten klaglos seinen Dienst tut, während um ihn herum die Glitzibunti supermodernen Autos verrecken und ständig ausgetauscht werden. Für alle Microsoft Haters: MS hat das System damals gekauft und die Weiterentwicklung kurz nach dem Kauf eingestellt, d.h. es ist noch nicht allzu viel "Verschmutzung" drin. Die Nicht-weiterentwicklung eines Produktes kann also auch ein Segen sein, wenn etwas schlicht und einfach genau das tut, was es soll und Niemand auf die Idee kommt, noch einen "Added Value" dadrauf zu packen (der lt. einem noch nicht näher benamten Gesetz der Softwareentwicklung zwangsweise die gewohnte Robustheit bricht). Ein Handwerker, der schon seit 20 Jahren mit seiner bewährten Bohrmaschine arbeitet, wird die auch so lange benutzen, wie sie ihren Dienst tut und keine neuen Materialien auf den Markt kommen, durch die das Arbeitspferd nicht mehr durch kommt. Ich sehe es übrigens wie Gerhard O.: Ein VCS ist absolut unverhandelbarer Mindestbestandteil im Werkzeugkoffer. Wer einmal verstanden hat, was man davon hat, wird Niemals mehr ohne auskommen wollen. Es ist eine Frage des Evangelismus, die Zweifler einfach nur durch praktische Demonstration eines Falles zu überzeugen.
Auch wenn etwas sinnvoll ist, heißt das noch lange nicht: Muss sein! Nebenbei: Niemand hindert dich (wahrscheinlich) daran, trotzdem eine Versionsverwaltung zu initialisieren. Auf diese Weise kannst Du jederzeit, zumindest bei Deinem Kram, den Rückwärtsgang einlegen. Kommst Du an die Ergüsse der Kollegen heran - bei Projekten mit mehreren Teilnehmern normal - so kannst Du diese ja ebenfalls erfassen. So frierst Du verschiedene Stati ein, nur halt nicht mit einem (anerkannten) Versionsnamen sondern mit einem Datum.
Andreas S. schrieb: > Dann führe doch einfach ein VCS für Deine eigenen Arbeiten ein. Gerade > Git lebt ja auch davon, dass eigentlich jeder Anwender seine eigenen > Repositories verwendet, so dass man auch keinen "richtigen" Server > aufsetzen muss. Eventuell stellen dann Deine Kollegen fest, dass Du > damit tatsächlich viel bessere Auskünfte über Deine Arbeit liefern > kannst und wollen dann irgendwann auch mitmachen. > Der Vorschlag ist ein Widerspruch in sich. Es steckt enorm viel Aufwand in der Pflege des Repos und ist völlig unnütz, wenn er das als einziger macht. Wenn der Rest ohne Versionskontrolle in wilder Laufbahn das Dateisystem verändert wird er niemals in den Vorteil kommen bessere Auskünfte geben zu können. Wenn ich also der Chef und dagegen wäre, würde ich das untersagen weil es keinen Mehrwert hätte, Zeit- und Geldverschwendung wäre. Wenn, dann müssen alle mitmachen und das Git-Repo muss das führende System sein und nicht der FTP-Server (whatever). @TO, sieht nach Kommunikationsfehler aus oder fehlende Argumente. Vielleicht falsches Umfeld? Dir bleibt nur selbst einen Vortrag zu halten. ;) Vielleicht fehlt auch nur das Vertrauen zur Expertise in der Firma...
Sebastian S. schrieb: > Stati brr, mir rollen sich in jedem Meeting die Fußnägel hoch, wenn ich das höre, obwohl es mit das prominenteste Beispiel für u-Deklination ist.
H. E. schrieb: > Es steckt enorm viel Aufwand in der Pflege des Repos Nur bei schlechten Systemen, also den aktuell gehypten. Gute wären im normalen Arbeitsablauf transparent und erfordern nach dem Einrichten vom Entwickler keinen Mehraufwand, nur bei Rausholen/Vergleich von Altversionen und dann sparen sie sogar Arbeit. Leider gibt es aktuell keine guten VCS.
Ich habe keine Ahnung was das für ein Aufwand sein soll. Ich verwalte selbst einen Gitlab Server für ein kleines Team, der ist super pflegeleicht. Ich musste noch nie etwas flicken, und konnte sogar eine eigene CI Funktion einbauen. Die Pflege des Repository beschränkt sich auf ein "commit" alle Paar Stunden, das dauert auch je nur 2 Minuten. Mergen geht damit definitiv schneller als ohne VCS. Man kann die Pflege ja auch skalieren. Selbst wenn man nur am Feierabend einmal Commit&Push macht und sonst nix hat man immer noch eine bessere Struktur als ganz ohne VCS. Der nächste Schritt wäre dann nur kompilier-fähige Stände zu committen - der Nutzen ist selbsterklärend. Parallel habe ich noch eine Owncloud Instanz am Laufen hauptsächlich für CAD Daten - das ist viel aufwendiger, da ist ständig was kaputt. Ok, bei Dropbox hat man das nicht, aber möchte man seine internen Daten Dropbox anvertrauen?
Version ist gut, Kontrolle besser schrieb: > Wir haben niemals irgendwelche Probleme mit der Versionsdatenbank > gehabt. Dann habt Ihr wohl sehr großes Glück gehabt. Leider basiert VSS ja auf einem Netzwerklaufwerk, auf dem die gemeinsamen Datenbankdateien liegen. Das kann über eine lange Zeit gut gehen, aber dann kracht es auf Grund irgendeines winzigen Fehlers auf einem der Clients. Es gibt leider auch noch andere VCS, die so funktionieren, z.B. RCS oder PVCS. > Klar kann das System nicht dass, was ein "modernes" System kann, z.B. > Integration in IDEs oder den Dateiexplorer, Ähh... Visual SourceSafe war doch gerade der Vorreiter, was die Integration in IDEs anging. Microsoft hat doch damals die sog. VCS Provider eingeführt, d.h. ein entsprechendes API, an das sich sowohl VCS als auch IDEs ankorken konnten. Microsoft Visual Studio war dann auf IDE-Seite das entsprechende Gegenstück. Somit gab es damals in den 1990er Jahren einen durchaus handfesten Vorteil bei der Verwendung von VSS und Visual Studio (bzw. den damals noch separat verkauften Produkten Visual C++, usw.).
Abgesehen von der Sinnhaftigkeit eines VCS für den Einzelkämpfer, kommt es auch ein wenig auf eure Prozesse (Entwicklung, Integration, Test/QS, Freigabe) bzw. Größe des Projekts/Teamstruktur an, ob sich ein VCS lohnen kann. Ein paar Argumente, um mit dem Chef/Kollegen darüber zu reden, falls die zutreffen: - Entwicklung/Integration: Wie läuft gerade der Bauprozess eurer Software o.ä.? Neben einer binary Firmware bzw. darin kompiliert sämtliche beteiligten repository Versionsnummern (z.B. git commit IDs) zu haben und diese dann vom Produkt auslesen zu können, macht das Ergebnis wesentlich reproduzierbarer. - QS/Freigabe: Mit einem vernünftigen System kann man den Stand über mehrere repositories taggen und so einen kompletten Produktstand versionieren. - Entwicklung/Integration: Automatisiertes Bauen des aktuellen Stands (aka nightly build) macht sich mit repositories besser als mit datierten Ordnern. - Integration/Test: Als Entwickler ist man dankbar, wenn der Tester einem zum Bug noch eine Version dazu schreiben kann, auf der er es getestet hat, damit man es selbst auf gleichem Stand reproduzieren kann (bzw. im VCS log schauen kann, was man seither gemacht hat). - Entwicklung/Pflege: Entwicklung von neuen Features parallel zur Pflege des bestehenenden Produkts sind eine Stärke von Branches.
H. E. schrieb: > Andreas S. schrieb: >> Dann führe doch einfach ein VCS für Deine eigenen Arbeiten ein. Gerade >> Git lebt ja auch davon, dass eigentlich jeder Anwender seine eigenen >> Repositories verwendet, so dass man auch keinen "richtigen" Server >> aufsetzen muss. Eventuell stellen dann Deine Kollegen fest, dass Du >> damit tatsächlich viel bessere Auskünfte über Deine Arbeit liefern >> kannst und wollen dann irgendwann auch mitmachen. >> > > Der Vorschlag ist ein Widerspruch in sich. Nein. Andreas hat völlig recht. > Es steckt enorm viel Aufwand > in der Pflege des Repos Keineswegs. > und ist völlig unnütz, wenn er das als einziger > macht. Das ist falsch. Ich vermute, Du verwechselst DVCS wie Git, Mercurial und andere mit GitHub, also einer zentralisierten Webplattform, die das D in DVCS - das steht für "distributed" wieder weitgehend eliminiert. Ein Repository besteht einfach aus einem folder, in dem zu Verwaltungszwecken ein hidden folder angelegt wird. Mit Mercurial tut es dafür ein simples Kommando
1 | hg init |
in dem Verzeichnis. Bevorzugt man Git, so lautet der Befehl (Überraschung!) "git init". Die Pflege besteht im einfachsten Fall in gelegentlichen Commits. > Wenn der Rest ohne Versionskontrolle in wilder Laufbahn das > Dateisystem verändert wird er niemals in den Vorteil kommen bessere > Auskünfte geben zu können. Du hast "für eigene Arbeiten" vergessen. Wenn ich, was früher auch gelegentlich mal vorkam, liegengelassene Projekte aus vor-CVS-Zeiten versionieren wollte, stellte sich oft die Frage, wie die händisch archivierten Snapshots bzw. Kopien denn eigentlich einzuordnen seien. Meine Vorgehensweise mit Mercurial - die mit Git dürfte analog funktionieren -: Die Snapshots in eine zeitliche Reihenfolge bringen, aus der ältesten Version ein Repository machen, alles, was nach versionierbarem Quellcode aussieht, in die Versionskontrolle aufnehmen und committen, dann die nächst jüngere Fassung drüberkopieren. Rinse and repeat, bis man bei der jüngsten Kopie angekommen ist. Dabei ein wenig mit dem Ignore-File spielen und neu hinzugekommene bzw. verschwundene Quellen genauer anschauen. Hier ist ggfs. das GUI hilfreich. Nachher hat man ohne viel Aufwand eine krude Historie rekonstriert, mit der man arbeiten kann. Das Verfahren lässt sich übrigens auch anwenden, um Änderungen, die von außen ohne Versionskontrolle hereinkommen, zu tracken und hat insofern entgegen Deinen Vermutungen durchaus einen Mehrwert. >Wenn ich also der Chef und dagegen wäre, > würde ich das untersagen weil es keinen Mehrwert hätte, Zeit- und > Geldverschwendung wäre. Wenn, dann müssen alle mitmachen und das > Git-Repo muss das führende System sein und nicht der FTP-Server > (whatever). Nichts gegen den Wunsch, ein zentrales Repository zu etablieren, wenngleich ich einwenden muß, daß die Praxis oft komplizierter ist. Es gibt unterschiedliche, durchaus funktionierende Modelle und ein einziges zentrales Repository ist eher selten die Lösung. Eher kontraproduktiv ist es aber der Ratschlag, statt lokaler Versionierung mit einem DVCS lieber ganz auf diese zu verzichten.
Ein Source Control System muss zwingend ausserhalb der Sourcen laufen, die Sourcen nicht beruehren. Und sich selbst eine Datenbank mit Veraenderungen aufbauen. Die Anfaenge waren nicht so. Wir haben mal RCS ausprobiert. Das hat alles reingezogen .. und nachher waren die Filenamen veraendert, usw. hat uns einige Tage gekostet.
PS: Bei GitLab & Co hat man außerdem eine wunderschöne Web-Oberfläche, wo man sich bunt anzeigen lassen kann was so passiert. Das dürfte auch BWLer freuen, wenn sie die Früchte der Arbeit live eintrudeln sehen können (nur im Browser, ohne lokale Software-Installation), und da fragwürdige Kriterien zur Mitarbeiter-Bewertung ableiten können. Falls einem GitLab o.ä. zu aufwendig ist, kann man ja auch bei GitHub, Bitbucket & Co private Repositories kaufen, was den Aufwand minimiert. Stellt sich natürlich wieder die Frage, ob man die Daten einem fremden Unternehmen anvertraut - aber das ist bei Dropbox & Co. ja auch der Fall. Ein Problem wurde aber noch gar nicht angesprochen: Das Prinzip von VCS ist es ja, aufzuzeichnen, wer wann was gemacht hat. Diese Daten fallen aber unter das Datenschutzgesetz. Bei entsprechend großen Unternehmen braucht es daher einen Datenschutz-Beauftragten sowie ggf. Zustimmung vom Betriebsrat. Da andere Lösungen wie File-Server diese Daten ebenso sammeln, sollte das eigentlich keine größe Hürde sein - es braucht nur noch mehr Überzeugungsarbeit.
Zwölf M. schrieb: > Ein Source Control System muss zwingend ausserhalb der Sourcen laufen, > die Sourcen nicht beruehren. Und sich selbst eine Datenbank mit > Veraenderungen aufbauen. Das hängt ein bisschen vom Anwendungsfall ab. > Die Anfaenge waren nicht so. Wir haben mal RCS ausprobiert. RCS besitzt auch heute noch eine gewisse Daseinsberechtigung, allerdings nicht in Entwicklungsprojekten und/oder im Umgang mit vielen Dateien, und schon gar nicht im Mehrbenutzerbetrieb. RCS ist äußerst praktisch, um Systemkonfigurationsdateien auf Servern o.ä. zu verwalten, insbesondere wenn keine Netzwerkverbindung zu einem zentralen VCS-Server besteht. Gerade bei Firewallkonfigurationen kommt es ja sehr schnell vor, dass eine winzige Konfigurationsaenderung gewaltige Auswirkungen haben kann. Und dann ist es hochgradig wichtig, eine lokale Versionsgeschichte der relevanten Dateien zu halten. Und die jeweilige Archivdatei liegt gleich nebenan, d.h. zu xyz.conf gibt es xyz.conf,v. Nachteilig ist bei RCS aber, dass das ci-Kommando standardmäßig die eingecheckte Datei lokal löscht; daher wird in solchen Fällen stets "ci -l" oder "ci -u" verwendet. Um mich noch einmal zu wiederholen: RCS hat heutzutage wirklich nichts mehr in "richtigen" Projekten zu suchen, ebenso wie SCCS.
Andreas S. schrieb: > RCS ist äußerst praktisch, um Systemkonfigurationsdateien auf Servern > o.ä. zu verwalten, insbesondere wenn keine Netzwerkverbindung zu einem > zentralen VCS-Server besteht Genau das kann git auch ganz wunderbar... Und wenn die Verbindung dann steht, synchronisiert man sich mit push/pull mit dem Server, damit das Script auch schön gesichert/zugänglich ist. Das ist auch einer der Gründe warum wir git im Formula Student Team nutzen - an der Renn/Test-Strecke hat man nicht immer Internet! Und wenn man doch mal Daten austauschen muss geht man per UMTS rein und trennt nach dem push/pull wieder, das spart eine Menge Daten im Gegensatz zu z.B. einer kompletten Owncloud-Synchronisierung.
Angehängte Dateien:
Dr. Sommer schrieb: > PS: Bei GitLab & Co hat man außerdem eine wunderschöne Web-Oberfläche, > wo man sich bunt anzeigen lassen kann was so passiert. ... > ... Falls > einem GitLab o.ä. zu aufwendig ist, kann man ja auch bei GitHub, > Bitbucket & Co private Repositories kaufen, was den Aufwand minimiert. Das geht auch einfacher. Eine Weboberfläche erhält man in Mercurial, indem man im lokalen Repository
1 | hg serve |
kommandiert. Das startet auf http://127.0.0.1:8000/ einen Webserver, der eine wunderschöne Web-Oberfläche zeigt. Natürlich ist das keine eierlegende Wollmilchsau wie GitLab, aber es ist simpel und es erlaubt komfortables Browsen im Repository, Drilldown auf einzelne Commits, einzelne Diffs oder einzelne Dateien darin, Checkout, fast alles, was man braucht, wenn man ansonsten kein GUI zur Hand hat, aber gerne eines hätte. Man kann das auch beispielsweise hinter einem Apache via reverse-proxy laufen lassen - so mache ich das @home - und damit mehrere Repositories im lokalen Netz zugänglich machen. > > Ein Problem wurde aber noch gar nicht angesprochen: Das Prinzip von VCS > ist es ja, aufzuzeichnen, wer wann was gemacht hat. Diese Daten fallen > aber unter das Datenschutzgesetz. Nur dann, wenn der Workflow erzwingt, daß kleinteilige Commits in ein zentrales Repository fließen. Davon ist aber eh' abzuraten. > Bei entsprechend großen Unternehmen > braucht es daher einen Datenschutz-Beauftragten sowie ggf. Zustimmung > vom Betriebsrat. Gute Idee. In dem Fall ist es aber wichtig, alle Beteiligten auch von der technischen Seite her mitzunehmen. M.E. sollte alle Parteien Interesse an Datensparsamkeit haben. Wer ein Versionskontrollsystem zur Mitarbeiterkontrolle einsetzt, macht etwas falsch.
Wolfgang S. schrieb: > Das geht auch einfacher. Eine Weboberfläche erhält man in Mercurial Ah, das ist chic. Vor GitLab braucht man aber nicht zurückzuschrecken, das ist tatsächlich einfach einzurichten und zu bedienen und sehr leistungsfähig. Wolfgang S. schrieb: > Nur dann, wenn der Workflow erzwingt, daß kleinteilige Commits in ein > zentrales Repository fließen. Davon ist aber eh' abzuraten. Wie soll man es denn sonst machen - einzelne Commits manuell in ein zentrales Repo kopieren? Der normale Workflow ist doch, öfter mal zu committen, und wenn das Feature fertig ist, das in den master-Branch zu mergen. Da sieht man dann aber auch alle einzel-Commits. Wolfgang S. schrieb: > Gute Idee. Ist nicht meine, sondern deutsches Gesetz ;-) Wolfgang S. schrieb: > Wer ein Versionskontrollsystem zur > Mitarbeiterkontrolle einsetzt, macht etwas falsch. Das sowieso. Es ist hauptsächlich eine Formalität. Das gleiche Problem hast du ja auch bei E-Mail, Outlook-Kalendern usw - kein Mitarbeiter würde sich aus Datenschutzgründen gegen einen Mail-Server aussprechen - wenn schon nur weil die Mails nerven ;-)
Gitter schrieb: > Abgesehen von der Sinnhaftigkeit eines VCS für den Einzelkämpfer, Also ich nutze mercurial seit Jahren und will es nicht mehr missen. Nicht nur für Software sondern auch für Hardware. Allein die Versionshistorie würde schon reichen um dem Aufwand zu rechtfertigen. Dann kann man mit Subrepos wirklich jeden einzelne Entwicklungs- und Fertigungsaspekt versionieren usw. usf. Hab mir z.B selber n Progrämmchen geschrieben das die Versionsnummer des Repos nach dem commit in die Leiterplatte einträgt. Auf alle sinnvollen Layer. Da kann man auch einfach ne Production Version branchen und munter weiter entwickeln. Die Prod. Version wird dann nach den Fertigungsänderungen manuell gemerged. Dafür bastele ich zur Zeit ein visuelles diff. Schon der Prototype ist so hilfreich das ich auch das nicht mehr missen möchte. Wolfgang S. schrieb: > Das geht auch einfacher. Eine Weboberfläche erhält man in Mercurial, > indem man im lokalen Repositoryhg serve Super Tip, danke. Funzt das auch mit mehreren repos lokal?
Im Grunde haben wir hier ein typisches Overhead- Problem. Die Frage also, ob ein bestimmter Mehraufwand in vernünftiger Relation zum Nutzen steht. Ob sich Versionierung oder der Einsatz von Scrum, ob sich ein Protokoll, der Einsatz einer ausgefeilten Hochsprache oder ein bestimmtes zugrundeliegendes Betriebssystem wirklich rechnet ist nicht pauschal zu sagen. In einer Diskussion wie dieser sollte immer auch die Möglichkeit im Blickfeld bleiben daß dem eben nicht so ist. Im Zweifelsfall wird der unbedarfte Anwender immer auch dem einfacheren Tool den Vorzug geben. Die Zeit steht nur einmal zur Verfügung und die ist grundsätzlich nunmal sinnvoller ins eigentliche Projekt als in dessen (eh man sich versieht schnell zu aufwendiger) Administrierung gesteckt. Zusätzliche Lernprozesse inklusive.
Wenn ihr eine kleine Firma mit 2 Entwicklern seid, verstehe ich Deinen Kollegen und Chef schon irgendwo. Wahrscheinlich wird noch viel manuell getestet, die Versionsverwaltung über unterschiedliche Verzeichnisse geregelt und es wird sich sicher um nicht sichere Software handeln. Nicht dass das ein optimale Arbeitsweise ist, aber so richtig fängt Versionskontrollsoftware erst an ihre Vorteile auszuspielen wenn es um Begriffe wie automatisches Testen und Continuous Integration (siehe Jenkins) und so weiter geht.
wie geht man damit um? die leute feste auf die fresse fallen lassen - siehs als darwinismus. wobei das natürlich leichter gesagt als getan ist. ich musste selbst von einem arschgeigen deppen der unser VCS nicht benutzte ein projekt übernehmen als er ging. er hat dann schnell vor seinem abgang noch ein 700mb .zip eingescheckt, in das er seinen sauhaufen von code reingepackt hatte. ich hab mich beim chef bedankt. oh und entschuldigt die beschimpfungen, aber ich muss mich bei dem thema irgendwie abreagieren, und den verantwortlichen so die fresse zu polieren wie sie es eigentlich verdient hätten ist unter strafandrohung verboten. schade.
Dr. Sommer schrieb: > Wolfgang S. schrieb: >> Das geht auch einfacher. Eine Weboberfläche erhält man in Mercurial > Ah, das ist chic. Vor GitLab braucht man aber nicht zurückzuschrecken, > das ist tatsächlich einfach einzurichten und zu bedienen und sehr > leistungsfähig. Wenn ich jemandem adhoc die Vorzüge eines DVCS demonstrieren möchte, werde ich auf dessen Laptop nicht eben mal GitLab installieren, schon gar nicht, wenn das ein mit Windows betriebener Laptop ist. Mercurial und - wenn nicht schon vorhanden - Python lokal zu installieren (oder alternativ TortoiseHg) ist hingegen auf den meisten Plattformen eine überschaubare Übung. > > Wolfgang S. schrieb: >> Nur dann, wenn der Workflow erzwingt, daß kleinteilige Commits in ein >> zentrales Repository fließen. Davon ist aber eh' abzuraten. > Wie soll man es denn sonst machen - einzelne Commits manuell in ein > zentrales Repo kopieren? Nein, sondern konsolidierte Commits in einem separaten Branch sammeln. Das kann man manuell machen, muß man aber nicht, das läßt sich auch automatisieren. In "entsprechend großen Unternehmen" - davon sprachst Du - wird man vermutlich eh separate Repositories für Entwicklung, freigegebene Versionen usw. pflegen müssen. >Der normale Workflow ist doch, öfter mal zu > committen, und wenn das Feature fertig ist, das in den master-Branch zu > mergen. In kleinen Gruppen wird man sicher so arbeiten. Wenn aber die Arbeit von mehrere Gruppen zusammengefasst wird, wird man nicht nur aus Datenschutzgründen nicht jeden Schreibfehler überallhin propagieren wollen. Mehr habe ich nicht gesagt. >Da sieht man dann aber auch alle einzel-Commits. > > Wolfgang S. schrieb: >> Gute Idee. > Ist nicht meine, sondern deutsches Gesetz ;-) Du hattest dies ja selber schon eingeschränkt. Abgesehen davon gibt es in den besseren größeren Unternehmen eh schon Gesamtbetriebsratsvereinbarungen, die einige dieser Dinge flächendeckend regeln. Es ist gewiß nicht verkehrt, dort auch die DVCS zu behandeln, also festzulegen, ab welchem Punkt was separat zustimmungspflichtig ist etc. Das bedeutet aber auch, daß man sich überlegen kann, daß es besser ist, manche Daten erst gar nicht zu sammeln.
Wolfgang S. schrieb: > H. E. schrieb: > >> Der Vorschlag ist ein Widerspruch in sich. > > Nein. Andreas hat völlig recht. Der Zusammenhang wird hier auseinandergezogen. Es ist nur dann ein Widerspruch, wenn ein führendes System (irgendein Root-Verzeichnis) ohne Versionskontrolle verwaltet wird und nur ein einziger bei sich ständig Fremdeinwirkungen manuell mit ins VCS-System reinpflegt. > >> Es steckt enorm viel Aufwand >> in der Pflege des Repos > > Keineswegs. Doch, auch Sicht des geschilderten Falls schon. Der Chef sagt: VCS? Nö! Und dann fängt der Mitarbeiter an Zeit in VCS zu stecken obwohl eigentlich: nö! ;) Es geht nicht darum was ich davon halte. Nicht das wir uns falsch verstehen, ich halte eine Versionskontrolle immer für sinnvoll, allein die Vorteile die sich daraus ergeben. Das war ausschließlich in Bezug auf die Kontroverse des geschilderten Falls bezogen. > >> und ist völlig unnütz, wenn er das als einziger >> macht. > > Das ist falsch. > > Ich vermute, Du verwechselst DVCS wie Git, Mercurial und andere mit > GitHub, also einer zentralisierten Webplattform, die das D in DVCS - das > steht für "distributed" wieder weitgehend eliminiert. Es geht mir immer noch darum, dass der Nutzen marginal ist, wenn der Rest der Firma das File-System bearbeitet, wie die Fingernägel gewachsen sind. In einer Versionskontrolle sollen ja alle Änderungen eines Zustands (Commits) aufgezeichnet werden. Das ist überhaupt nicht mehr gewährleistet, wenn der Rest am VCS vorbei arbeitet. Wenn überhaupt, lässt sich dann feststellen: Irgendeiner hat irgendwann seit dem letzten mal irgendwas an Stelle XYZ geändert. Zwischenstufen sind hier evtl. gar nicht aufgezeichnet. Ja, es ist besser als nichts, aber das wird den Chef nicht tangieren, wenn er gegenüber VCS abgeneigt ist. > >>Wenn ich also der Chef und dagegen wäre, >> würde ich das untersagen weil es keinen Mehrwert hätte, Zeit- und >> Geldverschwendung wäre. Wenn, dann müssen alle mitmachen und das >> Git-Repo muss das führende System sein und nicht der FTP-Server >> (whatever). > > Nichts gegen den Wunsch, ein zentrales Repository zu etablieren, > wenngleich ich einwenden muß, daß die Praxis oft komplizierter ist. Es > gibt unterschiedliche, durchaus funktionierende Modelle und ein einziges > zentrales Repository ist eher selten die Lösung. Am Ende soll alles zusammenlaufen. Deshalb gibt es ein Master-Repo und davon existieren lokale Kopien und deren Commits, Branches, Tags etc. pp. > Eher kontraproduktiv ist es aber der Ratschlag, statt lokaler > Versionierung mit einem DVCS lieber ganz auf diese zu verzichten. In der Hinsicht wurden keine Ratschläge erteilt. Die Energie als Eigenbrötler kann man sich letzendes sparen und man sollte die Energie stattdessen in Argumente investieren und einen Vortrag halten anhand von Beispielen. Meine Erfahrung ist die, dass VCS-Verweigerer nicht überzeugt davon sind weil die Vorzüge nicht bewusst sind. Zudem dominiert die Angst, dass man mit dem Werkzeug nicht klar kommt und viel Zeit "verbraten" würde auf Grund von fehlendem Wissen (was eigentlich ja nicht mal so schlimm wäre, was man nicht kennt, kann sich ja noch ändern). Zusammenfassend wie ich das sehe. Versionskontrolle: Unbedingt Eigenbrötler: besser als nichts Besser noch: Spielraum für Überzeugen schaffen anstatt als einziger mit dem Kopf durch die Wand. Es ging in meinem Bezug darauf, dass offensichtlich die Einstellung des Chefs die folgende ist: Was der Bauer nicht kennt, frisst er nicht.
Wolfgang S. schrieb: > Wenn ich jemandem adhoc die Vorzüge eines DVCS demonstrieren möchte, Ja ok, dafür ist GitLab overkill... Wolfgang S. schrieb: > Nein, sondern konsolidierte Commits in einem separaten Branch sammeln. Dann werden da aber auch die Zwischen-Commits angezeigt, zumindest bei Git, wenn man die konsolidierten commits einfach in diesen Branch merged. Das ist aber IMO kein Problem, man sieht ja welche commits die wichtigen sind, und kann die ja auch noch explizit taggen. Wolfgang S. schrieb: > Das bedeutet aber auch, daß man sich überlegen kann, daß es besser > ist, manche Daten erst gar nicht zu sammeln. Das ist ja wie Gold auf dem Weg liegen zu lassen, denn diese Daten können sich als sehr wertvoll erweisen...
Decius schrieb: > aber so richtig fängt > Versionskontrollsoftware erst an ihre Vorteile auszuspielen wenn es um > Begriffe wie automatisches Testen und Continuous Integration (siehe > Jenkins) und so weiter geht. Nein, das seh ich anders: Die Nützlichkeit fängt viel früher an. Gerade bei leichtgewichtigen DVCS wie git oder hg deren Benutzung so gut wie keinen Overhead erzeugen.
Bernd K. schrieb: > Standpunkt vertritt es sei zu umständlich die Bedienung eines VCS zu > erlernen, es "lohne" sich daher nicht. Wie geht Ihr mit sowas um? > > Ich versteh das echt nicht, das sind alles hochintelligente Menschen und > scheitern dennoch an so einer simplen Kosten-Nutzen-Rechnung. Bernd K. schrieb: > Ich erwarte nicht daß sich alle zu absoluten git-Experten entwickeln die > mit einer Hand auf den Rücken gebunden 2 Kernel branches mergen konnten. > "Äh das ist mir jetzt zu kompliziert, das kann ich doch nicht, kannst Du mir > das bitte schnell auschecken und auf das netzlaufwerk legen und mir dann > bescheid sagen? Danke!". Hallo? > Wohlgemerkt, es geht um Leute die selbst auch mit Entwicklung befasst > sind, nur von denen erwarte ich zumindest minimales Interesse daran was > das für ein Ding ist das das alles noch zusammenhält und wie man es > wenigstens grundlegend benutzt, das würde auch schon reichen. > > Aber es ist immer gerade "jetzt" zu kompliziert. Jedesmal ist es genau > jetzt zu kompliziert! Und danach ist es wieder "nicht nötig". > > Wo ist der Wissensdrang geblieben? Was neues gesehen: rausfinden was das > ist, was es macht, versuchen zu verstehen wie es funktioniert! > Ausprobieren wollen! Wo ist das alles geblieben? Ich habs noch. Warum > habens die anderen verloren? Du bist also der GIT-Experte. Vielleicht noch ein paar Dinge Drumherum, die andere auch nicht nutzen? ivy, ant, maven, Hudson, ...? Wenn es Dir darum geht, das andere Dir folgen, dann hast Du einen schweren Stand. Die Leute haben einfach keine Lust, private Zeit in "unnützes Zeug" zu investieren. Es dauert (wie eine neue Sprache lernen) einfach zu lang und die Leute haben ein Privatleben. Wenn es Dir wirklich darum geht, dass andere ein CVS nutzen, dann springe über Deinen Schatten und versuche es mit einem wesentlich einfacheren VCS, z.B. Tortoise/SVN.
Selbst wenn man Einzelkämpfer ist macht ein VCS immer Sinn:
Es hält einfach den Code sauber. Wo man früher ne Menge auskommentierten
Schrott drinn hatte ("das brauche ich vielleicht noch..." macht man
heute ein commit wenns später nicht passt kann man wie schon jeman
schrieb wunderbar Fehler eingrenzen. Ich mach für jedes kleine
Furzscript ein git init, man weiss nie was aus dem Script noch wird,
meist wirds doch grösser als geplant und behält mit git die Übersicht.
So Gemurkse wie "ich mache alle 2h eine Vollkopie mit was
selbergebasteltem" hat dann im Erstfall doch nicht den richtigen
Snapshotzeitpunkt erwischt mit dem Code den man noch mal anschauen will
muss sich durch redundanten Code wühlen.... einfach Murks und endlos
Zeit fressend.
Wer für git,... zu doof ist soll sich nen anderen Job suchen. Wäre ich
der Boss in dem Laden würde ich dem Typen ne Abmahnung wegen
Arbeitsverweigerung
reindrücken.
Bernd K. schrieb: > Decius schrieb: >> aber so richtig fängt >> Versionskontrollsoftware erst an ihre Vorteile auszuspielen wenn es um >> Begriffe wie automatisches Testen und Continuous Integration (siehe >> Jenkins) und so weiter geht. > > Nein, das seh ich anders: Die Nützlichkeit fängt viel früher an. Gerade > bei leichtgewichtigen DVCS wie git oder hg deren Benutzung so gut wie > keinen Overhead erzeugen. Oder der Klassiker -> Kollision. Person A, erstellt die Datei Einkauf.txt mit der Zeile: Äpfel -> Datei wird auf dem Produktivserver hochgeladen. Person B, lädt die Datei herunter und fügt Birnen dazu. -> Datei wird hochgeladen: Äpfel, Birnen Person C, hat zeitgleich wie Person B die Datei heruntergeladen (Stand von Person A) und fügt Pflaumen hinzu. Datei wird hochgeladen: Äpfel, Pflaumen und "Birnen" geht verloren. Der Einkäufer lädt die Datei herunter und wird keine Birnen kaufen, wenn der Fehler nicht rechtzeitig von A,B oder C bemerkt wird. Das wäre mit einer Versionskontrolle nur mit purer Ignoranz passiert. Denn diese hätte die Konflikte dargestellt und einer der Personen hätte den Konflikt auflösen müssen. :-)
Achim S. schrieb: > versuche es mit einem wesentlich > einfacheren VCS, z.B. Tortoise/SVN. SVN ist umständlicher als git und der Workflow ist schwerfälliger, das wäre also eher nachteilig. Tortoise gibts für beide.
Bernd K. schrieb: > Tortoise gibts für beide. Nutzt Du Tortoise git? Oder was willst Du damit sagen??
X4U schrieb: > Wolfgang S. schrieb: >> Das geht auch einfacher. Eine Weboberfläche erhält man in Mercurial, >> indem man im lokalen Repositoryhg serve > > Super Tip, danke. > > Funzt das auch mit mehreren repos lokal? Auf diese Weise nicht, nein. Da ich, wie schon geschrieben, den Mercurial-Webserver hinter einem Apache laufen lasse, weiß ich zwar, daß es prinzipiell gehen müsste, Mercurial weigert sich aber, den Server aus einem Verzeichnis heraus laufen zu lassen, das kein Repository ist. Man kann mit einem hgrc und Subrepositories, die man da manuell einträgt, ein wenig tricksen, jedoch überspannt schon das den Bogen ein wenig. hg help serve gibt ein paar Benutzungshinweise. Wie erwartet, kann man im Aufruf den Port festlegen.
1 | hg serve -p 9000 |
benutzt den Port 9000, die Angabe von 0 veranlasst hg serve, sich einen freien Port zu suchen. Auf diese Weise kann man, sollte das nötig sein, etwa um von einem anderen Arbeitsplatz aus schnell mal was zu clonen oder etwas nachzuschauen, das über mehrere Repositories verstreut ist, auch mehr als eines serven. Aber Vorsicht, wie die eingebaute Hilfe ja auch erläutert, eine Zugriffskontrolle gibt es hier nicht.
H. E. schrieb: > Zusammenfassend wie ich das sehe. > > Versionskontrolle: Unbedingt > Eigenbrötler: besser als nichts > Besser noch: Spielraum für Überzeugen schaffen anstatt als einziger mit > dem Kopf durch die Wand. Ich würde "besser als nichts" zwar in der Form "immerhin ein Anfang" ins Positive wenden wollen, ansonsten aber kein Einwand. "Mit dem Kopf durch die Wand" funktioniert nicht. Aber es gilt auch, besser vormachen als nur reden. Darauf kann man sich einigen, denke ich.
Bernd K. schrieb: > SVN ist umständlicher als git und der Workflow ist schwerfälliger, das > wäre also eher nachteilig. Tortoise gibts für beide. Dafür funktioniert Tortoise mit SVN sehr einfach, mit Git.. naja. Und CLI-Git ist indiskutabel. Merkregel: wenn ein Programm anfängt, den Anwender mit Implementationsdetails zuzuschütten, hat man ein Designproblem. Zumal man in Firmen ohnehin meistens kein DVCS braucht, weil der Server eben da ist. Schon weil sonst die Netzwerklizenzen für den Compiler nicht gehen. Außerdem wird der Server zentralem Backup unterzogen.
Dr. Sommer schrieb: > Wolfgang S. schrieb: >> Nein, sondern konsolidierte Commits in einem separaten Branch sammeln. > Dann werden da aber auch die Zwischen-Commits angezeigt, zumindest bei > Git, wenn man die konsolidierten commits einfach in diesen Branch > merged. Mercurial bietet andere Möglichkeiten, als einfach eine Serien von revsets als Patches zu exportieren, Git soweit ich weiß, auch. Ich denke, das geht jetzt aber ein wenig zu sehr ins Detail. > Das ist aber IMO kein Problem, man sieht ja welche commits die > wichtigen sind, und kann die ja auch noch explizit taggen. Wenn es um schützenswerte Daten geht, ist es schon wichtig, ob die Daten tatsächlich weg sind oder nur versteckt werden. > > Wolfgang S. schrieb: >> Das bedeutet aber auch, daß man sich überlegen kann, daß es besser >> ist, manche Daten erst gar nicht zu sammeln. > Das ist ja wie Gold auf dem Weg liegen zu lassen, denn diese Daten > können sich als sehr wertvoll erweisen... Eben.
Dr. Sommer schrieb: > Andreas S. schrieb: >> RCS ist äußerst praktisch, um Systemkonfigurationsdateien auf Servern >> o.ä. zu verwalten, insbesondere wenn keine Netzwerkverbindung zu einem >> zentralen VCS-Server besteht > Genau das kann git auch ganz wunderbar... Und wenn die Verbindung dann > steht, synchronisiert man sich mit push/pull mit dem Server, damit das > Script auch schön gesichert/zugänglich ist. Hä, welche Verbindung? Es gibt sehr viele Systeme, die niemals solch eine Verbindung bekommen werden, weil sie z.B. gar keinen Netzwerkzugang haben oder weil dieser eben keine Verbindung in beliebige Richtungen zulässt. Die Dateisicherung erfolgt dann z.B. durch das Anschließen (und anschließende Entfernen) einen physischen Datenträgers, auf den dann ein Backup geschrieben wird. Git hätte hier sicherlich den Vorteil, dass man solch einen Datenträger auch als Remote eintragen und ein Push ausführen kann. Aber der Vorteil von RCS ist eben der absolut minimalistische Ansatz: genau eine Archivdatei pro zu versionierender Datei. Keine Konfiguration, kein separates Verzeichnis. Außerdem wird es schon seit Jahrzehnten mit so ziemlich allen unixoiden Betriebssystemen standardmäßig mitgeliefert. Es gibt dann einfach keinen Grund, etwas anderes als dieses Hausmittel zu verwenden, wenn man wirklich nur eine einzelne Datei an beliebiger Stelle versionieren möchte. Man muss auch kein Repository anlegen, sondern dies geschieht automatisch beim ersten Checkin mittels "ci -l". > Das ist auch einer der Gründe warum wir git im Formula Student Team > nutzen - an der Renn/Test-Strecke hat man nicht immer Internet! Wieso schaffen es Autofanatiker eigentlich niemals, über ihren eigenen Tellerrand bzw. das Lenkrad hinauszuschauen?
Bernd K. schrieb: > SVN ist umständlicher als git und der Workflow ist schwerfälliger, das > wäre also eher nachteilig. Unsinn. Bei Git benötigt man spätestens dann etliche Repositories, wenn es um die Einrichtung von Zugriffsrechten geht. Bei SVN hingegen kann man - auch nachträglich - die Zugriffsrechte auf einzelne Pfade innerhalb eines Repositories sehr detailliert einstellen. SVN ist auch wesentlich mächtiger als Git, wenn es um die Restrukturierung von Repositories geht, insbesondere bei Verwendung eines einzigen für alle Projekte. Und durch die Verwendung einer einzigen Revisionsnummer für das ganze Repository hat man eine vorzügliche Lamport-Uhr, wohingegen man den Commits eben nicht die Reihenfolge ansieht. Git besitzt natürlich erhebliche Vorteile, wenn es um die verteilte Entwicklung geht. Für genau diesen Zweck wurde es ja schließlich auch entwickelt, ähnlich wie das anfänglich für die Linux-Kernelentwicklung genutzte und wesentlich ausgereiftere Bitkeeper. Allerdings gab es damals einen ziemlichen Streit wegen des Bitkeeper-Lizenzmodells, denn Bitkeeper ist ein normales kommerzielles Produkt. Interessanterweise habe ich neulich erfahren, dass Bitkeeper offenbar eine Weiterentwicklung von SCCS ist. > Tortoise gibts für beide. Es gibt nicht ein Program namens Tortoise, welches mit den unterschiedlichen VCS zurechtkommt. Tortoise SVN, Tortoise Git und Tortoise CVS sind völlig unterschiedliche Programme. Leider bin ich auch schon darauf hereingefallen, dass mir im Explorer der falsche Dateistatus angezeigt wurde, z.B. bei irgendwelchen Dateiarchiven, die ein .git-Verzeichnis enthalten und in einem per SVN verwalteten Verzeichnis entpackt werden. Offenbar scheint Tortoise Git da dominanter als Tortoise SVN zu sein.
Ohne Versionskontrolle würde ich nicht mehr arbeiten wollen. Mittlerweile packe ich alles in ein Git rein. Früher hatte ich SVN verwendet, das skaliert allerdings nicht so schön bzw. kann manche Features nicht bieten, die es bei Git gibt. Bei Software bietet sich Git natürlich an. Aber auch bei Hardware verwende ich es. KiCAD zum Beispiel speichert die Daten in Textfiles ab. Dadurch ist es sehr gut Git-Kompatibel. Aber auch für Projektberichte und wissenschaftliche Arbeiten setze ich mittlerweile auf Git. Auch ein paar Kollegen habe ich überzeugt. Durch mehrere Branches kann Kollege A bereits nen Review eines Teilberichts durchführen während ich an einem anderen Teil des Berichts arbeite. Später wird dann alles in einem Merge zusammengeführt. Durch die Diff-Funktion sehe ich sehr schnell, welche Änderungswünsche bestehen. Bei Überschneidungen kann man das immer noch sehr schön manuell auflösen. In Projekten arbeite ich meist auf einem eigenen Branch. Dadurch kommt es weniger zu Kollisionen und ich kann den aktuellen Stand auf Master zurückführen, sobald er bereit ist. D.h. halbfertige Sachen liegen erstmal nicht auf Master. (Ein Vorteil gegenüber SVN). Ich kenne auch noch die "alte" Methode, wo es in manchem Ordner ca. 10 Dateien mit ähnlichem Namen (_old, _asdf, ...) gab wo man nie wusste, was schon mit was zusammengeführt wurde und wo nun der aktuelle Stand ist. Nie wieder... Seit Anfang meiner Berufstätigkeit setze ich SVN und Git ein, das ist jetzt auch schon ca. 10 Jahre her. Sogar meine Facharbeit(!) hatte ich damals als Schüler in einem eigenen SVN liegen. Zusätzlich hatte ich damit ein externes Backup und eine gute Übersicht darüber, was/wo/wie geändert wurde.
Johannes O. schrieb: > [...] Projektberichte und wissenschaftliche Arbeiten [...] > Später wird dann alles in einem Merge zusammengeführt. merge und binary beisst sich doch meistens... außer du erstellst deine Projektberichte und wissenschaftliche Arbeiten in einem non-binary Format (TeX?)
H. E. schrieb: > Es ging in meinem Bezug darauf, dass offensichtlich > die Einstellung des Chefs die folgende ist: Was der > Bauer nicht kennt, frisst er nicht. Naja, wie ich das verstanden habe, wird ja FAKTISCH bereits ein VCS eingesetzt -- der Bauer frisst also durchaus, was in kleinen Häppchen in seine Kartoffelsuppe gemischt wird, solange er es nicht merkt. Das Kernproblem ist nur: Änderungen in den Verantwortlich- keiten kann man auf Dauer nicht gegen den Widerstand des Chefs durchsetzen, das ist zumindest meine Erfahrung.
Wolfgang S. schrieb: > H. E. schrieb: >> Zusammenfassend wie ich das sehe. >> >> Versionskontrolle: Unbedingt >> Eigenbrötler: besser als nichts >> Besser noch: Spielraum für Überzeugen schaffen anstatt als einziger mit >> dem Kopf durch die Wand. > > Ich würde "besser als nichts" zwar in der Form "immerhin ein Anfang" ins > Positive wenden wollen, ansonsten aber kein Einwand. "Mit dem Kopf durch > die Wand" funktioniert nicht. Aber es gilt auch, besser vormachen als > nur reden. > > Darauf kann man sich einigen, denke ich. Ich bin bei dir! :)
Possetitjel schrieb: > Naja, wie ich das verstanden habe, wird ja FAKTISCH > bereits ein VCS eingesetzt -- der Bauer frisst also > durchaus, was in kleinen Häppchen in seine Kartoffelsuppe > gemischt wird, solange er es nicht merkt. Anders gesagt schmeckt ihnen der anderen Leute Speck in der Suppe ganz hervorragend, bloß die eigene Sau, die wollen sie natürlich nicht schlachten.
Christopher J. schrieb: > Anders gesagt schmeckt ihnen der anderen Leute Speck in der Suppe ganz > hervorragend, bloß die eigene Sau, die wollen sie natürlich nicht > schlachten. Nein, sie möchten nicht von jemandem abhängig sein, der zwei Schritte weiter ist, nicht bereit ist einen zurück zu gehen und für den Bernd K. schrieb: > Auslachen, umdrehen und weggehen? zumindest eine Option ist. Christopher J. schrieb: > Frag ihn einfach mal ob er weiß was ein > Busfaktor ist und erkläre ihm dann, das dieser bei euch ziemlich genau > exakt 1 beträgt (in Worten EINS ;) Naja, ich glaube der TO muss nicht mehr beweisen, wie klasse er ist und wie doof alle anderen.
Michael R. schrieb: > Johannes O. schrieb: >> [...] Projektberichte und wissenschaftliche Arbeiten [...] >> Später wird dann alles in einem Merge zusammengeführt. > > merge und binary beisst sich doch meistens... außer du erstellst deine > Projektberichte und wissenschaftliche Arbeiten in einem non-binary > Format (TeX?) Ja, hatte ich vergessen zu erwähnen! Ist praktisch alles LaTeX, darum klappt das auch sehr gut.
Johannes O. schrieb: > Michael R. schrieb: >> Johannes O. schrieb: >>> [...] Projektberichte und wissenschaftliche Arbeiten [...] >>> Später wird dann alles in einem Merge zusammengeführt. >> >> merge und binary beisst sich doch meistens... außer du erstellst deine >> Projektberichte und wissenschaftliche Arbeiten in einem non-binary >> Format (TeX?) > > Ja, hatte ich vergessen zu erwähnen! Ist praktisch alles LaTeX, darum > klappt das auch sehr gut. ach du Glücklicher... ;-)
Achim S. schrieb: > Christopher J. schrieb: >> Anders gesagt schmeckt ihnen der anderen Leute Speck in der Suppe ganz >> hervorragend, bloß die eigene Sau, die wollen sie natürlich nicht >> schlachten. > > Nein, sie möchten nicht von jemandem abhängig sein, der zwei Schritte > weiter ist, nicht bereit ist einen zurück zu gehen und für den > > Bernd K. schrieb: >> Auslachen, umdrehen und weggehen? > > zumindest eine Option ist. Die Abhängigkeit ist doch jetzt schon da. Der Chef sollte froh darüber sein, dass er jemanden hat, der bereit ist sein Wissen zu teilen und weiterzugeben. Es gibt genug Leute die so eine Situation schamlos ausnutzen und sich für unverzichtbar erklären. Sobald jemand in die Nähe kommt, der auch nur von weitem so aussieht als könnte er das Know-How-Monopol gefährden, wird dieser dann so schnell es geht aus dem Team, der Abteilung oder der Firma geekelt. Was meinst du mit "nicht bereit ist einen [Schritt] zurück zu gehen"? Warum sollte der TO das machen? Sollte er die Versionsverwaltung komplett einstellen, den anderen Recht geben, sich heimlich die Hände reiben und voller Freude dabei zusehen wie es dann richtig knallt?
Christopher J. schrieb: > Die Abhängigkeit ist doch jetzt schon da. Ja, und das ist das Problem: Der Chef könnte ihn rein formaljuristisch abmahnen (oder Schlimmeres), weil er der ausdrücklichen Anweisung "keine Versionsverwaltung" zuwidergehandelt hat. Keine gute Situation. > Der Chef sollte froh darüber sein, dass er jemanden > hat, der bereit ist sein Wissen zu teilen und > weiterzugeben. Das, was der TO will, beeinflusst die Aufteilung der Kompetenzen im Team. Das wäre "eigentlich" Kernfeld des Chefs -- und viele (schlechte) Chefs sind sehr empfindlich, wenn sich dort ein Untergebener einmischt. > Was meinst du mit "nicht bereit ist einen [Schritt] > zurück zu gehen"? Chef und Kollegen nicht vor vollendete Tatsachen stellen. Mitstreiter suchen statt Konfrontation. > Warum sollte der TO das machen? Weil das der erfolgversprechendere Weg ist :) > Sollte er die Versionsverwaltung komplett einstellen, den > anderen Recht geben, sich heimlich die Hände reiben und > voller Freude dabei zusehen wie es dann richtig knallt? Nein.
Christopher J. schrieb: > Was meinst du mit "nicht bereit ist einen [Schritt] zurück zu gehen"? Ein einfacheres VCS zum Einstieg, Wir haben SVN, aber selbst Manager ohne jeden Entwickler-hintergrund nutzen es, weil tortoise den Einstiegs-aufwand auf ein paar Erklärungen reduziert und es für Windows-nutzer nathlos ist.Ich kenne kein nerdfreies git-äquivalent.
Christopher J. schrieb: > Warum sollte der TO das machen? Sollte er die Versionsverwaltung > komplett einstellen, den anderen Recht geben, sich heimlich die Hände > reiben und voller Freude dabei zusehen wie es dann richtig knallt? "VCS sind also spezialisierte BackupSysteme für Softwareentwickler". "VCS sind Gedächtnisstützen und Rettungsanker für Programmierer." "Als Entwickler können sie mithilfe eines VCS wesentlich angstfreier arbeiten" aus ISBN: 978-3-89721-567-2 S.297 -> Man braucht kein VCS um den Knall zu verhindern, durchdachtes backup ist ne brauchbare Alternative. Je vergesslicher und ängstlicher der Coder, desto mehr verlangt er nach VCS.
Claqueur schrieb: > -> Man braucht kein VCS um den Knall zu verhindern, durchdachtes backup > ist ne brauchbare Alternative. Je vergesslicher und ängstlicher der > Coder, desto mehr verlangt er nach VCS. Das ist also Deine Schlussfolgerung aus diesem Buch? Lass mich raten: Du gehörst auch zur Verweigererfraktion und suchst verzweifelt nach Argumenten, und seien sie auch noch so absurd?
Claqueur schrieb: > -> Man braucht kein VCS um den Knall zu verhindern, durchdachtes backup > ist ne brauchbare Alternative. Nicht wirklich. Konkretes Beispiel: wie durchsuchst Du denn das Backup z.B. nach dem Commit, welcher einen Fehler reingebracht hat? Das wäre ja wohl in etwa so: - nehme den Backup-Ordner in der Mitte zwischen dem letzten "OK"-Stand und jetzt - prüfe, ob es geht oder nicht - iteriere diese binäre Suche, bis der richtige Ordner gefunden ist - mache ein Diff zwischen diesem Ordner und dem Backup davor (Winmerge) Da es mangels VCS ja nun keine Commits mit brauchbarem Commit-Log gibt, sind die Änderungen auch nicht thematisch sortiert. Dann stehst Du da und kannst alle Änderungen im Ordner nacheinander händisch durchprobieren. Noch lustiger, wenn bestimmte Änderungen zusammengehören, weil sonst kein Build geht (das hätte man mi VCS in einem Commit zusammengefaßt). Die Folge wäre außerdem, daß man manuell die Branches und Tags von SVN mit der richtigen Benennung von Ordnern nachbildet. Wie immer, wenn man einen Ablauf automatisieren kann, dauert die manuelle Variante aber länger und ist anfälliger für Fehler. Übrigens braucht man bei VCS immer noch eine Backup-Startegie, schließlich kann ja auch die Platte im Server sich mal zerlegen, oder Wasserschaden, oder Blitzschaden.
Bernd K. schrieb: > Überzeugungsarbeit leisten? Auslachen, umdrehen und weggehen? Warum so aufwendig? Warte einfach ab bis es knallt und es zu einem Problem kommt weil die Versionskontrolle fehlt. Einfach etwas Geduld haben.
Backup mit history.... Ich glaub der Grund warum man VCS erfunden hat war daß man davon weg wollte.
Achim S. schrieb: > Ein einfacheres VCS zum Einstieg, > > Wir haben SVN, aber selbst Manager ohne jeden Entwickler-hintergrund > nutzen es, weil tortoise den Einstiegs-aufwand auf ein paar Erklärungen > reduziert und es für Windows-nutzer nathlos ist.Ich kenne kein > nerdfreies git-äquivalent Es gibt TortoiseGit, was die GUI angeht herrscht da also Gleichstand. Und es muss auch keineswegs "nerdfrei" oder Manager-kompatibel sein, alle beteiligten Personen beherrschen fließend mehrere Programmiersprachen, können hochkomplexe Zusammenhänge durchschauen, wir sprechen hier nicht von hilflosen BWL-Krawatten. Umsomehr erstaunt es mich daß ausgerechnet so eine vergleichsweise simples Idee wie einem Dateisystem noch eine Zeitdimension (und noch eine weitere für alternative Zeitlinien) hinzuzufügen durch die man dann genauso simpel navigieren kann wie durch die räumliche angeblich so eine unüberwindliche Verständnishürde sein soll an der fachliche Kapazitäten höchsten Kalibers inakzeptabel lange zu knabbern hätten während jeder 14 jährige Nachwuchsprogrammierer nicht das geringste Problem damit hat. Bezüglich SVN: das ist bereits aus dem Rennen, das ist vom Verständnis her auch nicht einfacher als git, da wäre also nichts gewonnen, aber vom technischen Standpunkt und der Usability verliert es haushoch, das fängt schon damit an daß es zwingend einen Server voraussetzt und jede Operation mit einer Gedenksekunde (oder Minute) bestraft wird. So ein veraltetes Zeug will ich im Jahre 2018 keinem ans Bein binden. Git ist ausgereift und hat sich großflächig als Stand der Technik etabliert, das hat es nicht ohne Grund geschafft, das ist also eine sinnvolle Wahl.
Bernd K. schrieb: > und hat sich großflächig als Stand der Technik etabliert, das > hat es nicht ohne Grund geschafft, das ist also eine sinnvolle Wahl. Selbst MS hat das nun prominent im TFS Umfeld mit eingepflegt und im Studio integriert.
ich würde einfach mal fragen, wie man derzeit Revisionssicherheit und Beweisführung in einem möglichen Klagefall erreicht.
Bernd K. schrieb: > Gerade bei leichtgewichtigen DVCS wie git oder hg deren Benutzung so gut > wie keinen Overhead erzeugen. Von welchem Git redest du ? https://git-scm.com/ ist keineswegs ein Leichtgewicht und zwingt bei jedem commit zu unendlichem Arbeitsaufwand. Ein gutes VCS erfordert seitens des Entwicklers KEINEN Arbeitsaufwand beim einchecken. Nicht mal den Aufruf eines Batch-Skriptes. Git erfordert fetch, merge (hoffentlich geht alles glatt, den anderen Fall will ich gar nicht ansprechen mit den durch Diff-Marker zerschossenen Source-Dateien), commit, commit-Kommentar, push, für jede winzige Änderung (Semikolon vergessen...), schlicht kranker Wahnsinn.
Bernd K. schrieb: > Es gibt TortoiseGit, was die GUI angeht herrscht da also Gleichstand. Nein, ist es nicht. Tortoise-Git ohne CLI-Gehacke geht auf Dauer nicht, und Git hat ein ohne Sinn und Verstand wüst zusammengewürfeltes CLI. Es hat außerdem keine Abstraktion, weswegen man sich mit den Implementationsdetails von Git herumschlagen muß, ein typisches Kennzeichen schlechter Nutzerschnittstellen. Die Anforderung, daß Programmierer gefälligst leidensfähig genug zu sein haben, um schlechte UIs zu tolerieren, ist vollkommen daneben. Schlechte UIs kosten nämlich auch mehr Zeit. Git hat genau dann seine Stärken, wenn man mit 1000 Leuten global verteilt am selben Projekt arbeitet, das ist mit SVN einfach nicht sinnvoll möglich. Für typische Industrieprojekte mit einer Handvoll Entwickler, die sowieso im Intranet sind, ist Git unnötiger Overkill und allenfalls aus Hipstergründen vorzuziehen. Zudem möchte man sowieso ein zentrales Repo auf dem Server haben, was auch korrekt gebackupt wird. Tortoise-SVN funktioniert im Gegensatz zu Tortoise-Git so, wie man sich das denkt. Es wird auch nie ein gutes GUI für Git geben, weil der Designfehler von Git der ist, daß keine Workflows definiert wurden, sondern Features. Ein typisches Rezept, was für Server, Protokolle usw. gut ist, für Anwendungssoftware aber immer schon versagt hat. Die paar Gedenksekunden von SVN werden hundertfach wieder wettgemacht, sobald jemand das erstemal stundenlang rumgoogelt, wie man Git jetzt dazu kriegt, das zu tun, was man erwartet. Alternativ drückt man diese Aufgabe kurzerhand dem vehemenesten Git-Supporter in der Firma auf. Zusätzlich zu seinen bisherigen Aufgaben, versteht sich. Übrigens sollte Dir die Beliebtheit von Github sehr zu denken geben. Wieso setzt sich ein Service durch, der das D in DVCS großteils wieder zunichte macht? Und wieso ist dieser nicht-Opensource-Dienst sogar bei Opensource-Entwicklern so beliebt bis hin zum Quasi-Monopol? Könnte es an der unterirdischen Benutzbarkeit liegen, die durch diese Abstimmung mit Füßen empirisch bestätigt wurde? Zudem ist der Mehrwert von "kein VCS" auch nur zu CVS riesig, von CVS zu SVN mäßig, und (mit Ausnahme des genannten Falles von 1000 Leuten global) von SVN zu Git vernachlässigbar.
Gerade dann, wenn man alleingelassen wird, ist - nach meiner Meinung - Mercurial prima. Es ist jederzeit möglich, auch ohne Netz zu arbeiten, Dein/ein "privates" Reposity zu nutzen und trotzdem - falls gewünscht - mit einem zentralen zu arbeiten. Passende Befehle sind implementiert. Ich habe alles, was ich brauche, auf einen Stick geklatscht und mache nur - relativ regelmäßig - eine (Sicherheits-)Kopie. Bzw. synchronisiere es mit einer zweiten Version. Dank ständig steigender Stickgrößen, habe ich bisher auch keine Probleme meinen Kram unterzubringen. Normalerweise reicht sogar ein etwas älterer.
Moin, mal wieder bezeichnend, wie hier wieder eine Menge Laberköppe und Trolle die Diskussion stören. Oder sind es doch nur renitente Wohlfühlprogrammierer? Bernd K. schrieb: > Und es muss auch keineswegs "nerdfrei" oder Manager-kompatibel sein, > alle beteiligten Personen beherrschen fließend mehrere > Programmiersprachen, können hochkomplexe Zusammenhänge durchschauen Das verstehe ich immer wieder nicht: Wie kann jemand, der eine Menge Codezeilen schreibt, auf einer IDE beharren und sich weigern, in einer CLI ein paar Kommandos zu tippen? Es ist auch nichts weiteres als eine Sprache. Das sind für mich die Wohlfühlprogrammierer, die sich dann oft als nicht teamfähig rausstellen. Ok, sind wir uns einig, das Problem ist NICHT technischer Art. Und es gibt nach wie vor eine Menge Firmen, die sehenden Auges auf den Abgrund zusteuern, weil der Chef nicht über sein Ego springen kann. Dementsprechend würde ich mir auch anhand der Managementstrukturen und Arbeitsweise des Teams das richtige VCS aussuchen. DAS allgemein richtige VCS gibt es nicht und es nimmt einem auch nicht idiotische Commit-Strategien ab. SVN hat schon noch seine Vorteile gegenüber git, aber setzt ein recht disziplinierte Entwicklungsstrategie voraus, die kaum einer konsequent durchzieht. Ab einem gewissen Schwellwert des aligen Entwickelns oder sowas komplexem wie Linux-Kernel-Source kommt man halt nur an git kaum vorbei. Für das hybride Arbeiten gibts's halt dann noch git-svn. Prinzipiell würde ich behaupten, dass es jeder hinbekommt, seinen (getesteten!) Code schlicht per
1 | git pull |
2 | git add -u . |
3 | git commit -m "Hab ich geändert" |
einzuchecken. Alle fortgeschrittenen Operationen sollten dann dem
Release-Manager ('prof7bit' ? :-) ) zumutbar sein, und auch so, dass er
sich nicht mit seinem VCS-Vorstoss zusätzliche Arbeit ans Bein bindet.
Wohlfühlcoder, die diesen pragmatischen Schritt nicht vollziehen,
haben's in agilen Entwicklungsfirmen nach meiner Erfahrung längerfristig
schwer.
Denn schlussendlich gilt: Zeit ist Geld.
Man sollte nicht nur den Normalfall berücksichtigen. Gerade auch, wenn man mal etwas falsch macht, muss man aus dieser Falle auch wieder rauskommen. Da bin ich immer wieder froh Kollegen zu haben, die mir aus der Patsche helfen. Und ich finde dies sind die Situationen, bei denen sich der Lernaufwand zeigt.
für einfache Workflows reicht mir für git auch der GitHub Desktop. Damit zum Beispiel mal eben die Versionen und Konfigexperimente für die 3D-Drucker Software zu verwalten bekommt man auch ohne Informatik Studium hin. Und es ist um Längen übersichtlicher als jede Menge kopierter und auskommentierter Codezeilen. Mit so einfachen Beispielen und einem einfachen Workflow kann man sich gut da rein arbeiten und mit git anfreunden. Das Gute daran ist das eben keine externen DB Tools nötig sind, wenn GitHub nicht reicht (weil es das sehr mächtige git nur eingeschränkt visualisiert) kann man auch mit dem CLI oder anderen Tools parallel arbeiten, das sehe ich als grossen Vorteil.
Dr. Sommer schrieb: > Der normale Workflow ist doch, öfter mal zu > committen, und wenn das Feature fertig ist, das in den master-Branch zu > mergen. Richtig. Ich versteh gar nicht, wie Leute auf die Idee kommen, nicht zu comitten ,vor Allem dann nicht, wenn das feature noch nicht fertig ist. Wenn man das dann noch nicht einmal in den Master-Branch mergen will, dann ist der Workflow kaputt. Im Ernst: Gibt es wirklich Leute, die im "normalen" Leben SO sprechen? Irrsinn. -Paul-
Paul B. schrieb: > Im Ernst: Gibt es wirklich Leute, die im "normalen" Leben SO sprechen? Bitte übersetze die Aussage doch mal in ein für dich ordentliches Deutsch. Das Resultat wäre, dass niemand mehr versteht wovon man redet. Die quasi-genormten Fachbegriffe dienen einer exakten Bezeichnung ohne Missverständnisse. Das ist in anderen Branchen (z.B. Luftfahrt) nicht anders. Aber keine Sorge, dich betrifft das sowieso nicht, außer Sprüchen hast du nichts drauf und als ewig gestriger kannst und willst du auch nichts dazulernen. Also vernüge dich mit deinen unlustigen Schmähungen. Mehr bleibt dir ja gar nicht.
MaWin schrieb: > https://git-scm.com/ ist keineswegs ein Leichtgewicht und zwingt bei > jedem commit zu unendlichem Arbeitsaufwand. Bullshit! Der Windowsnutzer macht im einfachsten Falle: Rechtsklick -> commit -> Meldung reinschreiben -> [commit] klicken. oder wenn er nur Teile committen will: Rechtsklick -> commit -> Häkchen wegmachen bei denen die man jetzt noch nicht committen will -> Meldung reinschreiben -> [commit] klicken. Erzähl doch mal wo das einfacher gelöst ist. Klar, auf der Kommandozeile gehts noch einfacher aber wir orientieren uns ja am Windows-Nutzer und die haben meist eine abweichende Definition von "Einfach".
Martin S. schrieb: > Alle fortgeschrittenen Operationen sollten dann dem > Release-Manager ('prof7bit' ? :-) ) zumutbar sein, Richtig. Nur gibts diesen wohl in einer Firma ohne bestehender Versionsverwaltung noch nicht. Und die, die lernwillig sind, scheinen noch nicht auf einer Position zu sein, diesen Posten zu übernehmen.
Bernd K. schrieb: > Der Windowsnutzer macht im einfachsten Falle: Der Stress beginnt, wenn er etwas eingecheckt hat, was nicht rein sollte. Alles lösbar. Brauchst du mir nicht zu erklären. Es sind aber die Fälle, bei denen die Neulingen Probleme haben.
Bernd K. schrieb: > alle beteiligten Personen ... können hochkomplexe Zusammenhänge > durchschauen... . Umsomehr erstaunt es > mich daß ausgerechnet so eine vergleichsweise simples Idee ... so eine > unüberwindliche Verständnishürde sein soll an der fachliche Kapazitäten > höchsten Kalibers inakzeptabel lange zu knabbern hätten während jeder 14 > jährige Nachwuchsprogrammierer nicht das geringste Problem damit hat. Ist genauso wie mit Matlab/Simulink - für jeden Ingenieur eine Selbstverständlichkeit, während die programmiererfahrenen superschlauen Informatiker lieber mit ihren umständlichen textbasierten Programmiersprachen rumkrebsen! -Duck und Wech-
Also ich als durchaus ernsthaft programmierender Hobbyist versteh hier nur Bahnhof. Was zum Teufel soll Git & Co, für die es allein schon dicke Handbücher gibt, mir noch bringen als nur zusätzlich Aufwand? Mein Code für ein Projekt entwickelt sich von ersten Anfängen bis zu einer Endversion, da sind nicht endlos Zwischenstände separat festzuhalten und (im Team) zu verwalten. Mit den zwei simplen Elementen Auskommentierung und Windows-Ordnerstruktur bin ich doch hinreichendst bedient ?! Ich finde man sollte sich das Leben nicht unnötig schwer machen!
Hobby-Programmierer schrieb: > Ich finde man sollte sich das Leben nicht unnötig schwer machen! Ich denke mal, es ist kein ernstgemeinter Beitrag. Für Neulinge sehe ich den Vorteil, dass sie nicht ausversehen, wie bei den Kopierorgien, sich mal schnell eine alter Version überschreiben.
Martin S. schrieb: > Das verstehe ich immer wieder nicht: Wie kann jemand, der eine Menge > Codezeilen schreibt, auf einer IDE beharren und sich weigern, in einer > CLI ein paar Kommandos zu tippen? Es ist auch nichts weiteres als eine > Sprache. > Das sind für mich die Wohlfühlprogrammierer, die sich dann oft als nicht > teamfähig rausstellen. > Das ist jemand, der auch lieber Visual-Studio oder Eclipse oder ... nimmt anstatt vi oder was anderes uraltes. > Denn schlussendlich gilt: Zeit ist Geld. Dann sollte man lieber nicht git nehmen, was ich schon an komischen Fehlermeldungen gesehen habe, für die es letztendlich keine Lösung gab (ja -> Workspace neu anlegen, Änderungen einpflegen, und dann mit git einchecken war dann beim zweiten mal merkwürdigerweise möglich).
Hobby-Programmierer schrieb: > Mit den zwei simplen Elementen Auskommentierung > und Windows-Ordnerstruktur bin ich doch hinreichendst bedient ?! > Ich finde man sollte sich das Leben nicht unnötig schwer machen! Probier's einfach mal aus, und lass dir die Versionsstände und Unterschiede mal mit eclipse darstellen. Es ist einfach befreiend, alle alten auskommentierten Codestellen furchtlos löschen zu können, weil sie ja in der Historie noch drin sind. Bei kniffligen Aufgaben hat man davon eine Menge. Gleiches gilt für radikale Umbauten des Codes - man kann einfach fröhlich dran rum basteln, ohne befürchten zu müssen, etwas zu verlieren. Ich benutze git auch für jedes Mini-Projekt, es kostet ja nix einmal "git init" einzugeben. Andreas S. schrieb: > Wieso schaffen es Autofanatiker eigentlich niemals, über ihren eigenen > Tellerrand bzw. das Lenkrad hinauszuschauen? Wie kommst du auf sowas? Ich habe schon CVS, SVN und git benutzt, warum sollte ich mich jetzt noch extra mit Uralt-Systemen wie RCS auseinandersetzen? Außerdem hat FS nichts mit Autofanatikern zu tun, die sind mehr in Tuning-Werkstätten zu finden. FS ist teilweise innovativer als die Industrie...
Hobby-Programmierer schrieb: > Ich finde man sollte sich das Leben nicht unnötig schwer machen! ich finde man sollte mittlerweile vor dem Programmieren lernen erstmal ein VCS zu Nutzen lernen.
xxx schrieb: > Das ist jemand, der auch lieber Visual-Studio oder Eclipse oder ... > nimmt anstatt vi oder was anderes uraltes. Ach, in der MS-Welt hatte man das mit der CLI-Phase auch mal, so in den 80ern unter DOS. Manche finden das heute noch cool. Das ist so ein bißchen wie Spoiler an nem Golf: die einzigen, die das cool finden, sind welche, die selber einen Spoiler am Golf haben. Der Rest der Welt sagt nur "oh mann".
Dr. Sommer schrieb: > Wie kommst du auf sowas? Ich habe schon CVS, SVN und git benutzt, warum > sollte ich mich jetzt noch extra mit Uralt-Systemen wie RCS > auseinandersetzen? Ich habe nicht gesagt, dass Du mit RCS arbeiten sollst, sondern welches auch heute noch der Anwendungsfall für RCS ist: einzelne Konfigurationsdateien auf Systemen zu versionieren. Wenn Du solche Anforderungen nicht hast, musst Du sie auch nicht berücksichtigen. Es wäre aber Unsinn, zwigend Git auf einem System zum Laufen zu bringen, auf dem ein RCS vorhanden ist und bei dem man überhaupt keine weiteren Features von Git o.ä. benötigt. > Außerdem hat FS nichts mit Autofanatikern zu tun, die > sind mehr in Tuning-Werkstätten zu finden. FS ist teilweise innovativer > als die Industrie... Genau das meine ich doch. Die Arroganz und Engstirnigkeit der Autofanatiker. Und Formula Student gehört definitiv dazu.
Andreas S. schrieb: > Es > wäre aber Unsinn, zwigend Git auf einem System zum Laufen zu bringen, > auf dem ein RCS vorhanden ist und bei dem man überhaupt keine weiteren > Features von Git o.ä. benötigt. Es sei denn, man hat keine Lust mehrere VCS zu lernen. Die meisten Server z.B. sollten genug Leistung haben auch git zu verkraften. Andreas S. schrieb: > Genau das meine ich doch. Die Arroganz und Engstirnigkeit der > Autofanatiker. Und Formula Student gehört definitiv dazu. Stimmt allerdings, FS ist an vielen Hochschulen einfach das anspruchsvollste Projekt. Das ist nichts für Party-Studenten die einmal im Monat an der Hochschule sind und ohne Schritt-für-Schritt-Anleitung nichts zuwege bringen.
Johannes S. schrieb: > Hobby-Programmierer schrieb: >> Ich finde man sollte sich das Leben nicht unnötig schwer machen! > > ich finde man sollte mittlerweile vor dem Programmieren lernen erstmal > ein VCS zu Nutzen lernen. Och man kann auch gut mit Versionen arbeiten ohne ein computergestütztes Versionssystem einzusetzen. Schon die Maschinenbauer vor hundert Jahren konnten easy verschiedenen Musterständer verwalten und zwischen diesen Up und Downgraden. das haben sie sich wohl von den Militärs mit Mark1, Mark2, Mark3, ... abgeschaut und die Olivgrünen machen das schon seit dem 19. Jahrhundert. Wahrscheinlich ein Kind der industriellen Massenproduktion
Christopher J. schrieb: > Was meinst du mit "nicht bereit ist einen [Schritt] zurück zu gehen"? Ok, hier lag ich falsch. Der TO ist wohl mit git groß geworden, sicher auch Linux-Experte und kennt gar nichts anderes, siehe: Bernd K. schrieb: > Es gibt TortoiseGit, was die GUI angeht herrscht da also Gleichstand. > Und es muss auch keineswegs "nerdfrei" oder Manager-kompatibel sein, > aber vom technischen Standpunkt und der Usability verliert [SVN] haushoch > zwingend einen Server voraussetzt > Git [..] hat sich großflächig als Stand der Technik etabliert
Klartexter schrieb: > Schon die Maschinenbauer vor hundert Jahren die haben auch noch mit Tusche auf Papyrus gezeichnet, wer will das heute noch?
Achim S. schrieb: > Christopher J. schrieb: >> Was meinst du mit "nicht bereit ist einen [Schritt] >> zurück zu gehen"? > > Ok, hier lag ich falsch. ??? > Der TO ist wohl mit git groß geworden, sicher > auch Linux-Experte und kennt gar nichts anderes, siehe: Vielleicht ist das ein Teil des Problems?
Hobby-Programmierer schrieb: > Also ich als durchaus ernsthaft programmierender Hobbyist versteh hier > nur Bahnhof. Was zum Teufel soll Git & Co, für die es allein schon dicke > Handbücher gibt, mir noch bringen als nur zusätzlich Aufwand? Na ja, stell dir vor, du entwickelst mit einer IDE, da trägst du alle Quelldateien zusammen die das Projekt ausmachen und die IDE weiss was sie temporär und als Ergebnis daraus erzeugt. Du überarbeitest den Code, und entdeckst irgendwann einen Fehler, und du fragst dich, seit wann der drin ist, das ging doch früher. Wie einfach wäre es, jetzt in jeder Datei nachsehen zu können wann und welche Änderungen es gab, wie einfach wäre es, zu jedem älteren Kompilat automatisch die damaligen Quelldateien im Debugger zu Hand zu haben und nicht ein blöde IDE die rumschimpft daß sie dir den Quelltext nicht mehr anzeigen kann, wie einfach wäre es wenn du ein neues Programmteil ausprobierst, feststellst daß es Unsinn war und du gehst einfach zurück zum Anfang, verwirfst alle Änderungen seit dem. Das alles kann ein Versionsverwaltungssystem sogar für den Einzelnutzer, der sich zudem nicht mit dem mergen von Änderungen von anderen Leuten rumplagen muss. Leider funktionieren aktuelle VCS nicht so. Die haben nicht nur dicke Handbücher, sondern fordern von dir VOR jeder später mal möglichen Aktion daß du vorauseilend und in 99% der Fälle umsonst heftig Arbeit aufhalst. Du musst definieren was eingecheckt wird und was nicht, obwohl die IDE das schon weiss. Die fordern daß jede Änderung nochmal eingecheckt wird, obwohl die IDE vor dem kompilieren schon automatisch speichert, die fordern von dir bei jedem einchecken einen Kommentar einzugeben obwohl der Kommentar was-warum-geändert-wurde schon im Quelltext steht den sie einchecken, und die fordern von dir TAGs anzugeben, damit du auf solche Versionen zurückgehen kannst, obwohl die IDE bei jedem Kompilat eigentlich von selbst einen snapshot machen könnte. Aktuelle VCS sind unsäglicher Schrott, und die open source Entwickler sind zu dumm sich überhaupt vorstellen zu können wie es programmiert sein könnte. Mindestbedingung ist, daß sie in der laufenden Arbeit keinerlei zusätzliche Arbeit erfordern, sondern nur dann, wenn du wirklich mal Nutzen aus ihnen ziehen willst, also Altversionen angucken oder Änderungen verwerfen, und dann sollten sie die Arbeit einfacher machen als du es ohne sie hättest. Das erinnert an ISAM und SQL: Beim einen Datenbanksystem musst du VORHER überlegen welche Abfragen hinterher mal stattfinden könnten, bei anderen kannst du dann wenn du musst schon die passende Anfrage formulieren und musst dich vorher nicht um eine eventuell mal in 2 Jahren nötige Sache kümmern und dich hinterher in den Arsch beissen wenn du vorher nicht dran gedacht hattest. Bei Eclipse beispielsweise hätte man Compiler und VCS in einer IDE. Aber sie funktioniert nicht so. Sie erfordert trotzdem, jede Arbeit doppelt und dreifach zu machen. Ganz nebenbei ist EGit einfach nur kaputt und voller Bugs. Bei VSS war es etwas besser integriert.
Michael B. schrieb: > Du musst definieren was eingecheckt wird und was nicht, obwohl > die IDE das schon weiss. Die fordern daß jede Änderung nochmal > eingecheckt wird, obwohl die IDE vor dem kompilieren schon automatisch > speichert, OMG, jeder fehlgeschlagene Kompilierversuch soll kommentarlos protokolliert werden? Nicht dein Ernst, oder? Eingecheckt wird was funktioniert und das kann man auch in einem Satz kommentieren.
Johannes S. schrieb: > Eingecheckt wird was funktioniert und das kann man auch in einem Satz > kommentieren. Härter: Nur was funktioniert resp "compiliert ohne Abbruch" wird eingecheckt,. Einfach mal einchecken weil 5 vor Feierabend macht keinen Sinn. >Klartexter schrieb: >> Schon die Maschinenbauer vor hundert Jahren >die haben auch noch mit Tusche auf Papyrus gezeichnet, wer will das >heute noch? Nee, die haben die Zeichnungen für die Diesellok die deinen Arsch durch die Gegend schaukelt übern Plotter gejagt und die Versionsnummer säuberlich in das dafür gedachte Zeichnungsfeld gesetzt. Versionsverwaltung macht auch für nicht Codierschweine Sinn. Die sollen mal nicht glauben die hätten die Ingenieurskunst erfunden - haben sie nicht, sie äffen sie nur auf digitale Art und Weise nach. Und ob sie die Philosophie dahinter verstanden haben, wäre auch zu hinterfragen.
Michael B. schrieb: > Leider funktionieren aktuelle VCS nicht so. Die haben nicht nur dicke > Handbücher, sondern fordern von dir VOR jeder später mal möglichen > Aktion daß du vorauseilend und in 99% der Fälle umsonst heftig Arbeit > aufhalst. Du musst definieren was eingecheckt wird und was nicht, obwohl > die IDE das schon weiss. (bin aber kein git Profi, ist evtl. auch falsch): git commit -a > Die fordern daß jede Änderung nochmal > eingecheckt wird, obwohl die IDE vor dem kompilieren schon automatisch > speichert, Also ich fasse mehrere Änderungen zusammen und checke dann ein, jede Änderung einchecken ... um Gottes willen > die fordern von dir bei jedem einchecken einen Kommentar Wenn man keine Lust dazu hat, gibt man halt ein Leerzeichen ein. Manche VCS können diesen Zwang auch übergehen mit einer - zugegeben - obskuren Kommandozeilenoption. > einzugeben obwohl der Kommentar was-warum-geändert-wurde schon im > Quelltext steht den sie einchecken, und die fordern von dir TAGs TAGs sind immer optional und nur sinnvoll wenn man ein Release erstellt hat das man herausgibt. Immer TAGs machen wäre nicht sinnvoll > anzugeben, damit du auf solche Versionen zurückgehen kannst, obwohl die > IDE bei jedem Kompilat eigentlich von selbst einen snapshot machen > könnte. Warum Versionsverwaltung so sehr schlecht reden? Bei meinen Ex-Kollegen fand ich es am ANfang meiner "Karriere" auch schrecklich wie die Ihre Sourcen sicherten: Auf dem Netzwerklaufwerk ein BAK Verzeichnis, dort dann die Sourcen und wieder ein BAK Verzeichnis usw. Überhaupt keine Übersicht! Auch selbst hatten die keine Übersicht mehr nach längerer Zeit. Ich hatte damals einfach für mich dann CVS verwendet (Repository auf dem Netzwerklaufwerk). Ein- auschecken und Versionen vergleichen, war super einfach. Die damaligen Kollegen hatten das dann nach und nach einfach übernommen (ohne Zwang und ohne meckern).
ich muss gestehen, ich bin einigermaßen überrascht, was manche hier von sich geben, im Jahr 2018... ich wäre eigentlich davon ausgegangen, dass die (konsequente) Verwendung eines SCM im beruflichen Umfeld eigentlich seit 15 Jahren eine Selbstverständlichkeit ist... war wohl ein Irrtum. Wie kommt man ohne sowas an Kunden, und behält diese? ich denke, ich muss "Musings about SCM" auf die Agenda meiner Bewerbergespräche setzen ;-) und nein, ich rede nicht von supply chain management
xxx schrieb: > Warum Versionsverwaltung so sehr schlecht reden? Tut er nicht. Genauer hinhören. Er kritisiert des Userinterface, nicht Ziel, Zweck und Leistungsumfang.
Dr. Sommer schrieb: > Es sei denn, man hat keine Lust mehrere VCS zu lernen. Die meisten > Server z.B. sollten genug Leistung haben auch git zu verkraften. Es interessiert überhaupt nicht, dass die meisten Server hinreichend leistungsfähig sind, wenn das ganz konkrete System, auf dem man eine Versionierung von Konfigurationsdateien durchführen will, dies nicht bietet. Ich rede hierbei nicht von "normalen" Servern oder Arbeitsplatzrechnern mit einer vollwertigen Linux- oder Windowsinstallation, sondern (wie oben schon erwähnt) z.B. Firewalls oder vom Netzwerk isolierten Rechnern. Gerade bei letzteren müsste man ggf. einen gewaltigen bürokratischen Aufwand betreiben, um eine Drittsoftware zu installieren. Und warum, wenn ggf. RCS schon vorhanden ist, wie bei sehr vielen (Embedded) Linux oder UNIX-Derivaten. Natürlich kann man von Party-Studenten nicht die Flexibilität erwarten, sich für den Alltagsgebrauch die Kommandos "ci -l", "co" und "rlog" zu merken. > Stimmt allerdings, FS ist an vielen Hochschulen einfach das > anspruchsvollste Projekt. Das mag sicherlich zutreffen. Daraus jedoch zu schließen, dass es außer Autobasteln keinerlei andere Arbeitsgebiete geben darf, ist jedoch reichlich vermessen.
Michael R. schrieb: > ich wäre eigentlich davon ausgegangen, dass die (konsequente) Verwendung > eines SCM im beruflichen Umfeld eigentlich seit 15 Jahren eine > Selbstverständlichkeit ist "Konsequente Verwendung"?!? -OMG- ich dachte es geht um Sinnvolle Verwendung! Und wenn es um Sinn und Unsinn geht, dann gibt es seit 25 Jahren keinen sinnvollen Grund eine neuartige Versionsverwaltungphilosophier samt tools auf den markt zu bringen. Trotzdem geschieht genau dass und irgendwelche Milchbärte drohen dann den alten Hasen mit Konsequenzen wenn sie nicht wie die anderen Codierschweine in der Herde auf das "einzig Wahre" KlickiKacki-tool setzen. Kein Wunder wenn erfahrenene Programmierer ihre eigenen tools/Ablagesysteme benutzen und das Company-tool nur zum "über die Mauer werfen" einsetzen, damit das Projektleiterhansel endlich Ruhe gibt.
Klartexter schrieb: > Kein Wunder wenn erfahrenene > Programmierer ihre eigenen tools/Ablagesysteme benutzen und das > Company-tool nur zum "über die Mauer werfen" einsetzen, damit das > Projektleiterhansel endlich Ruhe gibt. Genau deswegen möchte ich... Michael R. schrieb: > "Musings about SCM" auf die Agenda meiner > Bewerbergespräche setzen ;-) diese Art "erfahrene Programmierer" möchte ich nämlich gerne identifizieren...
Michael R. schrieb: > Wie kommt man ohne > sowas an Kunden, und behält diese? Von welchem Umfeld redest du? Ich kenne das Vorgehen ohne Versionsverwaltung überwiegend von Geräteherstellern mit kleiner Softwareabteilung. Im allgemeinen werden die älteren Versionen später nicht mehr benötigt.
Michael R. schrieb: > Genau deswegen möchte ich... > > Michael R. schrieb: >> "Musings about SCM" auf die Agenda meiner >> Bewerbergespräche setzen ;-) > > diese Art "erfahrene Programmierer" möchte ich nämlich > gerne identifizieren... ...um sie dann abzulehnen, schätzungsweise. Das kann aber auch nach hinten losgehen.
Possetitjel schrieb: > Michael R. schrieb: > >> Genau deswegen möchte ich... >> >> Michael R. schrieb: >>> "Musings about SCM" auf die Agenda meiner >>> Bewerbergespräche setzen ;-) >> >> diese Art "erfahrene Programmierer" möchte ich nämlich >> gerne identifizieren... > > ...um sie dann abzulehnen, schätzungsweise. Das kann aber > auch nach hinten losgehen. Nein. "Diese Art" agiert in höchstem Maße unprofessionell und man kann sich nur versuchen so weit wie möglich von denen fern zu halten.
Steffen R. schrieb: > Ich kenne das Vorgehen ohne Versionsverwaltung > überwiegend von Geräteherstellern mit kleiner > Softwareabteilung. Im allgemeinen werden die älteren > Versionen später nicht mehr benötigt. Ich habe mal bei einem (sehr) kleinen Gerätehersteller gearbeitet. VCS wäre schon sinnvoll gewesen -- aber vielleicht hätte man erstmal damit anfangen sollen, für JEDEN angenommenen Auftrag ein SCHRIFTLICHES Angebot und eine SCHRIFTLICHE Bestellung zu formulieren und an die Bearbeiter weiterzuleiten. Es ist nämlich nicht witzig, wenn man kurz vor dem Versand merkt, dass man gar nicht so ganz genau weiss, was eigentlich zu liefern ist. :/
Steffen R. schrieb: > Von welchem Umfeld redest du? Guter Einwand! Steffen R. schrieb: > Ich kenne das Vorgehen ohne > Versionsverwaltung überwiegend von Geräteherstellern mit kleiner > Softwareabteilung. Im allgemeinen werden die älteren Versionen später > nicht mehr benötigt. Abgesehen davon dass SCM etwas mehr bietet als "alte Versionen aufbewahren", werden auch Gerätehersteller mit Qualitätsanforderungen konfrontiert sein (nehme ich zumindest mal an). SCM ist für mich in erster Linie ein Tool zur Qualitätssicherung (welche zumindest in meinem Umfeld auch auditiert wird). Jetzt werden sich die "erfahrenen Programmierer" gleich mit Graus abwenden, weil die Jungs aus der QS, die mögen wir ja gar nicht... bringen null Umsatz, und nur Ärger... Possetitjel schrieb: > ...um sie dann abzulehnen, schätzungsweise. Das kann aber > auch nach hinten losgehen. kann sein. vielleicht hatte ich Glück, aber ich kenne niemanden der ohne SCM arbeiten will
Possetitjel schrieb: > ...um sie dann abzulehnen, schätzungsweise. Das kann aber > auch nach hinten losgehen. Nein, ewiggestrige Nörgler braucht kein Mensch. Solche Leute gehören so gut wie nie zu den Leistungsträgern oder bringen nennenswerte Ergebnisse zustande und bilden sich auf ihre Mindererzeugnisse wunderwas ein. Gottseidank, sind solche Typen in der Minderheit, sonst wären wir ein übles Dritte-Welt-Land, die sollen froh sein, dass man sie mit durchschleppt. Wenn das git interface so ein Graus wäre, dann hätte sich so ein laberkopp schon längst mal hinsetzen können und es nach seinen Vorstellungen verbessern, aber offensichtlich ist das für Millionen von Entwicklern mit unterschiedlichem Können (vom Anfänger bis zum Experten) und Alter kein Problem. Der Profi kennt und nutzt das Tool was zum jeweiligen Problem am besten passt.
Andreas S. schrieb: > Ich rede hierbei nicht von "normalen" Servern oder Arbeitsplatzrechnern > mit einer vollwertigen Linux- oder Windowsinstallation Ja, das ist ein ziemlicher Sonderfall. Ich verwalte alle Konfig Dateien meines Servers in einem zentralen git Repo, welches dann im Gitlab auf selbigem Server liegt... Andreas S. schrieb: > Daraus jedoch zu schließen, dass es außer Autobasteln keinerlei andere > Arbeitsgebiete geben darf, ist jedoch reichlich vermessen. Wer tut sowas?
Possetitjel schrieb: >> diese Art "erfahrene Programmierer" möchte ich nämlich >> gerne identifizieren... > > ...um sie dann abzulehnen, schätzungsweise. Ganz genau dafür ist diese Identifikation gedacht. > Das kann aber auch nach hinten losgehen. Deswegen gilt es ja, im Vorstellungsgespräch nicht nur herauszufinden, dass derjenige diese oder jene Methoden ablehnt, sondern warum er das tut. Es kann in seiner bisherigen Position ja durchaus wichtige Gründe geben, die den Einsatz einer bestimmten Methode verhindern. Jedoch sollte derjenige schon auf einer eher abstrakten Ebene erklären können, wo die Einsatzgebiete von Methoden liegen. Interessanterweise ist Verbohrtheit bei solchen Dingen keine Frage des biologischen Alters. Bei Anfängern basiert sie darauf, dass sie noch nicht den Überblick über die Grenzen ihrer präferierten Methoden haben und die in der Ausbildung mühsam erlernten Methoden für universell gültig halten. Und bei Älteren liegt es häufig daran, dass sie an ehemals sehr erfolgreichen Methoden festhalten und nicht merken, dass die früheren Rahmenbedingungen nicht mehr zutreffen. Allen Altersgruppen gemein ist aber ggf. die mangelnde Bereitschaft, sich mit neuen Themen zu beschäftigen. Ich hatte vor etlichen Jahren einen jungen promovierten Kollegen, der sich nach nur ca. 8 Monaten Arbeit an einem eher exotischen Thema (GSM-Protokollstack, Schicht 3, Supplementary Services) so sehr darauf fixiert hatte, dass für ihn die Welt zusammenbrach, als sein Projekt eingestellt wurde und er fortan an anderen Themen (ISDN-Protokollstackentwicklung) arbeiten sollte. Er erhob den Anspruch, bis zur Rente nur noch an seinem Thema arbeiten wollen. Letztendlich verließ er das Unternehmen, um zu einem bekannten finnischen Unternehmen zu wechseln. Mir ist nicht bekannt, wie er die Sache verkraftete, als dort auch die Telefone ausgeschaltet wurden. Womöglich musste er dort aber auch bei seinem Einstieg schmerzhaft lernen, dass GSM zu dem Zeitpunkt entwicklungsmäßig schon abgeschlossen, UMTS aktuell und LTE in den Startlöchern befindlich war.
Abradolf L. schrieb: > Der Profi kennt und nutzt das Tool was zum jeweiligen Problem am besten > passt. Das passt ja eigentlich zu dem, was Andreas Schweigstill schreibt. Problem: Bürokratie Tool: was halt schon da ist, darf dann auch was altes sein (solange es nicht MKS heisst :-))
Dr. Sommer schrieb: > Ja, das ist ein ziemlicher Sonderfall. Ich verwalte alle Konfig Dateien > meines Servers in einem zentralen git Repo, welches dann im Gitlab auf > selbigem Server liegt... Befindet sich das Git-Repository womöglich auf einem anderen Dateisystem als die wichtigsten Konfigurationsdateien (/etc o.ä.)? Wie kommst Du an das Repository heran, wenn sich z.B. in /etc/fstab oder der LVM-Konfiguration ein Fehler befindet, der dafür sorgt, dass das betreffende Dateisystem nicht angebunden wird?
Andreas S. schrieb: > GSM zu dem Zeitpunkt entwicklungsmäßig schon abgeschlossen Nachdem er bei den Finnen ist, wird er wohl mit GSM-R bis zur Persion durchkommen (einer meiner größeren Kunden macht damit immer noch gutes Geld)
Andreas S. schrieb: > Befindet sich das Git-Repository womöglich auf einem anderen Dateisystem > als die wichtigsten Konfigurationsdateien (/etc o.ä.)? Nein. Andreas S. schrieb: > Wie kommst Du an > das Repository heran, wenn sich z.B. in /etc/fstab oder der > LVM-Konfiguration ein Fehler befindet, der dafür sorgt, dass das > betreffende Dateisystem nicht angebunden wird? Manuelles Mounten oder im allerschlimmsten Fall, über das Backup. Außerdem habe ich eine Working Copy in /root, welches ja normalerweise kein separates Dateisystem ist.
Michael R. schrieb: > kann sein. vielleicht hatte ich Glück, aber ich kenne niemanden der ohne > SCM arbeiten will Vor nicht allzu langer Zeit unterhielt ich mich mit zwei Bekannten, die ebenfall ein Ingenieurbüro im Elektronikbereich hatten, über das Thema. Denen sagte Versionskontrolle usw. überhaupt nichts und prahlten damit, jeden Abend eine ZIP-Datei ihrer Arbeit zu erzeugen und abzulegen. Aber auch bei anderen Themen waren sie (vorsichtig ausgedrückt) nicht unbedingt auf dem neuesten Stand. Recht unverständlich fand ich es daher, dass sie etlichen Kunden hatten, die den teilweise technisch veralteten und dilletantisch angefertigten Kram auch noch abnahmen.
Michael R. schrieb: > Jetzt werden sich die "erfahrenen Programmierer" gleich > mit Graus abwenden, weil die Jungs aus der QS, die mögen > wir ja gar nicht... bringen null Umsatz, und nur Ärger... Naja, aber das kann doch tatsächlich die persönliche Erfahrung der "alten Hasen" sein. Dass sie auf die Jungs aus der QS nicht gut zu sprechen sind, heißt doch nicht, dass sie keine Qualitätsarbeit leisten wollen.
Possetitjel schrieb: > Michael R. schrieb: > >> Jetzt werden sich die "erfahrenen Programmierer" gleich >> mit Graus abwenden, weil die Jungs aus der QS, die mögen >> wir ja gar nicht... bringen null Umsatz, und nur Ärger... > > Naja, aber das kann doch tatsächlich die persönliche > Erfahrung der "alten Hasen" sein. > > Dass sie auf die Jungs aus der QS nicht gut zu sprechen > sind, heißt doch nicht, dass sie keine Qualitätsarbeit > leisten wollen. Es gibt einen großen Unterschied zwischen "Qualitätsarbeit leisten" und "Qualität messbar machen", letzteres kann durchaus lästig sein. Eine Anekdote eines Kunden: Wir haben dort den Reklamationsprozess überarbeitet, und auch das Tool dafür neu entwickelt. Das Tool stand außer Frage, aber der neue Prozess war mit Mehraufwand verbunden. Die PA (=QS) hat dann (ängstlich) zu einer Vorstellung eingeladen, adressiert an "PA und Freunde", weil laut PA-Leiter "dann kommt keiner, weil wir haben keine Freunde" ;-)
Possetitjel schrieb: > xxx schrieb: > >> Warum Versionsverwaltung so sehr schlecht reden? > > Tut er nicht. Genauer hinhören. > > Er kritisiert des Userinterface, nicht Ziel, Zweck und Leistungsumfang. Es ist als Programmierer ganz wichtig auf keinen Fall hinzuhören und die begründete Kritik der (teilweise zwangsweisen) User zu verstehen, sonst könnte man sich nicht jeden Tag auf die Schulter klopfen welche grandiose Nerd-Idee man heute wieder passend zum Modetrend abliefert, garantiert unpassend zu allem was die User brauchen und haben wollen. Ganz wichtig ist auch, niemals die Software selbst zu verwenden die man so programmiert hat, nur das bringt den nötigen Abstand zum eigenen Produkt.
Undenkbar... Bei uns wäre die SVN Verweigerung definitiv ein Kündigungsgrund! 1. Warnung 2. Abmahnung 3. Kündigung ratz fatz
Andreas S. schrieb: >> Das kann aber auch nach hinten losgehen. > > Deswegen gilt es ja, im Vorstellungsgespräch nicht > nur herauszufinden, dass derjenige diese oder jene > Methoden ablehnt, sondern warum er das tut. Darauf wollte ich hinaus; das kam mir bisher ein wenig zu kurz. > Allen Altersgruppen gemein ist aber ggf. die mangelnde > Bereitschaft, sich mit neuen Themen zu beschäftigen. Hmm, naja, ich will ja gerade darauf hinaus, dass es durchaus unterschiedliche Gründe für diese mangelnde Bereitschaft gibt. "Neu" bedeutet in der IT leider nicht unbedingt "besser" oder "nachhaltiger". Auch an sich nützliche neue Software kann z.B. ein derart grausames Userinterface haben, dass man sich damit nicht weiter beschäftigen will. > Er erhob den Anspruch, bis zur Rente nur noch an seinem > Thema arbeiten wollen. Ich verstehe; ich kenne das duraus auch von mir selbst. Der Punkt ist aber: Das hat nicht unbedingt damit zu tun, dass man generell NEUEM gegenüber nicht aufgeschlossen wäre, sondern sondern damit, dass man seine Begeisterung für ein Thema nicht beliebig an- und ausknipsen kann.
Johannes S. schrieb: > OMG, jeder fehlgeschlagene Kompilierversuch soll kommentarlos > protokolliert werden? Nicht dein Ernst, oder? Nicht nur Ernst, sondern selbstverständlich. Bei einem guten System fällt das gar nicht auf, was er eincheckt und es spielt auch keine Rolle. So viel wie möglich, kann man nur sagen. Erst beim auschecken ist relevant was man auschecken kann. Da zeichnet ein gutes System natürlich die erfolgreichen builds besonders: Schon alleienn weil sie wie es für seriöse Programmier erfoderlich ist eine eindeutige build-ID tragen, die natürlich eingecheckt ist, und es natürlich immer möglich sein muss, zu jedem gebuildeten auch die dazugehörigen Sourcen jederzeit wiederholen zu können. Richtig ist: Man braucht vermtulich niemand Zwischenstände zwischen den builds. Aber das ist egal ob sie drin sind, wenn das einchecken keinerlei Mühe macht. Wir hatten sogar ein System, bei dem man bei jeder Datei undo-mässig jede Edieraktion bis hin zur leeren Datei rückgängig machen konnte als komplette Versionshistorie, die Speicheraktionen tauchten darin mit timestamp besonders hervorgehoben auf. xxx schrieb: > Also ich fasse mehrere Änderungen zusammen und checke dann ein, jede > Änderung einchecken ... um Gottes willen > Wenn man keine Lust dazu hat, gibt man halt ein Leerzeichen ein. Tja ja, wenn das VCS Extraaufwand bedeutet, wird man halt nachlässig und umgeht es wo man nur kann.
@Andreas >Denen sagte Versionskontrolle usw. überhaupt nichts und prahlten damit, >jeden Abend eine ZIP-Datei ihrer Arbeit zu erzeugen und abzulegen. Aber >auch bei anderen Themen waren sie (vorsichtig ausgedrückt) nicht >unbedingt auf dem neuesten Stand. Regelmäßig ein Zip-Archiv erstellen ist auch eine Art der Versionskontrolle. Wahrscheinlich ist der Hauptunterschied die zeitliche Abhängigkeit. >Recht unverständlich fand ich es daher, dass sie etlichen Kunden hatten, >die den teilweise technisch veralteten und dilletantisch angefertigten >Kram auch noch abnahmen. Ich kann nur für Mercurial sprechen, aber bisher habe ich noch kein einziges mal die Meldung: "Behalt doch Deinen Sch** für Dich", bekommen. Ich gehe davon aus, das auch für die anderen Versionsverwaltungen gilt: Was Du speicherst wird gespeichert. Ob Schei* oder Qualitätscode, ist wohl gleichwertig.
Possetitjel schrieb: > xxx schrieb: > >> Warum Versionsverwaltung so sehr schlecht reden? > > Tut er nicht. Genauer hinhören. Das sehe ich anders: Michael B. schrieb: > Aktuelle VCS sind unsäglicher Schrott, und die open source Entwickler > sind zu dumm sich überhaupt vorstellen zu können wie es programmiert > sein könnte. Übrigens könnte man alle diese Dinge die gefordert waren, d.h. automatisches einchecken nach (erfolgreicher) Kompilierung, etc. ohne weiteres in jedes x-beliebige Makefile einbauen, so dass man das aus Eclipse, XYZ-Studio oder was auch immer, vollautomagisch macht. Dazu würde natürlich gehören, sich von seiner Verweigerungshaltung etwas frei zu machen, sich mit der Materie auseinanderzusetzen und das selber zu implementieren (mit git, hg, was auch immer), wozu die "open source Entwickler zu dumm sind". Mit git wäre das ein Zweizeiler, in etwa:
1 | $(TARGET).elf: $(OBJ) |
2 | gcc $^ -o $@ |
3 | git add -A . |
4 | git commit -am "Ich mag keine commit-messages!" |
und wenn du willst kommt eben noch ein "git push" hinzu, dann sind es drei Zeilen. Jetzt kannst du mit irgendeiner grafischen Oberfläche dir die Versionshistorie jeder Datei anschauen, zu einem alten Stand zurückkehren, bestimmte Revisionen (optional!) mit Tags versehen, etc. Ich bin zwar der Meinung, das Commit-Messages durchaus sehr sinnvoll sind und das "git add -A ." nicht sinnvoll ist aber soll jeder machen wie er meint.
Christopher J. schrieb: > Übrigens könnte man alle diese Dinge die gefordert waren, d.h. > automatisches einchecken ... > etwa:$(TARGET).elf: $(OBJ) > gcc $^ -o $@ > git add -A . > git commit -am "Ich mag keine commit-messages!" Automatische commits ohne Kommentar sind IMHO eine Perversion der Versionsverwaltung. Sinn der Vesrionsverwaltung ist doch nach Bedarf einen identifizierbaren Stand aus dem Archiv zurückzuholen. Wie will man einen Stand als zurückholenswert erkennen, wenn es an einem Tag 20 Stände ohne erklärenden Kommentar gibt? Warum einen Stand archivieren den niemals irgendjemand zurück holen wird und dessen diff zu Vorgänger und Nachfolger so aussagekräftig ist wie die Anzahl von halben Körnern in einem Sack Reis?
Klartexter schrieb: > Automatische commits ohne Kommentar sind IMHO eine Perversion der > Versionsverwaltung. Gebe ich dir vollkommen recht und wenn ich irgendwelche Commit-Messages wie "first", "second", etc lese wird mir ganz übel. Deswegen schrieb ich ja auch Christopher J. schrieb: > Ich bin zwar der Meinung, das Commit-Messages durchaus sehr sinnvoll > sind und das "git add -A ." nicht sinnvoll ist aber soll jeder machen > wie er meint. Es ging mir nur darum zu zeigen, dass die von Michael Bertrandt skizzierte Funktionsweise des (seiner Meinung nach!) bestmöglichen VCS, absolut problemlos mit Git nachzustellen ist und er sich daher mit der Aussage Michael B. schrieb: > Aktuelle VCS sind unsäglicher Schrott selbst widerspricht.
Andreas S. schrieb: >> Stimmt allerdings, FS ist an vielen Hochschulen einfach das >> anspruchsvollste Projekt. > > Das mag sicherlich zutreffen. Daraus jedoch zu schließen, dass es außer > Autobasteln keinerlei andere Arbeitsgebiete geben darf, ist jedoch > reichlich vermessen. Völliger Schwachsinn...gerade wer in seinem Studium in der FS mitgemacht hat, weiß ganz genau wieviel mehr Arbeitsgebiete es noch gibt. Dir hätten ein paar Semester in so einem Projekt gutgetan-man merkt, daß du das nicht hattest. Schade. Um nicht ganz OT zu sein: In der FS hatte ich überhaupt das erste Mal Kontakt mit Versionskontrolle. Wir haben allerdings SVN benutzt.
Christopher J. schrieb: > Übrigens könnte man alle diese Dinge die gefordert waren, d.h. > automatisches einchecken nach (erfolgreicher) Kompilierung, etc. ohne > weiteres in jedes x-beliebige Makefile einbauen Na ja, all die Dinge die ich für gute Useability genannt habe nicht, du hast dir nur ein einfaches, aber unzureichend realisiertes, rausgepickt. Du musst bei VCS erst mal festlegen, welche Dateien eingecheckt werden, obwohl das ja schon im IDE Projekt steht. Also doppelte Arbeit. Auch die kann man automatisieren, ja, aber den Skript möchtest du bestimmt nicht bauen, selbst wen man sich auf eine einzige Plattform "nur Visual Studio Projekte" beschränkt. Dann checkst du nach dem build alles ein, gut, aber ich schrieb schon "Kommentare stehen schon in code" und der sollte natürlich in der VCS Übersicht dann sichtbar sein. Das zu automatisieren bedeutet, in den geänderten Zeilen die Kommentare zu finden, mehrfach denselben nur 1 mal zu nutzen, eventuell von Tara zu befreien, und kompakt ins Kommentarfeld zu bekommen. Wenn mehr als 1 Datei und mehr als 1 Änderung dabei ist, macht ein häufiges Einchecken schon Sinn, und xxx Vorgehensweise "Also ich fasse mehrere Änderungen zusammen" eher nicht. Auch hier könnte man mit AWK&Co. extrahieren, viel Spass bei Erstellung der Skripte. Kennzeichnend ist bei deinem Sktipt auch, daß kein fetch gemacht wird, aber vielleicht ein push. Das geht i.A. in die Hose. Ich bestehe nicht darauf, bei merge-Kollisionen automatisch zu branchen, obwohl ich das arbeitsangemessen finde, denn niemand will sich ZU DIESEM ZEITPUNKT ums manuelle mergen kümmern. Aber, man wäre ja schion glücklich, wenn CVS und EGit bloss nicht so vor Programmierfehlern wimmeln würden, und bei EGit hat man den Eindruck als ob die Ersteller das Konzept nie verstanden haben, weil die Benutzerführung durch die Menükommandos/Dialoge eher in die Irre und zur Fehlbedienung verleiten, als hilfreich zu sein.
Michael B. schrieb: > Du musst bei VCS erst mal festlegen, welche Dateien eingecheckt werden, > obwohl das ja schon im IDE Projekt steht. Also doppelte Arbeit. Vernünftige IDE's wie Eclipse oder MSVC legen automatisch .gitignore Dateien an. Wenn du dann einfach alles hinzufügst, ist alles da außer den Build-Daten. Außerdem weiß z.B. Eclipse nicht explizit, was zum Projekt gehört - das nimmt einfach alle Dateien, die im Verzeichnis sind. Michael B. schrieb: > Aber, man wäre ja schion glücklich, wenn CVS und EGit bloss nicht so vor > Programmierfehlern wimmeln würden, Was hast du denn da für Probleme? Das einzige Problem was ich mit EGit je hatte war Java schuld...
Dr. Sommer schrieb: > Was hast du denn da für Probleme? Bei EGit funktioniert eine ganze Reihe der Menü-Kommandos nicht und CVS hat ein Problem mit Gross/Kleinschreibung Dateinamen. Dr. Sommer schrieb: > Vernünftige IDE's wie MSVC legen automatisch .gitignore Dateien an. https://stackoverflow.com/questions/2143956/gitignore-for-visual-studio-projects-and-solutions ??
Michael B. schrieb: > Bei EGit funktioniert eine ganze Reihe der Menü-Kommandos nicht Dann ist bei dir was kaputt. Mal ne aktuelle Eclipse-Version installiert? Das tut bei mir alles gut. Besonders hübsch find ich die History-Anzeige, insb. wenn "Show all Branches and Tags" an ist. Michael B. schrieb: > https://stackoverflow.com/questions/2143956/gitignore-for-visual-studio-projects-and-solutions > ?? Wie hier schon geschrieben ist: https://stackoverflow.com/a/19625167 "here's the default one which Visual Studio 2013 RTM automatically generates when creating a new Git-Repository:" ... MSVC legt eine .gitignore an. Wenn man die nicht mag, kann man da ein Standard-gitignore runterladen. Was an einer gepflegten .gitignore vorteilhaft ist: git kann automatisch alles löschen, was nicht zum Repo gehört (EGit: Team->Advanced->Clean) - so erhält man auf einen Rutsch einen sauberen Stand. Man bräuchte nichtmal "make clean" und das löscht auch alle anderen manuell angelegten Dateien.
Michael B. schrieb: > Dann checkst du nach dem build alles ein Das hattest du für besonders sinnvoll erachtet: Michael B. schrieb: > Bei einem guten System fällt das gar nicht auf, was er eincheckt und es > spielt auch keine Rolle. So viel wie möglich, kann man nur sagen. Was die Commit-Message angeht: Michael B. schrieb: > aber ich schrieb schon > "Kommentare stehen schon in code" und der sollte natürlich in der VCS > Übersicht dann sichtbar sein. Das zu automatisieren bedeutet, in den > geänderten Zeilen die Kommentare zu finden, mehrfach denselben nur 1 mal > zu nutzen, eventuell von Tara zu befreien, und kompakt ins Kommentarfeld > zu bekommen. Das hattest du nicht so genau beschrieben bzw. ich habe es nicht so verstanden wie du es meintest. Klar ist das möglich aber ich halte es für nicht sinnvoll, weil du nämlich in deinem Quelltext eher dokumentierst was du machst und warum und eben nicht, was sich zur letzten Revision geändert hat. Das gehört eben in die Commit-Message und deswegen ist es konträr zu deiner Anforderung: Michael B. schrieb: > Mindestbedingung ist, daß sie in der laufenden Arbeit > keinerlei zusätzliche Arbeit erfordern, sondern nur dann, wenn du > wirklich mal Nutzen aus ihnen ziehen willst, also Altversionen angucken > oder Änderungen verwerfen, und dann sollten sie die Arbeit einfacher > machen als du es ohne sie hättest. Achja und > Kennzeichnend ist bei deinem Sktipt auch, daß kein fetch gemacht wird, > aber vielleicht ein push. war bezogen auf > Das alles kann ein Versionsverwaltungssystem sogar für den Einzelnutzer, > der sich zudem nicht mit dem mergen von Änderungen von anderen Leuten > rumplagen muss. Das muss dann natürlich klar sein, dass an dem externen Repo von keiner anderen Person bzw. anderen Maschine etwas geändert wird, jedenfalls nicht in der gleichen Branch. Du kannst nicht sagen "Ich hätte gerne die komplette Funktionalität von Git aber bitte ohne das ich einen Finger krumm machen muss." Das ist wie "Wasch mich aber mach mich nicht nass." Michael B. schrieb: > Aber, man wäre ja schion glücklich, wenn CVS und EGit bloss nicht so vor > Programmierfehlern wimmeln würden, und bei EGit hat man den Eindruck als > ob die Ersteller das Konzept nie verstanden haben, weil die > Benutzerführung durch die Menükommandos/Dialoge eher in die Irre und zur > Fehlbedienung verleiten, als hilfreich zu sein. Das sind alles Open-Source Projekte. Hilf den Leuten mit deinem Feedback und deinen Verbesserungsvorschlägen, dann werden deine Wünsche eventuell erhört. Die Entwickler als Idioten zu diffamieren bringt hingegen überhaupt nichts.
Christopher J. schrieb:
...
wenn jemand ein Haar in der Suppe finden will dann konstruiert er sich
es eben. (Stammt nicht von mir, Zitat C. Tönnies)
Ich denke MBs Anforderungen sind da sehr exklusiv, ich habe sowas
jedenfalls noch nie gehört. Sowas wie git hätte ich mir schon vor 30
Jahren gewünscht allein um mein eigenes Chaos besser in den Griff zu
kriegen, von einer ganzen Entwicklungsabteilung ganz zu schweigen.
Klartexter schrieb: > Automatische commits ohne Kommentar sind IMHO eine Perversion der > Versionsverwaltung. > > Sinn der Vesrionsverwaltung ist doch nach Bedarf einen identifizierbaren > Stand aus dem Archiv zurückzuholen. > Wie will man einen Stand als zurückholenswert erkennen, wenn es an einem > Tag 20 Stände ohne erklärenden Kommentar gibt? Sehe ich genauso. Sinn hinter dem dauereinchecken könnte sein, dass mit Trial- und Error gefrickel programmiert wird. Frei nach dem Motto, tut´s nicht, probier ich mal was anderes. Ach jetzt geht's gar nicht mehr, schnell zurück zum vorherigen Stand.
Meine Erfahrung: Ich habe es am Arbeitsplatz konsequent eingesetzt mit der Folge das mehr und mehr Kollegen dieses übernommen haben bzw. auf der Verwendung derartiger Tools aufsetzten ( Prozesse Dokumentation Normen Anforderungen 62304 etc. ). Der alte Greis konnte irgendwann nicht mehr anders als zuzugeben das die Nutzung eines VCS nicht die schlechteste Idee ist.
Bernd K. schrieb: > Aus gegebenem Anlass: Wie ist am besten damit umzugehen wenn jemand im > beruflichen Umfeld der auch mit Programmieren befasst ist vehement den > Standpunkt vertritt es sei zu umständlich die Bedienung eines VCS zu > erlernen, es "lohne" sich daher nicht. Wie geht Ihr mit sowas um? Souverän! (SCNR) Nein, im Ernst: bei uns käme zwar niemand auf die Idee, sich einem VCS zu verweigern, aber wir haben genügend andere Themen mit ähnlich gelagerten Verweigerungshaltungen. Es hat mich jeweils Monate an Überzeugungsarbeit gekostet, Valgrind, SonarCube und Selenium im Testing durchzusetzen, für Jenkins hatte ich glücklicherweise die Unterstützung einer wundervollen Kollegin. Im Moment arbeite ich daran, meine Kollegen davon zu überzeugen, Linuxpakete und Docker-Images für unsere Softwaredistribution, Redis als hochverfügbaren und horizontal skalierbaren Key-Value-Store zu benutzen, und hernach wird es um Elasticsearch, Kibana sowie Apache Storm gehen. Meine Methode, damit umzugehen, ist eine mehrgleisige Strategie: ich rede zunächst mit Kollegen, die für diese Themen offen und selbst interessiert sind, unsere Software, QA und Methodik zu verbessern. Gleichzeitig spreche ich mit unseren Vertrieblern und Beratern, wo es, und was sie drückt. Um Probleme lösen zu können, muß ich sie möglichst gut verstanden haben. Im zweiten Schritt spreche ich mit Skeptikern und Verweigerern über ihre Befürchtungen. Dabei ist es besonders wichtig, ihnen zuzuhören und genau wahrzunehmen, wo ihre Probleme liegen. Kaum weniger wichtig ist es aber, ihnen dabei zu kommunizieren, daß sie ernst genommen und ihre Probleme gelöst werden sollen, sollte es zum Einsatz der gewählten Tools kommen. Aus den so erworbenen (Er)Kenntnissen ergibt sich, wo es an Kenntnissen mangelt, welche rationalen und irrationalen Befürchtungen es gibt, sowie welche Probleme die von mir vorgeschlagenen Lösungen lösen können, quasi meine "unique selling points". Danach entwickle ich einen oder mehrere kleine, überschaubare und leicht verständliche Prototypen zur Demonstration, mit denen ich im Bedarfsfall zeigen kann: a) was ich will, funktioniert, b) es löst die Probleme X, Y und Z wie gewünscht, c) den Impact auf Performance und Stabilität können wir beherrschen, und d) der Nutzen ist größer als der Aufwand. Nach dieser durchaus aufwändigen, zeitraubenden und häufig wegen ihres hohen Zeit- und Geduldsbedarfs frustrierenden Vorarbeit entwickle ich daraufhin zwei Präsentationen, eine nichttechnische für die GL und die Vertriebler und eine deutlich technischer orientierte für das mittlere Management und die Berater und Entwickler. Und die halte ich dann, im Bedarfsfalle gern auch mehrmals und in jeder gewünschten Detailtiefe. Danach kann ich mich meistens zurücklehnen und die Kollegen untereinander diskutieren und kämpfen lassen. Natürlich kommen unterdessen immer wieder Rückfragen und oft auch gute Ideen, die ich noch gar nicht bedacht hatte. Hier sind vor allem Souveränität und Selbstbeherrschung wichtig: es gibt keine dummen Fragen, manche Dinge muß man eben zehnmal sagen oder gleich verständlich demonstrieren können. Bisher war ich mit dieser Strategie ziemlich erfolgreich. Sie funktioniert allerdings nur, wenn man eine gute Vertrauensbasis zu seinen Kollegen hat, interne Politik eine untergeordnete Rolle spielt und man wirklich fit mit der vorgeschlagenen Technologie ist. Und diese Strategie ist wirklich sehr zeitaufwändig, oft frustrierend, und es gibt keine Erfolgsgarantie. Aber am Ende ist es so, wie mein Schulfreund Jörn sagt: Menschen kann man nicht mit rein technischen Argumenten überzeugen, sondern nur emotional. Manchmal ist es ganz gut, einen studierten Sozialpädagogen zu haben. ;-) Ach ja, am Rande bemerkt: steter Tropen höhlt den Stein. Es hilft, immer wieder über das anliegende Thema zu sprechen und dabei immer wieder die Vorteile der gewünschten Lösung herauszustellen. ;-)
Abradolf L. schrieb: > Michael B. schrieb: > Was für Kraut baust du eigentlich in deinem Garten an? Das kann kein Kraut sein, eher Pilze oder Chemie. > Michael B. schrieb: >> Aber die aktuellen Implementationen, von SourceSafe über CVS und GIT >> sind > > Unglaublich, dass Millionen von Entwicklern auf dem Globus verteilt ohne > Probleme damit umgehen können Sein Nickname ist ja kein Zufall. ;-)
Hallo, Sheeva P. schrieb: > Bernd K. schrieb: >> Wie geht Ihr mit sowas um? > > Souverän! (SCNR) > > Nein, im Ernst: bei uns käme zwar niemand auf die Idee, sich einem VCS > zu verweigern, aber wir haben genügend andere Themen mit ähnlich > gelagerten Verweigerungshaltungen. > ... > Ach ja, am Rande bemerkt: steter Tropen höhlt den Stein. Es hilft, > immer wieder über das anliegende Thema zu sprechen und dabei immer > wieder die Vorteile der gewünschten Lösung herauszustellen. ;-) Beeindruckend! Bleibt dir dann eigentlich auch noch Zeit für deine "normale" Arbeit? rhf
Da ist die Firmenkultur schwer im Argen. Hat dein Chef noch einen Chef? 1. Mache auf das Problem aufmerksam. 2. Halte das schriftlich fest. 3. Sei nicht diplomatisch, aber auch nicht unverschämt. Halte in jedem Falle ungeschminkt fest: Das Fehlen eines Versionskontrollsystem macht das Unternehmen zur Klitsche. Bewirb dich aber vorher noch woanders und mache nichts ohne Fallnetz. Und wenn sich nichts ändern sollte, dann verlasse das Unternehmen, denn da ist Hopfen und Malz verloren. Bei uns wird Versionsverwaltung seit Anbeginn genutzt, ich schätze, da wurde schon in den 80ern mit begonnen. Und es ist wirklich alles drin, was zum Projekt gehört. Das Unternehmen, in dem ich arbeite, ist zwar etwas chaotisch, aber in diesem Punkte wird doch ein gewisser Standard erhalten. Sogar das Projektmanagement legt seine Word- und Excel-Dokumente im CVS/SVN/Git ab. Bei ganz alten Projekten wird CVS genutzt, bei mittelalten SVN und bei den neuen Git. Selbst das Unternehmen, in dem ich vorher war, hatte sein SVN-Repository, obwohl das Unternehmen sonst schlecht geführt war. Aber die haben erkannt: Die Software ist das Kapital des Unternehmens.
Paul H. schrieb: > b) Versuche nachzuvollziehen, wo die Verständnisprobleme bei deinem Chef > und deinen Kollegen bestehen. Versuche ihnen durch Beispiele zu > erklären, wo, wann und warum eine Versionskontrolle sinnvoll ist. > Untermauere das ganze ggf. mit einer kurzen Demonstration, wie einfach > es ist, das zu erlernen. Letzendlich kannst du ja ganz klar darlegen, > dass man einmal ein paar Stunden an Zeit investiert und dann dauerhaft > von der Zeitersparnis profitieren kann. Am Ende der Diskussion hast du > die beiden entweder überzeugt oder sie überzeugen dich, in dem sie > stichhaltige Argumente bringen. Mach das ganze nicht in der Kaffeepause > sondern bestelle sie zu einem Termin ein. Ich frage mich, was in dem Repository denn abgelegt werden soll. Dokumente an denen viele Menschen arbeiten? Software? In beiden Fällen braucht man ein Repository. Hat man im Unternehmen nur Dokumente, die man exklusiv bearbeitet, würde schon eine Backup-Lösung wie rsync reichen. Das Stichwort ist gemeinsam. Ein Vorteil eines Repositories ist, dass man sehr schnell Backup-Lösungen entwickeln kann, denn man muss nur noch das Repository sichern. Ein Vorteil einer Versionsverwaltung ist, dass man sehr schnell Rechner neu aufsetzen kann. Ich bekam vor einem halben Jahr einen neuen Rechner, der megaschnell eingerichtet war, weil das damals gegenwärtige Projekt in Nullkommanix auf der Platte hatte. Ich musste nur "git clone" aufrufen.
Sheeva P. schrieb: > Im Moment arbeite ich daran, meine Kollegen > davon zu überzeugen, Linuxpakete und Docker-Images für unsere > Softwaredistribution, Redis als hochverfügbaren und horizontal > skalierbaren Key-Value-Store zu benutzen, und hernach wird es um > Elasticsearch, Kibana sowie Apache Storm gehen. Was gibt Dir eigentlich die Sicherheit, daß -Du- mit Deinen Ansinnen auf dem richtigen Weg bist?
Michael B. schrieb: > Aber die aktuellen Implementationen, von SourceSafe über CVS und GIT > sind CVS mag ich nicht besonders im Handling, aber SVN ist doch kinderlicht, genauso wie Git, wobei SVN leichter zu verstehen ist. Ich möchte noch das Augenmerk auf Mercurial legen. Finde ich einfacher als Git. Git ist MacGyver, Mercurial James Bond.
Es ist interessant zu lesen, dass offenbar viele die gleichen Probleme haben. Wie sagt mein Chef so schön: egal in welcher Firma man arbeitet, die Summe der Scheiße ist konstant. Normalerweise verstehen 90% unserer Programmierer nach 15 Minuten Einweisung wie Tortoise SVN funktioniert und warum es gut ist das zu verwenden. Aber es gibt immer wieder "Experten", vor allem Ältere, die es so machen wollen, wie sie es schon immer gemacht haben. Da ersetzen dann dutzende Verzeichniskopien und ZIP-Files die Versionsverwaltung. Die begreifen es selbst dann nicht, wenn sie zu dritt an einem Projekt arbeiten und schon x mal Daten verloren gegangen sind, weil Änderungen nicht von allen kopiert wurden. Noch härter sind dann die Programmierer, die ihre "Versionsverwaltung" mit ZIP-Files auf USB-Stick machen. Weil ein USB-Stick ist ja so super sicher. Das "beste" was ich bisher erlebt habe war eine "Projektverwaltung" mit PCs. Das heißt, es wurde für jedes Projekt ein neuer PC eingerichtet und die Daten blieben am Ende des Projekts auf dem PC und dieser wurde dann ins Regal gestellt. Bis mal wieder an dem Projekt gearbeitet werden musste. Dann wurde der Projekt PC aus dem Regal geholt.
Sheeva P. schrieb: > Im Moment arbeite ich daran, meine Kollegen > davon zu überzeugen, Linuxpakete und Docker-Images für unsere > Softwaredistribution, Redis als hochverfügbaren und horizontal > skalierbaren Key-Value-Store zu benutzen, und hernach wird es um > Elasticsearch, Kibana sowie Apache Storm gehen. Bis man sich zu 90% mit den Tools beschäftigt und nicht mehr zum Arbeiten kommt. Es kann auch einen Overkill an Tools geben.
Claus M. schrieb: > Klartexter schrieb: >> Automatische commits ohne Kommentar sind IMHO eine Perversion der >> Versionsverwaltung. ... > Sehe ich genauso. > > Sinn hinter dem dauereinchecken könnte sein, dass mit Trial- und Error > gefrickel programmiert wird. Frei nach dem Motto, tut´s nicht, probier > ich mal was anderes. Ach jetzt geht's gar nicht mehr, schnell zurück zum > vorherigen Stand. OK, ich glaub jetztz nähert man sich dem Kern des Problems: Man kann eine Versionsverwaltung so benutzen das es keine Probleme löst sondern weitermachen lässt wie bisher aber denoch Cheffe beruhigt. Um einen solchen sinnfreien Umgang zu verhindern, tut der TO IMHO gut daran eine Selbsterfahrungsübung anzusetzen und ein paar Tips mitzugeben: Aufgabe: "Hier ist ein neuer Laptop, die IT spielt die Entwicklungsumgebung auf. Du bearbeitest jetzt das Projekt des Kollegen der schon auf Versionsverwaltung ist. Zieh die Sourcen des vovorletzen Lieferstand auf den neuen Rechner, compilier es und mache einen binärvergleich des erzeugte binaries mit dem damals geliefert.en" Umgangsregeln mit Quellcodeverwaltung: 1) Nur Sourcen und buildscripte einchecken, keine Compilate/Compiler. (Bemerkung: Compilate insbes. Lieferstände müssen aber auch gesichert werden, aber nicht im SourceVerwaltungssystem. Dafür gibt es ein seperates Backup-System) 2) Nur compilierfähige Sourcen/Scripte einchecken 3) Aussagekräftige Commitkommentare verfassen (Bemerkung: dazu ist es hilfreich zur Gedächtnisauffrischung vor dem Commit ein diff laufen zu lassen) 4) Tags/Labels nach Namensrichtlinien vergeben, Tags umfassen nicht nur sourcen, sondern auch zugehörige scripte/configs/versionsbeschreibende Doku 5) Regelmäßig (vor Lieferung sonst einmal im Monat) die Arbeitskopien löschen und die Sourcen mittels des pasenden Tags/Labels frisch aus der Versionsverwaltung holen und die oben beschriebene Aufgabe nachstellen. Übrigens, ich bin mir sicher das auch von denen die die Versionsverwaltung bereits nutzen, an der Aufgabenstellung scheitern. Es genügt nicht vom Verhindern des "Knalls" zu sprechen, man muss den "Knall" auch regelmäßig als Übung durchspielen. So wie bei einem Feueralarm.
Claqueur schrieb: > 5) Regelmäßig (vor Lieferung sonst einmal im Monat) die Arbeitskopien > löschen und die Sourcen mittels des pasenden Tags/Labels frisch aus der > Versionsverwaltung holen und die oben beschriebene Aufgabe nachstellen. Warum solltedas gut sein? Was anderes als bei 'update' sollte da herauskommen?
... schrieb: > Das "beste" was ich bisher erlebt habe war eine "Projektverwaltung" mit > PCs. Das heißt, es wurde für jedes Projekt ein neuer PC eingerichtet und > die Daten blieben am Ende des Projekts auf dem PC und dieser wurde dann > ins Regal gestellt. Bis mal wieder an dem Projekt gearbeitet werden > musste. Dann wurde der Projekt PC aus dem Regal geholt. So macht es auch die NASA, da war mal ein Bericht über das Voyager oder was Pioneer boden Team - da haben aller Rechner nen Aufkleber "Nicht wegwerfen". Heutige Software ist halt imkopatibel zu den Sun-Kisten von damals. Also "Ganzen Rechner Archivieren" ist die dümmste Idee nicht. Der böser Hacker Kim kann sich zwar aus der Ferne in nen Server hacken und Source korumpieren, aber Verfahren "Regalsicherung" scheitert er schon mit seiner Wampe am Überklettern des Hofzaunes.
Dumdi D. schrieb: > Claqueur schrieb: >> 5) Regelmäßig (vor Lieferung sonst einmal im Monat) die Arbeitskopien >> löschen und die Sourcen mittels des pasenden Tags/Labels frisch aus der >> Versionsverwaltung holen und die oben beschriebene Aufgabe nachstellen. > > Warum solltedas gut sein? Was anderes als bei 'update' sollte da > herauskommen? Es deckt halt auf was bei "update" fehlt, nicht geht, aber nicht auffällt weil es lokal verhanden oder modifiziert ist. -Nicht einegecheckte dateien, -filelocks wegen vermeintlichen merge oder sonstige Konflikten, -Begrenzungen des Filessystems (zu lange Pfadnamen), -Konflikte mit fileowner -Änderungen im Buildprozess wegen unterschiedlichen fileattributen oder Dateerstellungszeiten. -ausgechecktes shellscript läuft nicht weil die Fileendung (/LF versus /LF /CR) modifiziert wurde ... Auch bei der Arbeit mit Versioensmanagment gilt: "Was nicht getestete wurde - tut nicht".
Wolfram D. schrieb: > Ein Vorteil einer Versionsverwaltung ist, dass man sehr schnell Rechner > neu aufsetzen kann. Ich bekam vor einem halben Jahr einen neuen Rechner, > der megaschnell eingerichtet war, weil das damals gegenwärtige Projekt > in Nullkommanix auf der Platte hatte. Ich musste nur "git clone" > aufrufen. Ich wäre der Letzte, der originelle Nutzungen von Mercurial oder Git kritisieren würde. Aber genau so, wie es bessere Backuptools als ausgerechnet die DVCS gibt - man denke nur an die Probleme mit größeren Dateien und mit nicht textuell diffbaren -, gibt es auch für diese Aufgabe bessere und einfachere. Konkret, wenn ich sehr schnell Rechner neu aufsetzen möchte, dann benutze ich Ansible. Da gibt es sogar Module für die meisten (D)VCS http://docs.ansible.com/ansible/latest/list_of_source_control_modules.html Beispiel aus http://docs.ansible.com/ansible/latest/hg_module.html#examples
1 | # Example just get information about the repository whether or not it has |
2 | # already been cloned locally. |
3 | - hg: |
4 | repo: git://bitbucket.org/user/repo |
5 | dest: /srv/checkout |
6 | clone: no |
7 | update: no |
Dumdi D. schrieb: > Warum solltedas gut sein? Was anderes als bei 'update' sollte da > herauskommen? Ich hab's schon erlebt, daß so ein Vorhaben gescheitert ist, weil jemand die Projekt-Settings der IDE vergessen hat mit einzuchecken. Dummerweise hat die verwendete IDE aus diesen Settings den Startupcode automatisch generiert. Claqueur schrieb: > 1) Nur Sourcen und buildscripte einchecken, keine Compilate/Compiler. Man kann auch die Compilate mit einchecken, das ist Geschmackssache. Das macht man aber nur bei Lieferständen, die an irgendwen gehen, und sei es ans Testfeld. > 2) Nur compilierfähige Sourcen/Scripte einchecken Unbedingt. Ich krieg nen Hals, wenn ich "update" mache und dann nichtmal ein Build geht, weil der Kollege das nicht getestet hat. > 3) Aussagekräftige Commitkommentare verfassen Das hilft spätestens, wenn man tracken will, mit welchem Commit ein Fehler reingekommen ist. Daher bin ich auch gegen automatische Commits, weil dann kein brauchbares Log mehr da ist. Man muß nur aufpassen, daß man nicht aus Faulheit zu Monster-Commits neigt. Ich mach das so, daß ich committe, wenn ich ein Feature implementiert oder einen Bug behoben habe und bevor ich mich ans nächste mache. Daher können zu einem Commit auch mehrere Dateien gehören.
Claqueur schrieb: > Umgangsregeln mit Quellcodeverwaltung Irgendwo hab ich das schon mal gelesen, lass mich nachdenken, das muss in einer Werbebroschüre über das theoretische Phantasieleben gewesen sein. Claqueur schrieb: > 1) Nur Sourcen und buildscripte einchecken, keine Compilate/Compiler. Geil, geht spätestens in die Hose, wenn mal wieder ein Auto-Update den Compiler so erneuert hat, daß er alte Sourcen nicht kann. Sehr schön z.B. bei Java, auf der Insel leben bekanntlich die Wahnsinnigsten. Richtig ist: Normalerweise ändert sich die Arbeitsumgebung seltendst. Also ist gerade dabei ein einchecken unproblematisch, weil nur seltendst Daten übertragen werden. Da man aber auch altes mit neuem Comöiler bearbeiten will, müssen das 2 verschiedene Repositories sein. Damit man dann aber doch das zusammengehörige erkennt, ist ein TIMESTAMP die wichtigste Orientierung. > 2) Nur compilierfähige Sourcen/Scripte einchecken Für Laien die nur auf einer Plattform entwickeln mag man denken daß das reicht. Andere wissen nicht, was der nightly build heute auf den 5 anderen PLattformen daraus macht und zu bemeckern hat. > 3) Aussagekräftige Commitkommentare verfassen Supi. Du bist der Überflieger, der heuite weiss nach was morgen gesucht wird. Nein, auch du bist das nicht, also merken: Du weisst heute nicht, was morgen wichtig ist, daher KANN man hier nicht das später gesuchte schreiben. Es steht dir aber frei, vor jedem commit 2 Tage brainstorming nach der aussagekräftigsten Kommentarzeile zu machen. > 4) Tags/Labels nach Namensrichtlinien vergeben Geil-o-mat. Wer nie ein langlebiges Projekt hatte, weiss nicht, daß sich Richtlinien wie Säue in Dörfern verhalten. > 5) Regelmäßig Sich regelmässig Arbeit machen ? Hast du nichts wirkliches zu tun ? Wenn das nicht automatisiert ist, hat der Anwender wohl den Schuss nicht gehört.
Nop schrieb: > Daher können zu einem Commit auch mehrere Dateien gehören. Nur zur Ergänzung: Das würde ich als Fazit nicht so formulieren, weil das so klingt, als würde es eine Ausnahme beschreiben. Denn es ist ja eine der wichtigen Neuerungen moderner VCS, daß sie nicht dateiorientiert arbeiten, sondern auf Changesets basieren, die i.d.R. alle versionierten, modifizierten Dateien des Directorytrees in einem atomaren Commit zusammenfassen, was dann eben einen neuen Changeset in der Historie des Repositories ergibt. Ideal, wenn auch nicht immer so sauber durchzuhalten, ist es, wenn sich Commits auf vollständige - zumindest theoretisch funktionsfähige, lokal getestete ... - in sich logisch geschlossen Veränderungen beziehen. Also etwas, das man mit einer Commit-Message beschreiben kann, was sich auf einen Fehler oder eine separat implementierbare Funktion etc. beschränkt. Commits, die unfertige Zwischenzustände darstellen, sollte man zu vermeiden versuchen.
naja wenn die leute kein VCS benutzen: mach einfach code kaputt und dann such nach dem schuldigen.
Wolfgang S. schrieb: > Commits, die unfertige Zwischenzustände darstellen, sollte > man zu vermeiden versuchen. Das würde ich so nicht unterschreiben: es könnte falsch verstanden werden. Grundsätzlich hast du recht, ein Commit sollte eine Erweiterung, eine Fehlerkorrektur, ein abgearbeitetes "Ticket" darstellen. ABER: sobald die Arbeit daran die "Tagesgrenze" überschreitet, würde ich committen (mit entsprechendem Log-Eintrag, "Ticket 4711: Enhancement of xy (in progress)") Ein weiterer Fall, der mich leider recht häufig trifft: Man arbeitet seit 4 Stunden an einem Prio-3-Ticket, dann kommt eins mit Prio 1 rein, dummerweise sind dieselben Dateien betroffen. Dann mach ich einen "progress" commit, arbeite mein Prio-1-Ticket ab, committe dieses (und hab damit ein sauberes Changeset, welches sich auch portieren lässt) und arbeite dann am anderen Ticket weiter. Das ist auch der Grund, warum ich mit der heutigen Bedeutung von "Changeset" nicht ganz glücklich bin: Heute meint man "ein Commit" wenn man Changeset sagt. Für mich kann ein Changeset auch mehrere Commits umfassen, diese mehreren Commits werden dann beim Portieren zwischen branches (development, 1st/2nd level test, production) gemeinsam behandelt. Üblicherweise nimmt dann die Anzahl der Commits pro Changeset auch ab, je näher zum Produktivsystem man sich befindet.
Claqueur schrieb: > Es deckt halt auf was bei "update" fehlt, nicht geht, aber nicht > auffällt weil es lokal verhanden oder modifiziert ist. -Nicht > einegecheckte dateien, - Wobei die dann ja vorher geloescht werden (vermutlich meinyest Du backupen vor loeschen?)
@fisa: ein branc pro ticket und dann Squashen. Dann kannst du schön Work in progress commits machen und die am ende als einen vollständigen commit in den master mergen (oder wohin auch immer). Das hält das Commitlog ordentlich und sorgt dafür, das der haupt branch immer funktionsfähig ist!
Simon S. schrieb: > @fisa: ein branc pro ticket und dann Squashen. Dann kannst du schön Work > in progress commits machen und die am ende als einen vollständigen > commit in den master mergen (oder wohin auch immer). Das hält das > Commitlog ordentlich und sorgt dafür, das der haupt branch immer > funktionsfähig ist! "squash" scheint ein git-Begriff zu sein, damit kann ich grad nichts anfangen (wir setzen Subversion ein) ein branch pro Ticket ist unrealistisch, dafür gibts a) zu viele Tickets b) zu viele long-term Tickets mit Laufzeiten von mehreren Monaten c) zu viele beteiligte Systeme/Umgebungen d) zu viele Abhängigkeiten zwischen den Tickets. Wir machen keine (bzw. wenig) "klassische" SW-Entwicklung, sondern primär Customizing / Erweiterung einer Standardlösung. "Source-Code" sind bei uns Skripte, C#, SQL-Procedures/Scripts/Trigger, Konfig-Files, JSON, XML, ... Definiere "master" oder "haupt-branch". Wie ich schon angedeutet habe: Es gibt ein oder mehrere Entwicklungssysteme, ein bis zwei Testsysteme (zumindest eins beim Kunden) und (in der Regel) ein Produktivsystem. Welches ist deiner Meinung nach der "Haupt-Branch" und der "Master"? Grundsätzlich haben wir die Prozesse gut im Griff, aber das bessere ist der Feind des Guten :-)
Michael R. schrieb: > Wolfgang S. schrieb: >> Commits, die unfertige Zwischenzustände darstellen, sollte >> man zu vermeiden versuchen. > > Das würde ich so nicht unterschreiben: es könnte falsch verstanden > werden. > > Grundsätzlich hast du recht, ein Commit sollte eine Erweiterung, eine > Fehlerkorrektur, ein abgearbeitetes "Ticket" darstellen. > > ABER: sobald die Arbeit daran die "Tagesgrenze" überschreitet, würde ich > committen (mit entsprechendem Log-Eintrag, "Ticket 4711: Enhancement of > xy (in progress)") Danke für die Ergänzung. Tatsächlich arbeite ich auch so, wenn es sich nicht vermeiden läßt. Selbst dann versuche ich aber, so etwas wie einen verständlichen Zwischenzustand zu erreichen, und sei es, indem ich für den Commit dann einzelne Änderungen nicht in den Commit übernehme. Etwas verallgemeinert, ein (D)VCS hilft enorm, die vielen Fäden, die man in der Hand hat, besser zu überblicken. Es hilft aber auch, sein Vorgehen, konkret die Aufteilung der bearbeiteten Software in was immer die verwendeten Sprachen als Sprachmittel für die Aufteilung in Dateien und in Zeilen zuläßt, so zu strukturieren, daß diese mit dem VCS und nicht gegen es arbeitet. Disclaimer: niemand behauptet, daß das trivial sei. > > Ein weiterer Fall, der mich leider recht häufig trifft: Man arbeitet > seit 4 Stunden an einem Prio-3-Ticket, dann kommt eins mit Prio 1 rein, > dummerweise sind dieselben Dateien betroffen. Dann mach ich einen > "progress" commit, arbeite mein Prio-1-Ticket ab, committe dieses (und > hab damit ein sauberes Changeset, welches sich auch portieren lässt) und > arbeite dann am anderen Ticket weiter. Da sich beide Tickets ja auf einen bereits vorhandenen und publizierten Changeset beziehen dürften, wäre es ggfs. einfacher, in einem weiteren Clone des Repository diesen Stand auszuchecken, den Fehler dort zu korrigieren, das dann - je nach Projektorganisation - zu testen/publizieren/weiterzugeben und nachher seine Arbeit an dem Prio-3-Ticket im alten Clone wieder aufzunehmen. Wie man nachher den notwendigen Merge macht, hängt von unbekannten Details ab. M.a.W. Du wirst, wenn mehrere Leute am gleichen Code arbeiten, nach Abarbeiten des einen Tickets eh' erst den Stand des oder der anderen Repositories (i.d.R. wohl ein zentrales) importieren und mergen müssen, bevor Du Dir das nächste vornimmst. Genau so kannst Du auch vorgehen, wenn ein vordringliches Ticket Deine Arbeit unterbricht. > > Das ist auch der Grund, warum ich mit der heutigen Bedeutung von > "Changeset" nicht ganz glücklich bin: Heute meint man "ein Commit" wenn > man Changeset sagt. Für mich kann ein Changeset auch mehrere Commits > umfassen, diese mehreren Commits werden dann beim Portieren zwischen > branches (development, 1st/2nd level test, production) gemeinsam > behandelt. Üblicherweise nimmt dann die Anzahl der Commits pro Changeset > auch ab, je näher zum Produktivsystem man sich befindet. Es gibt - in Mercurial, vermutlich aber auch in Git - eine ganze Reihe von Erweiterungen, es gibt Plattformen wie GitHub, die m.E. ein Indiz dafür sind, daß die z.Zt. populären DVCS noch reichlich Luft nach oben haben. Andererseits kommen wir dann bald in den Bereich, der im Jargon "Change Management" genannt wird, und irgendwann dann auch "Configuration Management". Mir sind ehrlich gesagt die Tools lieber, die nur eine Problemstellung behandeln, die aber richtig und so, daß sie leicht für lokale Workflows einerseits gut erweiterbar und andererseits einbaubar sind. Wirklich gute Versionskontrollsysteme müssten auch die Syntax und Semantik der Sprachen verstehen, in denen die verwalteten Items formuliert sind, incl. der verwendeten Typen, der irgendwie in den Metadaten abgelegten Datenflüsse. Und das sprachübergreifend. Ich glaube nicht, daß wir in den nächsten zehn Jahren dergl. haben werden, insofern bin ich ganz glücklich, daß sich immerhin ein paar VCS durchgesetzt haben, die das ganze wenigstens agnostisch auf der Ebene von Zeilen, Dateien und Mengen von Dateien ganz gut hinbekommen.
Wolfgang S. schrieb: > Danke für die Ergänzung. Tatsächlich arbeite ich auch so, wenn es sich > nicht vermeiden läßt. Selbst dann versuche ich aber, so etwas wie einen > verständlichen Zwischenzustand zu erreichen Bis hierher sind wir uns einig... Wolfgang S. schrieb: > indem ich für > den Commit dann einzelne Änderungen nicht in den Commit übernehme. Darauf steht bei uns "hanged, drawn and quartered" ;-) Hauptsächlich deswegen, weil man (leider) mal für länger raugerissen sein kann, und ein Kollege übernimmt. Wolfgang S. schrieb: > Andererseits kommen wir dann bald in den Bereich, der im Jargon > "Change Management" genannt wird, und irgendwann dann auch > "Configuration Management" Da hab ich gewisse Vorteile: genau diese CM-Prozesse entwickeln und implementieren wir mit und für unsere Kunden. Da gibts ganz ganz spannende Synergie-Effekte: Warum macht der Kunde das so und so, warum der nächste anders, was kann ich für uns (und den dritten Kunden) daraus lernen? Es ist unheimlich spannend wie sich verschiedene Branchen (zB Railway und Luftfahrt) hier auf den ersten Blick grundlegend unterscheiden, auf den zweiten Blick dann aber doch wieder eine ähnliche Denke haben. Aus meiner Sicht bieten genau diese Erfahrungen des "CMII" unheimlich viel Potential für die SW-Branche. Das ist aber eine Prozess-Frage, und keine Tool-Frage. Nichtsdestotrotz: ohne ein SCM-Tool geht erstmal gar nichts.
Bernd K. schrieb: > Überzeugungsarbeit leisten? Auslachen, umdrehen und weggehen? Ignorieren > und Thema wechseln? Ich bin echt am Ende mit meinem Latein, über den > Chef kann ich nicht gehen (will ich auch nicht) denn der ist der selben > Meinung ("lohnt" sich nicht [für ihn]) und fällt mir damit quasi auch > noch öffentlich in den Rücken statt mit gutem Beispiel voranzugehen. So, der Rest der Welt will nicht so, wie du es willst? Könntest du eventuell den Gedanken ins Auge fassen, daß dein Chef möglicherweise einen weiteren Horizont hat als du und daß er genau deswegen dir sagt, daß es sich nicht lohnt? Ich kann solche Meinungen wie "ein Versionskontrollsystem ist IMMER!! gut und wer das nicht sofort einsieht, ist ein Idiot!" nicht leiden, weil es einen Mangel an Intellekt desjenigen erkennen läßt, der sowas sagt. Du schriebest: "wenn jemand im beruflichen Umfeld der auch mit Programmieren befasst ist vehement den Standpunkt vertritt es sei zu umständlich die Bedienung eines VCS zu erlernen..." Daraus schließe ich, daß derjenige nicht nur mit Programmieren, sondern vornehmlich mit ganz anderen Dingen in der Firma befaßt ist - und zwar mit Dingen, von denen DU zu wenig weißt und verstehst, um darüber so hochnäsig zu urteilen, wie du es in Eröffnungspost getan hast. Also: 1. Gehört das Programmieren nun zu den Kernpflichten des Kollegen? 2. Ist es im konkreten Falle wirklich nachrechenbar, daß ein VCS einen wirtschaftlichen Vorteil hat, oder ist es lediglich etwas künstlich Draufgesetztes, was außer deine persönlichen Ansichten zu befriedigen, nichts wirklich bringt? Was sagt der BWL'ler (und nicht der Programmierer) dazu? 3. Wärest DU nicht vielleicht derjenige, der sich um ein VCS zu kümmern hätte und nicht dein Kollege? 4. Warum gibt es bei euch in der Firma kein sauberes Agreement über die hoffentlich ebenso saubere Aufteilung der Arbeit? Das würde nämlich bedeuten, daß es verläßliche und gutdokumentierte Schnittstellen zwischen den Arbeiten der einzelnen Mitarbeiter gibt, anhand deren man sich sicher sein kann, daß das, was man an Funktionalität aus der Arbeit des Kollegen benutzt, eben sauber funktioniert und basta! Und wenn es irgendwo eine Erweiterung geben muß, dann wird diese zuerst durchdiskutiert und auf Probleme abgeklopft, dann so dokumentiert, daß man sich drauf verlassen kann und erst dann vom zuständigen Kollegen implementiert. Für sowas ist ein VCS herzlich überflüssig, stattdessen braucht es ein wohlgeführtes Projektmanagement und das ist was ganz Anderes. Ich habe eher den Eindruck, daß du dich hier ziemlich verrannt hast, bloß weil irgend etwas nicht ganz so läuft, wie deine eigene Nase zeigt. Versuche daher mal, dir die obigen Fragen in aller Ruhe selbst zu beantworten. Bedenke mal, daß du auch hier im Forum des Öfteren schon herumgemotzt hast, ohne dabei die Argumente anderer gebührend abzuwägen. W.S.
Ich bin mal ein wenig neugierig: Welche Versionsverwaltungssysteme werden denn bei euch im Unternehmen eingesetzt? Git und SVN wurden ja schon als Systeme genannt, aber vielleicht gibt es ja auch "exotische" Systeme? Was nutzt man denn beispielhaft im Automotive oder Medizin-Bereich? Git kann ich mir da ja schwer vorstellen... Nikolas
Nikolas schrieb: > Medizin-Bereich? Git > kann ich mir da ja schwer vorstellen... TFS (TFVC), wird aber vermutlich langfristig in TFS mit Git statt TFVC wandern, da letzteres einen langsamen Tod zugunsten von Git stirbt. Ältere Projekte liegen und bleiben in ClearCase.
... schrieb: > Das "beste" was ich bisher erlebt habe war eine "Projektverwaltung" mit > PCs. Das heißt, es wurde für jedes Projekt ein neuer PC eingerichtet und > die Daten blieben am Ende des Projekts auf dem PC und dieser wurde dann > ins Regal gestellt. Bis mal wieder an dem Projekt gearbeitet werden > musste. Dann wurde der Projekt PC aus dem Regal geholt. In der Zeit vor Programmen wie VMware o.ä. war das leider ein durchaus praktikabler Weg, weil man nur so für eine einigermaßen konsistente Buildumgebung sorgen konnte.
Nikolas schrieb: > Was nutzt man denn beispielhaft im Automotive oder Medizin-Bereich? Git > kann ich mir da ja schwer vorstellen... So mein Erfahrungsbereich: Rational Clearcase -> Avionic Perforce -> Automotive PTC (ehemals PTC) Integrity -> Automotive, Medizin svn, rcs, cvs kennt man von Firmen, die kein geld vür Versionsverwaltung locker machen.
Claqueur schrieb: > PTC (ehemals PTC) Integrity -> Automotive, Medizin soll heissen: PTC (ehemals MKS) Integrity -> Automotive, Medizin Da mal die wiki-links für diese: https://en.wikipedia.org/wiki/MKS_Integrity https://de.wikipedia.org/wiki/Rational_ClearCase https://de.wikipedia.org/wiki/Perforce
Claqueur schrieb: > PTC (ehemals MKS) Integrity -> Automotive, Medizin Wird bei mir im Unternehmen (Defence-Bereich) verwendet. Von den Kollegen und mir wird es gerne als MehrKostenSystem bezeichnet, weil einfache Arbeitsabläufe dort schwierig durchzuführen sind. Das liegt aber sicherlich nicht an dem Tool selbst, sondern daran, dass die betreuende Abteilung versucht (hat) im Tool ein Schema aus dem Vorgängersystem abzubilden, welches das Tool nicht wirklich hergibt. Etwas nervig ist, dass man Dateien wie in CVS auschecken muss, damit man sie bearbeiten kann oder man nimmt manuell das Schreibgeschützt-Attribut für die entsprechende Datei über den Windows-Explorer weg.
Roland F. schrieb: > Beeindruckend! > Bleibt dir dann eigentlich auch noch Zeit für deine "normale" Arbeit? Ja, natürlich. Zudem ist das ein Teil meines Arbeitsauftrages und somit Teil meiner normalen Arbeit. Zum Glück habe ich nämlich einen Chefchef, der sehr genau weiß, daß wir in manchen Bereichen etwas rückständig sind.
Rudolf schrieb: > Sheeva P. schrieb: >> Im Moment arbeite ich daran, meine Kollegen >> davon zu überzeugen, Linuxpakete und Docker-Images für unsere >> Softwaredistribution, Redis als hochverfügbaren und horizontal >> skalierbaren Key-Value-Store zu benutzen, und hernach wird es um >> Elasticsearch, Kibana sowie Apache Storm gehen. > > Was gibt Dir eigentlich die Sicherheit, daß -Du- mit Deinen Ansinnen auf > dem richtigen Weg bist? Die Tatsache, daß wir von unseren Kunden zwar immer wieder auf diese Themen angesprochen werden -- Paketierung, Docker, Hochverfügbarkeit, horizontale Skalierbarkeit -- aber bislang entweder nichts oder nur unprofessionelle Bastellösungen liefern können. Und natürlich mein Chefchef, der sehr genau weiß, daß wir in manchen Bereichen Aufholbedarf haben, und mich deswegen ausdrücklich damit beauftragt hat, etwas dagegen zu tun. Um der nächsten Rückfrage gleich vorzubeugen: natürlich könnte mein Chefchef einfach anordnen, daß dies oder jenes Werkzeug benutzt wird. Aber irgendwer müßte die in Frage kommenden Werkzeuge ja trotzdem evaluieren und dann das Passende empfehlen -- und zudem gehört es zu unserer Firmenkultur, mit Überzeugung statt mit Anordnungen zu arbeiten, zumal meine Kollegen ja alle keine Dummköpfe oder Faulpelze sind.
Nop schrieb: > Sheeva P. schrieb: >> Im Moment arbeite ich daran, meine Kollegen >> davon zu überzeugen, Linuxpakete und Docker-Images für unsere >> Softwaredistribution, Redis als hochverfügbaren und horizontal >> skalierbaren Key-Value-Store zu benutzen, und hernach wird es um >> Elasticsearch, Kibana sowie Apache Storm gehen. > > Bis man sich zu 90% mit den Tools beschäftigt und nicht mehr zum > Arbeiten kommt. Es kann auch einen Overkill an Tools geben. Für manche Entwickler mag es eine ganz neue Erkenntnis sein, aber letztlich kann man eine Software nur dann verkaufen, wenn sie die Bedürfnisse des Kunden befriedigt und dessen Probleme löst. Da wir das in einigen Bereichen derzeit noch nicht oder nur sehr rudimentär können, haben wir genau zwei Optionen: entweder, selbst etwas zu entwickeln (klassisches NIH), oder auf etablierte Industrielösungen zu setzen. Rate, was mehr Aufwand ist. ;-)
Michael R. schrieb: > Definiere "master" oder "haupt-branch". Wie ich schon angedeutet habe: > Es gibt ein oder mehrere Entwicklungssysteme, ein bis zwei Testsysteme > (zumindest eins beim Kunden) und (in der Regel) ein Produktivsystem. > Welches ist deiner Meinung nach der "Haupt-Branch" und der "Master"? > > Grundsätzlich haben wir die Prozesse gut im Griff, aber das bessere ist > der Feind des Guten :-) http://nvie.com/posts/a-successful-git-branching-model/ Sowas in der art passt denke ich. Master=Produktivsystem Release=Testsystem bei euch und beim kunden Develop=Testsystem bei euch Feature=Entwicklungssysteme
Claqueur schrieb: > svn, rcs, cvs kennt man von Firmen, die kein geld vür Versionsverwaltung > locker machen. Wenn SVN für den Aufgabenbereich paßt, gibt es auch keinen Grund, Geld auszugeben. Was da bei Git übrigens ein ziemlicher Blocker sein kann: man kann damit die History "bereinigen". Sheeva P. schrieb: > Da wir das > in einigen Bereichen derzeit noch nicht oder nur sehr rudimentär können, > haben wir genau zwei Optionen: entweder, selbst etwas zu entwickeln > (klassisches NIH), oder auf etablierte Industrielösungen zu setzen. > Rate, was mehr Aufwand ist. ;-) Klar, wenn die Tools Features abbilden, die der Kunde anfordert und bezahlt (bzw. ansonsten abspränge), ist das was ne andere Hausnummer. Und klar ist das NIH-Syndrom dann ein Problem - man kriegt nach Abzug der natürlichen Fluktuation für hausinterne Tools immer so schwer Leute am Markt. ;-)
Simon S. schrieb: > Master=Produktivsystem > Release=Testsystem bei euch und beim kunden > Develop=Testsystem bei euch > Feature=Entwicklungssysteme Danke! Im Wesentlichen arbeiten wir eh genau so, nur die benamselung ist anders...
Nop schrieb: > Klar, wenn die Tools Features abbilden, die der Kunde anfordert und > bezahlt (bzw. ansonsten abspränge), ist das was ne andere Hausnummer. Da mache ich ja nicht aus Spaß an der Freude, sondern um reale Probleme zu lösen. Daß mir das trotzdem Spaß macht, ist dabei kein Widerspruch. ;-) > Und klar ist das NIH-Syndrom dann ein Problem - man kriegt nach Abzug > der natürlichen Fluktuation für hausinterne Tools immer so schwer Leute > am Markt. ;-) Für interne Werkzeuge bekommt man auch keinen kommerziellen Support, sondern man muß ihn selbst leisten.
Nop schrieb: > Claqueur schrieb: >> 1) Nur Sourcen und buildscripte einchecken, keine Compilate/Compiler. > > Man kann auch die Compilate mit einchecken, das ist Geschmackssache. Das > macht man aber nur bei Lieferständen, die an irgendwen gehen, und sei es > ans Testfeld. Ja, kann man, aber dann nutzt man eine Sourceverwaltung nicht als Sourceverwaltung sondern als BackUp oder Konfigurationsmanagmentsystem. Ich weiss das hört sich nach Krümelkackerei an. Aber Aufgabe von Sourcemanagment ist es nun mal, immer die Quelltexte bereitzuhalten um aus denen jederzeit aufs letzte bit genau den selben Stand/Compilat erzeugen zu können. Und um das 100% zu garantieren ist es eigentlich nötig das Compilat nicht aus der Arbeitsversionen also die von denen man meint commited zu haben oder nach dem Comilieren commiten zu werden. Sondern aus den wieder ausgecheckten Sourcen in einem anderen Verzeichniss. Sonst kann sowas passieren: > Ich hab's schon erlebt, daß so ein Vorhaben gescheitert ist, weil jemand > die Projekt-Settings der IDE vergessen hat mit einzuchecken. Dummerweise > hat die verwendete IDE aus diesen Settings den Startupcode automatisch > generiert. Es ist halt ne Art "Selbsterziehung", Checke ich die Sorucen nicht in die "Sourceverwaltung" ein, zwinge ich mich selbst dazu wirklich sicherzustellen das aus den aus der Sourceverwaltung zurückgeholten Sourcen jederzeit das Compilat erzeugbar ist. Andernfalls kann irgendwann der Bezug zwischen Sourcen und Compilat unbemerkt verloren gehen. Zum Zeitpunkt der Ausöieferung braucht man den bezug nicht, aber spätestens bein ersten Bugreport wird harig wenn man nicht die zum report passenden (Bug-) Quellen aus dem Archiv ziehen kann.
Claqueur schrieb: > Checke ich die Sorucen nicht in > die "Sourceverwaltung" ein, zwinge ich mich selbst dazu wirklich > sicherzustellen das aus den aus der Sourceverwaltung zurückgeholten > Sourcen jederzeit das Compilat erzeugbar ist. Andernfalls kann > irgendwann der Bezug zwischen Sourcen und Compilat unbemerkt verloren > gehen. Grmm, der Typo machts voll daneben! :-( Schreiben wollt ich: Checked man die Compilate bewusst nicht in die "Sourceverwaltung" ein, zwingt man sich, selbst Sicherzustellen das mit den aus der Sourceverwaltung zurückgeholten Sourcen jederzeit ein identisches Compilat erzeugbar ist. Andernfalls kann irgendwann der Bezug zwischen Sourcen und Compilat unbemerkt verloren gehen.
Nikolas schrieb: > Was nutzt man denn beispielhaft im Automotive oder Medizin-Bereich? Git > kann ich mir da ja schwer vorstellen... Aus der Luftfahrt ist mir noch Teamcenter Enterprise bekannt. Allerdings ist dieses Programm von der Benutzeroberfläche her in der Tat abartig. Das macht bei der Arbeit wenig Freude.
Nop schrieb: >> 2) Nur compilierfähige Sourcen/Scripte einchecken > > Unbedingt. Ich krieg nen Hals, wenn ich "update" mache und dann nichtmal > ein Build geht, weil der Kollege das nicht getestet hat. Das sollte auf jeden Fall für den Master Branch gelten, aber nicht für alle Entwicklungszweige. Wenn ich neue Features baue, dann werden auch (noch) defekte Softwarestände eingecheckt. Manches lässt sich eben gerade nicht in ein paar Stunden mit einem Commit lösen. Dann sollte die Commit-Message aber eine Notiz wie "WIP" o.Ä. enthalten. Claqueur schrieb: > Checked man die Compilate bewusst nicht in > die "Sourceverwaltung" ein, zwingt man sich, selbst Sicherzustellen das > mit den aus der Sourceverwaltung zurückgeholten Sourcen jederzeit ein > identisches Compilat erzeugbar ist. Andernfalls kann irgendwann der > Bezug zwischen Sourcen und Compilat unbemerkt verloren gehen. Aus Platzgründen mache ich so etwas nur bei EINZELNEN Softwareständen. Wenn sie zum Beispiel an den Kunden rausgehen. Wenn man es ganz genau macht, müsste man ALLES mit einchecken, inkl. Compiler. Und ja, ich war schon in Firmen da gab es einen Rechner, für ein Projekt, mit GENAU DIESEM Softwarestand von vor X Jahren. Alles noch mit altem Windows XP und dem Stand von damals, gab wohl auch ne Ausnahmegenehmigung von der IT. Simon S. schrieb: > http://nvie.com/posts/a-successful-git-branching-model/ > > Sowas in der art passt denke ich. Halte ich auch für sinnvoll, hier und da muss man es eben an die eigene Arbeitsweise anpassen. Besonders bei Einsteigern ohne Berufs/Entwicklungserfahrung siehts aber leider anders aus. Da wird alles erstmal pauschal auf Master gepusht. Beim nächsten Pull kracht es dann weil jeder am gleichen Stand arbeiten will (rebase kennen sie dann auch nicht ;-) )
Wühlhase schrieb: > Aus der Luftfahrt ist mir noch Teamcenter Enterprise bekannt. Du meinst das PLM-Dingens von Siemens?
Christopher J. schrieb: > Wühlhase schrieb: >> Aus der Luftfahrt ist mir noch Teamcenter Enterprise bekannt. > > Du meinst das PLM-Dingens von Siemens? TC Enterprise war ja wohl mal das Metaphase von SDRC, während TC Engineering aus Unigraphics IMAN hervorging. Nachdem fast alle Beteiligten sich gegenseit gekauft haben, um dann von Siemens übernommen zu werden, läuft das jetzt wohl alles gemeinsam unter dem Branding "TeamCenter"
Bei uns wird momentan PDM von solutionsworks zur Dokumenten-, sowie CADverwaltung eingesetzt. Ein elend langsames Tool. Der Vorteil davon ist, dass dieses auch von DAUs benutzt werden kann,weil es sich im Windows Explorer integriert...
Christopher J. schrieb: > Wühlhase schrieb: >> Aus der Luftfahrt ist mir noch Teamcenter Enterprise bekannt. > > Du meinst das PLM-Dingens von Siemens? Keine Ahnung ob es das von Siemens ist, ich hab grad keine Screenshots dazu gefunden. Ich weiß aber noch daß es in Java programmiert ist.
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.