Guten Abend !
Mal ne kleine Frage an die erfahrenden Entwickler hier im Forum, wie
macht ihr das so mit dem Versionsmanagement, sei es bei privaten (wohl
eher unwahrscheinlich) und bei den beruflichen Projekten?
Ich arbeite gerade an einem größeren Projekt und wollte später wenn
alles einmal läuft den Quellcode gerne in ein Versionsmanagement
einpflegen um spätere Änderungen zu verfolgen ect.
Kann mir einer mal nen paar tipps geben? Gibt es da auch freeware und
open-source Lösungen?
Vielen Dank für die Hilfe und viel Spass beim Fussball
Du kannst CVS beispielsweise auch ohne Linuxserver verwenden. Das
Repository liegt dann z.B. auf lokaler Platte oder auf einem
Netzlaufwerk.
Und ich würde damit auch nicht erst anfangen, wenn das Projekt läuft,
sondern sofort!
----, (QuadDash).
ja aber winvcd läuft nicht korrekt, habemir die vcs.exe dazu
runtergeladen und die entsprechend angegeben wo die steht. Aber der
Aufruf aus dem Programm (winvcs) läuft nicht. Er sagt immer falsche
Aufruf "--c"-option unbekannt. Wenn ichs in der kommandozeile mache
klappt es...
wind winvcs etwa süberladen mit den 10mio. optionen....
Nun ja, "funktionieren" tut beides. Es funktioniert auch RCS und
SCCS...
Man muß halt für sich selbst entscheiden was einem besser liegt. Ein
bisschen Einarbeitungszeit ist da schon investieren.
Und Daniel, wenn Du mal mit einer "professionellem"
Versionsverwaltung z.B. Clearcase gearbeitet hast, dann wirst Du cvs
sicherlich nicht überladen finden :-)
Noch ein link für die ganz eiligen:
http://kj.uue.org/papers/cvs-handout/
Gruß,
rweber
Roland schrieb:> Kann jemand für mich eine praktische, deutschsprachige Beschreibung über> ClearCase und ClearQuest geben?
Du möchtest, dass dir jemand mal eben schnell ein paar tausend Seiten
CCase und CQuest Dokumentation auf drei Seiten zusammenfasst? Viel
Glück.
Als Mausschubser kann ich Die tortoise-svn empfehlen. Der inegiert sich
in den Windows-Explorer und die cmd-line tools werden von vielen IDEs
unterstützt, u.a. von eclipse (subclipse) Es ist sogar eine server auf
windows Basis verfügbar ...
J. Bernau
Roland schrieb:> Kann jemand für mich eine praktische, deutschsprachige Beschreibung über> ClearCase und ClearQuest geben?
Bist Du sicher, anschließend einige zig- bis hunderttausend Euro für die
Programme ausgeben zu wollen und zu können?
Daniel schrieb:> Ich arbeite gerade an einem größeren Projekt und wollte später wenn> alles einmal läuft den Quellcode gerne in ein Versionsmanagement> einpflegen um spätere Änderungen zu verfolgen ect.
Hier liegst du einem Irrtum auf. Fange sofort damit an.
:)
Ich bin ganz sicher, dass ich für eine praktische Dokumentation brauche
:)
Es geht um meine Einarbeitung und im Rahmen dieser soll ich einen
Vortrag über ClearCase und ClearQuest halten.
Deswegen habe ich nachgefragt, vielleicht hat jemand eine Dokumentation,
worin z.B.: durch ein Beispiel wird die Funktionalität vorgestellt.
Hier bei der Firma haben wir keine ClearCase und ClearQuest, so kann ich
nicht ausprobieren...
Gruß
Inzwischen würde ich auch eher zu git tendieren als svn.
Ohne aufs Datum zu schauen waren mir die ersten Vorschläge doch suspekt,
als jemand ernsthaft CVS vorschlug, aber als mir das Datum ins Auge
stach, wusste ich warum.
Es hat sich in den letzen Jahren sehr viel getan in Sachen
Versionskontrolle. Die ganzen verteilten Systeme sind groß und brauchbar
geworden.
Falls jemand Interesse an Versionskontrollsystemen hat, kann ich dieses
frei verfügbare Online Buch http://www.ericsink.com/vcbe/index.html
empfehlen.
Subversion kann man wahlweise mit einem Server machen (also ein Daemon
unter Linux oder Dienst unter Windows) oder auch einfach nur mit lokalen
Dateien.
Mit dem Tool svnadmin kannst Du ein lokales Subversion repository
erzeugen, das ist einfach ein Verzeichnis mit einem haufen
Geheimnisvoller Dateien.
Wenn Du später das Repository mit mehreren Personen nutzen willst,
kannst Du deine Computer durch Installation des Daemon/Dienst zum Server
machen und einfach das vorher erzeugte Repository weiter nutzen.
Stefan schrieb:> Subversion kann man wahlweise mit einem Server machen (also ein Daemon> unter Linux oder Dienst unter Windows) oder auch einfach nur mit lokalen> Dateien.
Das ändert aber nichts daran, dass es immer ein "zentrales" Repository
gibt. Gut, wenn man alleine arbeitet, dann wird der Unterschied zwischen
zentral und dezentral vielleicht nicht ganz so deutlich.
Stefan schrieb:> Mit dem Tool svnadmin kannst Du ein lokales Subversion repository> erzeugen, das ist einfach ein Verzeichnis mit einem haufen> Geheimnisvoller Dateien.
Damit fängt es schon an unheimlich zu werden. Subversion packt (genauso
wie CVS) in jedes Verzeichnis einen "versteckten" Ordner ".svn" (bzw.
".cvs"). Bei Git hingegen gibt es nur auf der Wurzelebene einen solchen
Ordner.
Stefan schrieb:> Wenn Du später das Repository mit mehreren Personen nutzen willst,> kannst Du deine Computer durch Installation des Daemon/Dienst zum Server> machen und einfach das vorher erzeugte Repository weiter nutzen.
Bei Git braucht man noch nicht mal notwendigerweise einen "zentralen"
(bare) Server (auch wenn das bei größeren Projekten durchaus Sinnvoll
ist).
Ich will hier jetzt keine Hetzkampagne gegen SVN/CVS führen, aber jeder
der schon einmal mit beiden Systemen gearbeitet hat, wird wohl
bestätigen können, dass Git (bzw. dezentrales Versionsmanagement) viele
Vorteile bietet, unter anderem ist es eben trivial Branches zu erstellen
und diese ggf. wieder mit der "Mainline" zu mergen. SVN/CVS sind dafür
i.A. nicht zu gebrauchen.
> Ich will hier jetzt keine Hetzkampagne gegen SVN/CVS führen
Keine Angst, jeder, der schon mal mit anderen Systemen gearbeitet hat,
wird Dir zustimmen.
Als heißen Konkurrenten zu Git möchte ich noch Bazaar erwähnen. Ähnliche
Features, vielleicht nicht ganz so umfangreich und schnell, aber dafür
wirklich einfach in der Anwendung.
Ich benutze VisualSVN Server und TortoiseSVN
Funktioniert gut und erleichtert das Leben.
Auch wenn man nur alleine arbeitet möchte ich es nicht mehr missen(hab
ziemlich lange gebraucht bis ich mich mal rangetraut habe)
Was ist am mergen bei SVN so schlimm? Bzw. was ist da der Unterschied zu
GIT?
Ich hatte bisher keine Probleme Tags&Branches zu erstellen
Michael H. schrieb:> GlierKäis schrieb:>> Hier liegst du einem Irrtum auf. Fange sofort damit an.>> In den vergangenen SECHS JAHREN dürfte er das hinbekommen haben.
Hahaha! Michael H. du hast recht, der Thread ist von 2006. Da hat der
freche Roland einfach mal den Thread gekapert, statt sich an die
Forenregeln zu halten. Gab es nicht vor kurzem eine Diskussion zu dem
Thema, nun bin ich selbst auch darauf hereingefallen und habe auf den
ersten Post des Threads geantwortet ohne auf das Datum zu achten,
autsch.
sehr guter link!!!
was der da beschreibt kann ich nur bestätigen. gerade mit dem einchekken
wenn man nix verbocken will und die version noch net ganz rund läuft
Stefan B. schrieb:> Falls jemand Interesse an Versionskontrollsystemen hat, kann ich dieses> frei verfügbare Online Buch http://www.ericsink.com/vcbe/index.html> empfehlen.
Ich habe mal die ersten paar Seiten gelesen und das vorher erwartete
bestätigte sich:
Ich sehe keine Lösung für den typischen kleinkriminellen
Hobbyprogrammierer, also Leute die:
1. nicht wissen, ob die erarbeitete (Teil-)Lösung sich bewähren wird
2. wenige KB Code schreiben
3. abundzu dran weiterarbeiten (und daher viel zwischenzeitlich
vergessen)
4. mehrere Handlungsstränge aus der Not heraus gebähren.
Wie manage ich damit ein Projekt, das in drei verschiedene Codes
zerfallen ist, weil die populistisch 'besser' sind, die dann aber nach
jeweils mehreren Subversionen wieder zusammengeführt werden sollen?
Bislang mache ich das mit primitiven ASCII-Dateien, in denen die
Änderungen reingeschrieben wurden inkl. Datum. Darafhin habe ich dann
mehrere mehroderweniger komplette Projekte auf dem PC. Von ZeitzuZeit
sortiere ich dann aus, führe zusammen durch Code kopieren, usw.
Nicht professionell, aber vermutlich arbeiten die allermeisten im
hardwareorientierten Bereich so. Daß man mit dieser Methodik ein Win12
nicht generieren kann, ist klar.
Die Sache wird dadurch etwas einfacher, daß es immer nur einen
Programmierer gibt.
Im Studium wurde topdown-Entwicklung propagiert. Das war mir schon
damals klar, daß das Blödsinn ist, denn in den allermeisten Projekten
ist überhaupt nicht klar, ob man die entstehenden Teilschritte überhaupt
sinnvoll aufgeteilt hat. Daher arbeiten sicherlich die meisten Leute in
diesem Bereich nach von unten = Teillösungen, die dann auch testbar
sind! nach_ _oben hin zum optionalen GUI. Für topdown müßte man extra
Testcases realisieren, die logischerweise rein virtuell sind und damit
enorm fehlerträchtig (abgesehen vom zeitlichen Aufwand Code fürs
Nirwarna zu kreieren). FORTH basiert ja als ganze Programmiersprache auf
diesem Ansatz.
Was sind eure Meinungen?
all das kannste damit ja genau so weitermachen wenn du unbedingt willst.
dann wird halt immer ein neuer branch erzeugt.
> 3.abundzu dran weiterarbeiten (und daher viel zwischenzeitlich> vergessen)
da man sich den log der bisherigen änderungen anschauen kann, ist das
für vergessliche ideal.
die manuelle Arbeit des mergens wird nunmal immer bleiben...egal wie man
sein Projekt nun pflegt...mit einer Versionierung oder indem man Ordner
samt Files hin&her kopiert
Neuer Versionierungssysteme als SVN sollen das ja besser können, wobei
ich es noch nicht ausprobiert habe. Ich kann mir auch noch nicht
vorstellen, wie man sowas gross automatisieren soll. Wenn ich zwei
unterschiedliche Funktionen mit gleichem Namen habe, muss doch ein
Mensch draufschauen und sagen was übernommen werden soll?!
Michael H. schrieb:> GlierKäis schrieb:>> Hier liegst du einem Irrtum auf. Fange sofort damit an.>> In den vergangenen SECHS JAHREN dürfte er das hinbekommen haben.
Na sowas, wie die Zeit vergeht, wenn man sich amüsiert.
Zum Glück hat der H's Michl auf die Uhr geschaut. Ja, er lebt noch ...
Karol Babioch schrieb:> Damit fängt es schon an unheimlich zu werden. Subversion packt (genauso> wie CVS) in jedes Verzeichnis einen "versteckten" Ordner ".svn" (bzw.> ".cvs").
Das ist bei der aktuellen SVN-Version (1.7.x) geändert, die "versteckten
Daten" liegen jetzt auch im Wurzelverzeichnis!
Ich bin gespannt, ob sich in den letzten 15 Jahren eine verbesserte
Methodik breit machte. Ich kann mich erinnern, damals auf einmal eine
Validierung von größeren C-Projekten durchführen zu müssen (50KByte
Binärcode), weil die Auftraggeber das für irgendwelche Zulassungen
benötigten. Es war nicht mein Task die Software zu schreiben und zu
validieren :-)
Ich möchte natürlich nicht nur C-Fragmente, sondern z.B. auch
Schaltungen in LTspice so behandeln. Geht das auch? Wenn eine neue
Methodik, dann soll sie möglichst universell sein, wie z.B. das Datei-
und Ordner-System im Filesystem. Was man für alles mögliche benutzen
kann.
Vielleicht mache ich ja was grundlegend umständlich und bin nie auf eine
solidere Idee gestoßen?
Ich denke das obige Argument "da muß ja ein Mensch nochmals drüber
schauen und entscheiden, WAS nun übernommen wird und was nicht" bleibt?
Z.B. zwei Funktionen, die unterschiedliche Dinge tun, aber auf ein
zufällig gemeinsames Special Function-Register in einem Controller
zugreifen, um ihre Funktion zu realisieren.
Es ist wie immer. Es kommt darauf an was man von dem System erwartet.
Bei uns arbeiten ca. 10 Leute seit ca. 10-12 Jahren mit cvs. Dabei geht
es nur darum Änderungen an den gleichen Dateien von mehreren Leuten
automatisch abgeglichen zu kriegen. Das ganze andere Geraffel wie
verschiedene Entwicklungszweige u.s.w haben wir nie benutzt und werden
es auch nicht. Wenn ein Release freigegeben wird bleibt es auf dem Stand
stehen, wird kopiert für das nächste Release und neu eingecheckt. Mag
sein das die neueren Systeme viel mehr können, das muss dann aber auch
von allen sicher beherrscht werden. Das kostet auch Zeit und Geld.
Deshalb ist für mich manchmal weniger mehr. Auch wenn man privat auf
verschiedenen Rechnern was macht ist cvs für mich völlig ausreichend.
Roland schrieb:> Kann jemand für mich eine praktische, deutschsprachige Beschreibung über> ClearCase und ClearQuest geben?
Vielleicht, vielleicht auch nicht. Hat in jedem Falle nichts
(aber auch gar nichts) mit dem Ursprungsthread zu tun, der seit
6 Jahren in der Kiste lag.