Druckbare Version
Moin *,
nun habe ich gerade ein Programm völlig vergurkt und müsste mal ein wenig zurückschrauben. Deshalb würde ich in Zukunft gerne mal eine Versionskontrolle einsetzen, also subversion oder git. Deshalb ein paar Fragen:
1. Benutzt Ihr sowas überhaupt?
2. gibt es Plugins für win-avr?
3. oder für avr-Studio?
viele Grüße
Andreas
OK: 3. gibt es offenbar - habe ich gerade in der Hilfe gefunden. (Aber leider nicht einen Link zum Plugin).
viele Grüße
Andreas
ich benutze gerne git, da man da nicht unbedingt ein zentrales repo braucht.
Für Windows empfehlen sich SVN oder GIT in der Form TortoiseSVN oder TortoiseGIT. Unter Linux würde ich vermutlich gleich GIT wählen.
Für neue Projekte nutze ich eigentlich nur noch GIT.
mfG
Markus
Moin *,
im Moment tendiere ich auch ein wenig zu git, aber wie ist das mit der IDE-Einbindung?
viele Grüße
Andreas
Kommt immer auf die IDE an. Ich bediene git aber oft lieber über die Shell
Aahh - ein Geistesverwandter ;)Zitat:
Zitat von TheDarkRose
Ich programmier mit WinAVR in Eclipse, und für Eclipse gibt es Tonnen von Plugins für Versiosnverwaltung! Zumal der Codeformatter und die Autovervollständigung ein Highlight der Eclipse IDE sind! und das Code-Highlighting erst ^^
Bei Eclipse hast du eh die beste Auswahl -> eGit, benötigt nicht mal eine installation von git am System.
WinAVR in Eclipse? Hast Du da mal einen Pointer auf 'ne Doku? Eclpise kenne ich bisher nur mit Java. Welche der vielen Eclipse-Packages benutzt Du? Wie bekomme ich IDE in eine andere IDE rein?Zitat:
Zitat von Ceos
(BTW: meine Lieblings-IDE: vim und make, hehehe).
viele Grüße
Andreas
Für Eclipse gibt es das EclipseAVR Projekt. Ich glaube eher, das er das meinte. WinAVR und co muss trotzdem teilweiße installiert werden, da man die Toolchain zum compilen und alles braucht, auf die das EclipseAVR Plugin zurückgreift.
OK - gefunden. Das werde ich mir mal anschauen.
viele Grüße und vielen Dank
Andreas
sorry ich hänge im moment ein wenig mit dem Antworten hinterher ,Arbeit stresst viel im Moment und privat geht auch viel Zeit drauf
einfach Eclipse installieren (am besten gleich die Variante für C++, welche man auf der Eclipse-Seite ein Stück weiter unten findet) dann WinAVR installieren, EclipseAVR isntallieren (nimmt einem die Einrichtung der Toolchain ab), losprogrammieren !
Nochmal Danke!! Und kein Problem mit dem hinterherhängen - ich liege gerade mit Erkältung zu Hause. Sobald die Watte aus dem Hirn verschwunden ist werde ich das mal angehen.
viele Grüße
Andreas
Sorry wenn ich deinen thread infiltriere, aber wo wir hier gerade bei Versionskontrolle sind hätte ich auch noch eine Frage...
Wir benutzen in der Firma momentan Visual Source Safe (schlimmer gehts kaum, ich weiss), es gibt aber erste Überlegungen ob wir eventuell auf was besseres umsteigen (vor allem weil die VSS Datenbank wohl in absehbarer Zeit eine kritische Größe erreicht).
Die offensichtlichste Lösung wäre natürlich der Team Foundation Server von Microsoft, aber es gäbe da ja auch noch Subversion, Mercurial und Git (um nur mal die wichtigsten zu nennen). Welches System für uns am besten geeignet wäre, interessiert mich dabei aber erstmal garnicht (muss man ausprobieren und dann entscheiden).
Mein Problem ist ein spezielles Feature von VSS welches wir exzessiv nutzen, das aber keiner der 4 Kandidaten zu haben scheint: shared files
Unsere VSS Datenbank ist vollgestopft mit vielen unterschiedlichen Projekten, wobei es allerdings viele Dateien gibt die in mehreren (einige sogar in allen) Projekten genutzt werden. Bei VSS kann man eine solche Datei einfach "sharen", sagen wir mal in den Projekten A, X und Y. Ändert man diese Datei dann in einem der Projekte, dann wirkt sich das auch auf die anderen Projekte aus.
Wie würde man das in TFS, SVN, Mercurial oder Git lösen?
Also ich selbst bevorzuge Git, weis es eben nicht nur eine simple Arbeitskopie erstellt, sondern das ganze Repository klont. Damit hat man immer die komplette Commithistory dabei, kann auch Commits machen wenn man offline ist, und da es bei Git ja sehr gut mit Branching zu arbeiten ist, benutze ich das auch viel. Und man kann dann auch mal schnell lokal einen Branch erstellen, um gewisse Dinge (auch über länger) auszuprobieren, ohne das man diesen Branch in ein zentrales Repo pushen müsste. Somit muss nicht jeder deine Gedankenspiele mitbekommen, wenn man das nicht will. Auf gut deutsch, Git kann sehr agil sein.
Zu deiner Sache mit den den shared projects. Bei SVN heißt das svn-externals und bei Git sub-modules. Ob man in einem so eingebunden Unterrepo(/-projekt) die Dateien direkt bearbeiten kann und ins richtige Projekt commiten, hängt von den richtigen Zugriffseinstellungen ab.
Kennst du zufällig Github? Falls ihr euch für Git entscheidet und eure Firma nicht auf professionellen Support verzichten möchte, könntet ihr euch Github:FI (Firewall Install) ansehen. Das ermöglicht dir eine fast Github ähnliche Umgebung und auch so einfache Administration der Repositorys und Commiter im eigenen Unternehmen und auch nach außen abgeschottet.
Also wenn ich das richtig verstehe müssten wir dann die geshareten Dateien erstmal zu neuen repositories zusammenfassen, und diese dann in den anderen einbinden, richtig? Und die Dateien würden dann in entsprechenden Unterverzeichnissen auftauchen? Das wäre einerseits schön, weil wir damit etwas mehr Ordnung in die Sache bringen würden, aber andererseits müsste man tonnenweise #includes anpassen, da sich der Pfad vieler Dateien dadurch ändern würde (d.h. nach der Migration der VSS Datenbank wäre nochmal viel Handarbeit notwendig um wieder auf einen vergleichbaren Stand zu kommen).Zitat:
Zu deiner Sache mit den den shared projects. Bei SVN heißt das svn-externals und bei Git sub-modules. Ob man in einem so eingebunden Unterrepo(/-projekt) die Dateien direkt bearbeiten kann und ins richtige Projekt commiten, hängt von den richtigen Zugriffseinstellungen ab.
Github kenne ich nur vom Namen her, aber professioneller Support ist für uns eigentlich auch nicht so wichtig (wir sind eine relativ kleine Firma, mit nur einer Handvoll Entwicklern).Zitat:
Kennst du zufällig Github? Falls ihr euch für Git entscheidet und eure Firma nicht auf professionellen Support verzichten möchte, könntet ihr euch Github:FI (Firewall Install) ansehen. Das ermöglicht dir eine fast Github ähnliche Umgebung und auch so einfache Administration der Repositorys und Commiter im eigenen Unternehmen und auch nach außen abgeschottet.
Moin Felix,
Das sollte eigentlich der richtige Weg sein. Jajaja - das ist erstmal mit Arbeit verbunden;); wie Du selbst sagst, bringt das mehr Ordnung ins System. Aber so'n Umstieg kann auch als Chance gesehen werden sich von Altlasten zu befreien.Zitat:
Zitat von Felix G
viele Grüße
Andreas
Also wenn du die sub-modules richtig einbindest, dann dürfte sich nichts am Pfad ändern und es fallen keine #include Änderungen an.