[C#] Einfaches CVS gesucht [Archiv]

Archiv verlassen und diese Seite im Standarddesign anzeigen : [C#] Einfaches CVS gesucht

()V()r.Freeze

2010-05-09, 22:41:54

Hallo zusammen,

ich suche eine einfache Möglichkeit, in einem 2er Team komfortabel ein Windows Forms Projekt zu versionieren und die jeweiligen Workspaces auf dem aktuellen Stand zu halten. Ein Compare Editor wie in Eclipse unter Verwendung von Subversion wäre nett, muss aber nicht sein.

Verwendet wird Visual Studio 2010, entwickelt wird in C#. Soweit ich weiß unterstützt Visual Studio .svn nicht (außerdem hab ich keine Ahnung vom Einrichten eines Subversion-Servers).

Daher die Frage: Gibt es eine (evtl. sogar in Visual Studio integrierte) Lösung, die Projekte bei beiden Entwicklern aktuell zu halten?

Gruß

PatkIllA

2010-05-09, 23:13:13

svn kannst du ja auch unabhängig von VisualStudio benutzen. Außerdem gibt es plugins.
Von MS gibt es den Team Foundation Server. Ob der einfacher einzurichten ist?

Gast

2010-05-10, 00:08:23

in Zeiten von git/hg/bzr würde ich mich nicht mit cvs oder svn quälen.

()V()r.Freeze

2010-05-10, 00:10:00

Danke für eure Antworten. Wir testen jetzt die Kombination freepository + AnkhSvn für Visual Studio.

Shink

2010-05-10, 05:58:54

Vielleicht etwas exotisch aber: Wenn du mit Eclipse schon Erfahrung hast könntest du ja Eclipse mit C#-Plugin als CVS/SVN-Client versuchen.

Monger

2010-05-10, 07:48:48

Wir benutzen TortoiseSVN und AnkhSVN als Clients, und bei uns arbeiten damit ca. 20 Leute.

Wir haben uns gerade vor ein paar Tagen auch mal den neuen Team Foundation Server 2010 angeschaut. Sehr mächtig, und auch sehr einfach aufzusetzen. Da braucht es länger, bis man sein Subversion Repository mit allem drum und dran konfiguriert hat. Vorallem hat mir gefallen, wie alles von der Projektplanung und Featuredefinition über die Entwicklung bis runter zum Testing Center, Bug Reporting und Build Prozess alles integriert ist.

Allerdings ist der Server auch nicht ganz billig, und für unsere Teamgröße wäre das purer Overkill. Subversion hat den Vorteil, dass es ziemlich simpel ist, und man auch selbst leicht Tools dafür entwickeln kann (mit SharpSVN, z.B.).

catamaran

2010-05-10, 08:54:55

TFS 2010 hat in unserer Firma das angestaubte SourceSafe mehr als nur ersetzt. Für ein 2-Mann-Projekt dürfte der TFS etwas übertrieben sein.

Unfug

2010-05-10, 08:55:04

http://www.visualsvn.com/

()V()r.Freeze

2010-05-10, 09:53:55

Vielen Dank für eure Antworten. Die Entscheidung ist mittlerweile gefallen, wir bleiben bei dem AnkhSVN. Bietet alle Funktionen die wir brauchen und die Einrichtung erfolgte für Neulinge relativ einfach.

Gandharva

2010-05-10, 12:12:08

Git, Bazaar oder Mercurial. Alles andere ist imo Steinzeit. Persönlich bevorzuge ich Git.

ESAD

2010-05-10, 12:56:37

es gibt für vs auch ein visualsvn plugin was commit, etc direkt im vs erlaubt. es kann allerdings bei großen projekten manchmal eine datei vergessen aber bei kleineren sachen sollte es problemlos funktionieren

Monger

2010-05-10, 13:45:14

Git, Bazaar oder Mercurial. Alles andere ist imo Steinzeit. Persönlich bevorzuge ich Git.
Ich finde diese Art der dezentralen Quellverwaltung jetzt nicht sooo entscheidend.

Die Stärke von Subversion ist halt, dass es mittlerweile schon lange etabliert ist, und es sehr ausgereifte und vielseitige Tools dafür gibt. TortoiseSVN ist wohl einer der verbreitesten und besten SVN Clients überhaupt. Es gibt so einige Web Plugins die man auf dem Server aufsetzen kann, sogar mit integrierter Meilensteinplanung und Bugtracking wie z.B. Trac.

Kommt halt immer drauf an, was man braucht. Für uns war es entscheidend, dass sich das in den Gesamtprozess gut eingliedert, weil wir halt noch etwas mehr als nur klassische Quellverwaltung brauchen. Deshalb ist uns z.B. auch AnkhSVN als Client schlicht zu wenig.

Coda

2010-05-10, 13:58:26

Ich finde diese Art der dezentralen Quellverwaltung jetzt nicht sooo entscheidend.
Dann hast du es nicht verstanden. Das macht sehr wohl einen großen Unterschied.

Monger

2010-05-10, 14:44:08

Dann hast du es nicht verstanden. Das macht sehr wohl einen großen Unterschied.
Dann erkläre es mir. Was hat die dezentrale Verwaltung für Vorteile - mal abgesehen davon, dass man sich den Server spart?

Wenn man nicht gerade mit dem Laptop mobil unterwegs ist, verstehe ich auch den Sinn des lokalen Repositories nicht so wirklich.

Ach, übrigens: du hast gerne mal die Tendenz, wie in diesem Post ein lapidares "... ist Blödsinn" loszulassen, bist dann aber zu faul, auch irgendetwas konstruktives zur Diskussion beizutragen. Für mich ist dies das selbe Niveau wie ein Smilie-Post. Also bitte: schreib vernünftig, oder gar nichts.

Gandharva

2010-05-10, 19:09:16

Ich finde diese Art der dezentralen Quellverwaltung jetzt nicht sooo entscheidend.

- branch handling / merges - da pulverisiert Git ein SVN geradezu. Schon mal versucht komplexe Sachen in SVN zu mergen? Viel Spass beim Konflikte auflösen. ;)
- Performance
- erhöhte Ausfallsicherheit "per Design"
- Arbeiten komplett ohne Serveranbindung möglich!
- Braucht viel weniger Platz (grade bei großen Projekten wichtig!)

Ach ja, versuch das mal mit SVN:
http://www.kernel.org/pub/software/scm/git/docs/git-cherry-pick.html
http://www.kernel.org/pub/software/scm/git/docs/git-grep.html
Gibt noch viel mehr solcher Killerbefehle, die man, wenn man sie 1x benutzt hat nie mehr missen will. SVN wirkt in meinen Augen, im Gegensatz zu Git, einfach nur altbacken und vor allem unflexibel.

Die Stärke von Subversion ist halt, dass es mittlerweile schon lange etabliert ist, und es sehr ausgereifte und vielseitige Tools dafür gibt.
Nur weil es etwas schon lange gibt, heisst das nicht das es automatisch besser ist als etwas neueres.

TortoiseSVN ist wohl einer der verbreitesten und besten SVN Clients überhaupt.
Ja, TortoiseSVN ist gut und der Windows Nutzer hat wohl auch keine andere Alternative. Allerdings gibt es auch gute GUIs für Git (Für die Leute die es nötig haben ;) ). git-cola z.B. nutze ich hier. Dafür gibt es glaueb ich sogar auch einen Windows Client.

Es gibt so einige Web Plugins die man auf dem Server aufsetzen kann, sogar mit integrierter Meilensteinplanung und Bugtracking wie z.B. Trac.
Trac arbeitet übrigens auch problemlos mit Git zusammen.
http://trac-hacks.org/wiki/GitPlugin
http://trac-hacks.org/wiki/GitwebPlugin

Kommt halt immer drauf an, was man braucht. Für uns war es entscheidend, dass sich das in den Gesamtprozess gut eingliedert, weil wir halt noch etwas mehr als nur klassische Quellverwaltung brauchen. Deshalb ist uns z.B. auch AnkhSVN als Client schlicht zu wenig.
Gerade wenn man etwas mehr als nur ein klassisches VCS braucht sollte man nicht mehr auf SVN setzen. Ganz nebenbei ist ein klassisches Arbeiten im Sinne von SVN (Server<->Client) mit Git auch möglich. Man muss sich nur an ein paar Regeln halten. Allerdings führt das in meinen Augen einige Vorteile von Git ad absurdum.

Monger

2010-05-10, 19:57:22

- branch handling / merges - da pulverisiert Git ein SVN geradezu. Schon mal versucht komplexe Sachen in SVN zu mergen? Viel Spass beim Konflikte auflösen. ;)

Zumindest bei uns hatten wir bisher erstaunlich wenig Bedarf am Branchen. Da du ja bis zum Commit de Facto jederzeit einen privaten Branch auf deinem Rechner hast, macht Branching eigentlich nur Sinn wenn man wirklich aus der selben Produktlinie parallel an verschiedenen Ständen arbeiten muss. Für die wenigen Fälle wo wir z.B. auf einen bestimmten Release hin Änderungen einpflegen mussten, haben wir das halt mit Patches gemacht.

Wobei... wenn ich drüber nachdenke, hätte ich mir auch gewünscht, bestimmte Änderungen innerhalb der selben Datei auch nur zu bestimmten Zeiten einspielen zu können.

- Performance
- erhöhte Ausfallsicherheit "per Design"
- Arbeiten komplett ohne Serveranbindung möglich!
- Braucht viel weniger Platz (grade bei großen Projekten wichtig!)

Betrifft das auch Binärdaten? Weil das ist ja eine echte Achillesferse von SVN.

Ach ja, versuch das mal mit SVN:
http://www.kernel.org/pub/software/scm/git/docs/git-cherry-pick.html
http://www.kernel.org/pub/software/scm/git/docs/git-grep.html

Sorry, ich kann mir gerade darunter nix vorstellen. Was wäre denn so ein Anwendungsfall z.B. von Cherry Picking?

Ja, TortoiseSVN ist gut und der Windows Nutzer hat wohl auch keine andere Alternative. Allerdings gibt es auch gute GUIs für Git (Für die Leute die es nötig haben ;) ). git-cola z.B. nutze ich hier. Dafür gibt es glaueb ich sogar auch einen Windows Client.

Ein guter Windows Client ist halt für mich schon essentiell. Gerne auch mit Integration in Visual Studio, aber direkt auf dem Dateisystem ist halt deutlich flexibler. Aber da es ja offenbar auch ein TortoiseGit gibt, werde ich mir das doch mal genauer anschauen. Sieht ja auch verdächtig danach aus, als würden die TortoiseSVN auf TortoiseGit gerade portieren.

Trac arbeitet übrigens auch problemlos mit Git zusammen.
http://trac-hacks.org/wiki/GitPlugin
http://trac-hacks.org/wiki/GitwebPlugin

Auch sehr interessant zu wissen. Danke.

noid

2010-05-10, 19:58:49

- branch handling / merges - da pulverisiert Git ein SVN geradezu. Schon mal versucht komplexe Sachen in SVN zu mergen? Viel Spass beim Konflikte auflösen. ;)
- Performance
- erhöhte Ausfallsicherheit "per Design"
- Arbeiten komplett ohne Serveranbindung möglich!
- Braucht viel weniger Platz (grade bei großen Projekten wichtig!)

Ach ja, versuch das mal mit SVN:
http://www.kernel.org/pub/software/scm/git/docs/git-cherry-pick.html
http://www.kernel.org/pub/software/scm/git/docs/git-grep.html
Gibt noch viel mehr solcher Killerbefehle, die man, wenn man sie 1x benutzt hat nie mehr missen will. SVN wirkt in meinen Augen, im Gegensatz zu Git, einfach nur altbacken und vor allem unflexibel.

Nur weil es etwas schon lange gibt, heisst das nicht das es automatisch besser ist als etwas neueres.

Ja, TortoiseSVN ist gut und der Windows Nutzer hat wohl auch keine andere Alternative. Allerdings gibt es auch gute GUIs für Git (Für die Leute die es nötig haben ;) ). git-cola z.B. nutze ich hier. Dafür gibt es glaueb ich sogar auch einen Windows Client.

Trac arbeitet übrigens auch problemlos mit Git zusammen.
http://trac-hacks.org/wiki/GitPlugin
http://trac-hacks.org/wiki/GitwebPlugin

Gerade wenn man etwas mehr als nur ein klassisches VCS braucht sollte man nicht mehr auf SVN setzen. Ganz nebenbei ist ein klassisches Arbeiten im Sinne von SVN (Server<->Client) mit Git auch möglich. Man muss sich nur an ein paar Regeln halten. Allerdings führt das in meinen Augen einige Vorteile von Git ad absurdum.

Ich weiss nicht wo und mit wem du arbeitest - aber hier bei uns ist SVN schon Ketzergedenkengut. Git klingt zwar nett, aber ich bezweifle, dass sich sowas hier durchsetzen würde (gerade das "keine GUI unter xy" schlägt bei uns alles). ;(

Möchte dir dennoch danken, für die Auszüge - mal schauen ob ich sowas lokal mal für kleine Spielereien/Scripte/Tools nutzen kann/werde. :freak:

PatkIllA

2010-05-10, 20:13:42

noid

2010-05-10, 20:20:05

Was mich ja interessieren würde wieviele von euch nightly-/automated build systeme wie zB cruisecontrol.net nutzen?

Gandharva

2010-05-10, 20:22:09

Zumindest bei uns hatten wir bisher erstaunlich wenig Bedarf am Branchen. Da du ja bis zum Commit de Facto jederzeit einen privaten Branch auf deinem Rechner hast, macht Branching eigentlich nur Sinn wenn man wirklich aus der selben Produktlinie parallel an verschiedenen Ständen arbeiten muss. Für die wenigen Fälle wo wir z.B. auf einen bestimmten Release hin Änderungen einpflegen mussten, haben wir das halt mit Patches gemacht.
Du hast eben keinen echten lokalen Branch auf deinem Rechner bis du den Krempel hochschiebst. Du hast lediglich lokale Änderungen die _nicht_ getrackt werden. Das ist ein gewaltiger Unterschied.
Mit Git ist man da viel freier. Schnell einen Branch erstellen um was zu testen. Nebenbei wurden im Master Tree schon Änderungen gemacht. Du befindest deine Test für gut -> merge und fertig. Und das klappt quasi immer ohne Konflikte. :)

Betrifft das auch Binärdaten? Weil das ist ja eine echte Achillesferse von SVN.
Binärdaten sind immer ein Problem in einem VCS. Da nehmen sich Git und SVN glaub ich nicht viel. Bei reinem Text ist Git aber klar überlegen.

Sorry, ich kann mir gerade darunter nix vorstellen. Was wäre denn so ein Anwendungsfall z.B. von Cherry Picking?
Du hast ein Repo zu einem bestimmten Zeitpunkt geklont oder ausgecheckt, zwischenzeitlich wurden viele Änderungen gemacht von denen du aber nicht alle haben willst sondern nur einige bestimmte. -> "git-cherry-pick"

git-grep ist eine extrem schnelle pattern matching Suche übers komplette Repo. Du willst z.B. wissen wo eine bestimmte Variable, Funktion oder was auch immer überall verwendet wird: "git grep foo" -> bingo! Schon hast du eine Auflistung aller Dateien in der Deine Variable oder Funktion verwendet wird.

PatkIllA

2010-05-10, 20:26:17

Mit Git ist man da viel freier. Schnell einen Branch erstellen um was zu testen. Nebenbei wurden im Master Tree schon Änderungen gemacht. Du befindest deine Test für gut -> merge und fertig. Und das klappt quasi immer ohne Konflikte. :)Solange nicht an der gleichen Stelle in der gleichen Datei Änderungen gemacht wurden klappt das auch bei SVN erstaunlich gut und einen eigenen Branch erstelle ich auch ruckzuck mit SVN.

Gandharva

2010-05-10, 20:27:51

Ich weiss nicht wo und mit wem du arbeitest - aber hier bei uns ist SVN schon Ketzergedenkengut. Git klingt zwar nett, aber ich bezweifle, dass sich sowas hier durchsetzen würde (gerade das "keine GUI unter xy" schlägt bei uns alles). ;(
Ich wüsste jetzt kein OS wo es nicht auch eine GUI für Git gibt.
Solange nicht an der gleichen Stelle in der gleichen Datei Änderungen gemacht wurden klappt das auch bei SVN erstaunlich gut und einen eigenen Branch erstelle ich auch ruckzuck mit SVN.
Da habe ich schon ganz andere Erfahrungen gemacht. Die gleiche Stelle brauchts dazu nichtmal. Sobald du das gleiche File erwischt sind Probleme quasi vorprogrammiert in SVN. SVN ist diesbezüglich einfach Strunzdumm. ;) SVN weiss ja nichtmal wann der Merge gemacht wurde. Wie soll das da jemals wieder korrekt zusammengebracht werden in etwas komplexeren Fällen?

DanMan

2010-05-10, 20:51:35

Solange nicht an der gleichen Stelle in der gleichen Datei Änderungen gemacht wurden klappt das auch bei SVN erstaunlich gut und einen eigenen Branch erstelle ich auch ruckzuck mit SVN.
Branching ist immer einfach, selbst beim CVS - der Merge danach ist das Problem. :)

Verteilte-VCS sind z.B. auch super, wenn man alleine an etwas arbeitet, aber auf Versionskontrolle nicht verzichten mag. Man kann es sich komplett sparen einen Server aufzusetzen. Man initialisiert einfach ein Verzeichnis und los gehts.

Davon abgesehen - wenn man eine taugliche IDE wie z.B. Eclipse benutzt, dann ist der Unterschied zw. SVN und DVCS lange nicht mehr so groß, wie wenn man alles über die Konsole durchführt.

CVS ist aber definitiv tot. Das peilt ja nicht mal, wenn man eine Datei umbenennt. :|
Kann git das eigentlich? Mercurial kann es, und ich frage, weil hier steht (http://versioncontrolblog.com/comparison/Bazaar/CVS/Git/Mercurial/Subversion/index.html) git könne es nicht (SVN übrigens auch nicht?).

PatkIllA

2010-05-10, 20:52:43

Branching ist immer einfach, selbst beim CVS - der Merge danach ist das Problem. :)Ich meinte den Merge. Das hab ich schon dutzendfach gemacht und Ärger gibt es nur, wenn an der gleichen Stelle in der gleichen Datei geändert wurde.
Da habe ich schon ganz andere Erfahrungen gemacht. Die gleiche Stelle brauchts dazu nichtmal. Sobald du das gleiche File erwischt sind Probleme quasi vorprogrammiert in SVN. SVN ist diesbezüglich einfach Strunzdumm. ;) SVN weiss ja nichtmal wann der Merge gemacht wurde. Wie soll das da jemals wieder korrekt zusammengebracht werden in etwas komplexeren Fällen?
Was schon mal von welchem Branch mit welchen Revisionen gemerged wurde merkt sich SVN (wenn auch etwas dämlich über die Properties). Was meinst du mit wann der Merge gemacht wurde? Den Merge machst du doch gerade und welche Version von welcher Datei stammt wird auch branchübergreifend behandelt.

Monger

2010-05-10, 20:56:24

Wie oft (oder wohl eher selten) machst du denn ein Commit?
Im selben Repository (sprich: im selben Projekt) ungefähr ein bis zweimal die Woche. Schwankt natürlich sehr stark: wenn die Änderungen dringend gebraucht werden, natürlich manchmal auch mehrmals täglich.

Was mich ja interessieren würde wieviele von euch nightly-/automated build systeme wie zB cruisecontrol.net nutzen?
Wir haben früher mal nightly Builds gemacht - aber zumindest für unseren Fall halte ich das für unsinnig. Ich will wissen was in einem Build drin ist, bevor ich ihn veröffentliche. Wir builden also nach Bedarf.

Du hast ein Repo zu einem bestimmten Zeitpunkt geklont oder ausgecheckt, zwischenzeitlich wurden viele Änderungen gemacht von denen du aber nicht alle haben willst sondern nur einige bestimmte. -> "git-cherry-pick"

Warum sollte ich nicht alle Änderungen haben wollen? :confused:

git-grep ist eine extrem schnelle pattern matching Suche übers komplette Repo. Du willst z.B. wissen wo eine bestimmte Variable, Funktion oder was auch immer überall verwendet wird: "git grep foo" -> bingo! Schon hast du eine Auflistung aller Dateien in der Deine Variable oder Funktion verwendet wird.
Naja, okay. Das kann ich im lokalen Dateisystem natürlich mindestens genauso gut, sofern ich nicht zwingend irgendeine spezifische Revision will.

SVN weiss ja nichtmal wann der Merge gemacht wurde. Wie soll das da jemals wieder korrekt zusammengebracht werden in etwas komplexeren Fällen?
Wie meinst du das? Natürlich weiß SVN, von wann deine lokalen Änderungen sind, und von wann die Head Revision. Ich kann auf jeden Fall die Konflikte die ich dieses Jahr schon hatte an einer Hand abzählen.

PatkIllA

2010-05-10, 20:59:11

Im selben Repository (sprich: im selben Projekt) ungefähr ein bis zweimal die Woche. Schwankt natürlich sehr stark: wenn die Änderungen dringend gebraucht werden, natürlich manchmal auch mehrmals täglich.Und wenn du nach 4 Tagen merkst das du dich in den letzten Stunden verrant hast pfummelst du alles von Hand wieder auseinander und stellst aus dem Gedächtnis den Stand von morgens wieder her oder machst die Arbeit der ganzen Woche rückgängig? :eek:

Elemental

2010-05-10, 21:00:11

Gandharva

2010-05-10, 21:05:35

Vertippt, es sollte natürlich heissen: SVN weiss ja nichtmal wann der Branch gemacht wurde. Und mein letzter Stand ist das SVN dies nicht exakt weiss.

DarkFox

2010-05-10, 21:07:11

PS: wer sich über die Entstehung von Git und einige Hintergründe interessiert und hinter dem Mond gelebt hat;), dem kann ich nur den Vortrag von Linus Torvalds ans Herz legen: http://www.youtube.com/watch?v=4XpnKHJAok8
Incl. dem berühmten: "if you use svn you are ugly and stupid" :D

PatkIllA

2010-05-10, 21:10:35

Vertippt, es sollte natürlich heissen: SVN weiss ja nichtmal wann der Branch gemacht wurde. Und mein letzter Stand ist das SVN dies nicht exakt weiss.
Da SVN sich ja eh immer die Änderungen gegenüber der letzten Revision merkt kann man doch ganz einfach den letzten gemeinsamen Commit bestimmen.

catamaran

2010-05-10, 21:17:41

Wir setzen in der Arbeit IBM Clearcase ein, aber das is auch nicht der Weisheit letzter Schluss. Meine privaten Projekte zu Hause hab ich bisher immer nur lokal auf Platte gespeichert.
Dachte nun daran, daheim den TFS2010 zu installieren, um dort auch eine Versions-Kontrolle zu haben. Hat den schon jemand selber im Einsatz und kann was Pro/Kontra zum TFS sagen?

Den haben wir seit ein paar Wochen tatsächlich in der Firma im Einsatz. Allerdings nur mit den Standardeinstellungen. Der TFS ist viel mehr als eine reine Versionierung. Bug-Tracking, Tests, Web-Interface, automatische Builds etc... alles mit drin und vieles auch direkt aus VS2010 zugänglich.
Den ganzen Umfang habe ich noch nicht erfasst.

Monger

2010-05-10, 21:58:41

Und wenn du nach 4 Tagen merkst das du dich in den letzten Stunden verrant hast pfummelst du alles von Hand wieder auseinander und stellst aus dem Gedächtnis den Stand von morgens wieder her oder machst die Arbeit der ganzen Woche rückgängig? :eek:
Ich pfusche niemals am lebenden Objekt rum. Wenn ich irgendwelche größeren strukturellen Änderungen vorhabe, habe ich die vorher an einem kleinen Modell erstmal ausgetestet, erst dann implementiere ich. Die Funktion teste ich dann anhand von kleinen Modultests, und erst dann committe ich. Dass ich tatsächlich mal die Arbeit eines ganzen Tages verwerfen muss, passiert eigentlich nie.

Hat vielleicht auch damit zu tun, dass wir in erster Linie Libraries verwalten. Da denkt man lieber mal drei Tage darüber nach ob man diese Funktion wirklich braucht, bevor man dann die API aufbohrt! ;)
Den Luxus hat man in einer normalen Anwendungsentwicklung wahrscheinlich nicht.

Wir setzen in der Arbeit IBM Clearcase ein, aber das is auch nicht der Weisheit letzter Schluss. Meine privaten Projekte zu Hause hab ich bisher immer nur lokal auf Platte gespeichert.
Dachte nun daran, daheim den TFS2010 zu installieren, um dort auch eine Versions-Kontrolle zu haben. Hat den schon jemand selber im Einsatz und kann was Pro/Kontra zum TFS sagen?
Bei uns haben alle Entwicklungsteams ClearCase im Einsatz. Ich gehöre ja streng genommen nicht zur Entwicklung, sondern nur zur Testautomatisierung - deshalb sind wir da mit Geld für Lizenzen auch deutlich knapper, und haben nur ein paar ClearCase Clients bei uns laufen.

Wir haben jetzt wie gesagt nur letzte Woche mal probeweise einen TFS2010 Server aufgesetzt und damit rumgespielt. Erstens mal: den Server aufzusetzen, hat vielleicht ne Stunde gedauert - und das ohne dass wir da groß nachlesen mussten. Und was wir dann im Anschluss darauf ausprobiert haben, war erstaunlich reibungslos: Tasks erstellen und verteilen, E-Mail Benachrichtigungen aktivieren, Rechteverwaltung, Projekte erstellen, Änderungen committen, Blame, Testfälle erstellen, per Testcenter manuelle Tests durchführen, Bug Reports erstellen, Bugs beheben und dann in der Taskleiste beim Commit auch gleich abhaken, Mergen... erst beim Build Server bin ich dann so langsam ins Straucheln gekommen, den habe ich nicht so wirklich gepeilt.

Aber alleine dass wir all das an einem halben Tag ausprobiert haben, nachdem wir nur zwei kleine Einführungsvideos auf Channel 9 davon gesehen haben, spricht doch für sich.
Den einzigen Kritikpunkt den ich habe, ist dass es voll und ganz auf Visual Studio (und MS Office Produkte) zugeschnitten ist. Wir nutzen halt die Quellverwaltung auch noch für ganz andere Daten, das wäre damit ziemlich schwerfällig. Und es ist schwierig, mit anderen Tools zu mischen. Wenn du von der Produktdefinition und Projektplanung (über MS Project) bis über die Entwicklung bis hin zur Qualitätssicherung ein einheitliches Verfahren haben willst, ist das garantiert spitze. Für unsere kleine Testautomatisierung fände ich das gerade n bißchen Overkill.

Besser als der ClearCase Rotz ist es aber allemal! ;)
Was haben wir da schon gelacht, wenn wiedermal die Entwickler scharenweise zum Kaffeeautomaten laufen, weil der ClearCase Server wieder streikt.

Monger

2010-05-10, 22:20:40

Mit Git ist man da viel freier. Schnell einen Branch erstellen um was zu testen. Nebenbei wurden im Master Tree schon Änderungen gemacht. Du befindest deine Test für gut -> merge und fertig. Und das klappt quasi immer ohne Konflikte. :)

Ich glaube, an der Stelle habe ich schlicht ein Verständnisproblem. Wann genau machst du denn einen Branch?

Für mich bedeutet ein Branch: ich mache aus einem Produkt mehrere, die ich parallel pflegen muss. In aller Regel heißt das, dass man schon auf einem neuen Major Release arbeitet, aber aus welchen Gründen auch immer den Minor Release noch nachpatchen muss.

Das halte ich aber bei kleineren Projekten für relativ unwahrscheinlich - und erst recht bei Open Source Produkten. Warum sollte man auf einer alten Version stehenbleiben, wenn man jederzeit zur neuesten wechseln kann?

Und selbst dann kann es eigentlich nur einige wenige Branches geben. Bei dir hört sich das dagegen so an, als hättest du ständig einen Haufen private Branches. Für was eigentlich? Machst du für jede neue Arbeitsaufgabe quasi einen neuen Branch auf, und mergst dann genau die dazu passenden Änderungen in den Hauptzweig rein? Aber wozu? Warum nicht einfach alle lokalen Änderungen committen, sobald du mit ihnen fertig bist?

PatkIllA

2010-05-10, 22:29:50

Ich glaube, an der Stelle habe ich schlicht ein Verständnisproblem. Wann genau machst du denn einen Branch?

Für mich bedeutet ein Branch: ich mache aus einem Produkt mehrere, die ich parallel pflegen muss. In aller Regel heißt das, dass man schon auf einem neuen Major Release arbeitet, aber aus welchen Gründen auch immer den Minor Release noch nachpatchen muss.

Das halte ich aber bei kleineren Projekten für relativ unwahrscheinlich - und erst recht bei Open Source Produkten. Warum sollte man auf einer alten Version stehenbleiben, wenn man jederzeit zur neuesten wechseln kann?Weil der Hauptentwicklungszweig in vielen Fällen ungetestet ist und man trotzdem den Fehler rausmachen will/muss. Oft sind Fehler ja auch mit ein paar Zeilen behoben, weil man z.B. an eine Bedingung nicht gedacht. Da pflegt man dann in den Branch halt nur die Fehlerbehebung ein und kann vergleichweise sicher sein sich nicht allzuviele Nebeneffekte eingebrokt zu haben.

Und selbst dann kann es eigentlich nur einige wenige Branches geben. Bei dir hört sich das dagegen so an, als hättest du ständig einen Haufen private Branches. Für was eigentlich? Machst du für jede neue Arbeitsaufgabe quasi einen neuen Branch auf, und mergst dann genau die dazu passenden Änderungen in den Hauptzweig rein? Aber wozu? Warum nicht einfach alle lokalen Änderungen committen, sobald du mit ihnen fertig bist?Wir machen von jeder veröffentlichten nummerierten Version einen branch auf wo dann einfache Fehlerbehebungen reinkommen aber keine neue Features. In der Zwischenzeit wird dann am trunk weiterentwickelt. Den trunk kann man aber niemanden zum produktiven Arbeiten geben, bis der durch die QS ist.
Ansonsten macht man einen Branch wenn man eine größe Änderung hat, die auch die Kollegen betrifft. Da kann man dann auch Zwischenstände einchecken, die nicht laufen oder evtl nicht mal kompilierbar sind. Zu den Zwischenständen kann man jederzeit wieder zurück und außerdem hat man ein Backup gegen Festplattendefekt, Fehlbedienung, Virusbefall oder sonst was.

Coda

2010-05-11, 00:23:37

Ach, übrigens: du hast gerne mal die Tendenz, wie in diesem Post ein lapidares "... ist Blödsinn" loszulassen, bist dann aber zu faul, auch irgendetwas konstruktives zur Diskussion beizutragen. Für mich ist dies das selbe Niveau wie ein Smilie-Post. Also bitte: schreib vernünftig, oder gar nichts.

Den Modtext kannst du dir bei mir sparen.

"Ich finde diese Art der dezentralen Quellverwaltung jetzt nicht sooo entscheidend." hat exakt genauso viel Inhalt.

Und ich lasse gerne solchen Unsinn stehen. Da rollt es mir die Fußnägel hoch.

Es gibt sehr gute und sehr viele Quellen mit Informationen darüber die man sich nur zur Gemüte führen muss, deshalb finde ich es als reine Zeitverschwendung dazu mehr zu schreiben.

noid

2010-05-11, 07:22:07

Den Modtext kannst du dir bei mir sparen.

"Ich finde diese Art der dezentralen Quellverwaltung jetzt nicht sooo entscheidend." hat exakt genauso viel Inhalt.

Und ich lasse gerne solchen Unsinn stehen. Da rollt es mir die Fußnägel hoch.

Es gibt sehr gute und sehr viele Quellen mit Informationen darüber die man sich nur zur Gemüte führen muss, deshalb finde ich es als reine Zeitverschwendung dazu mehr zu schreiben.

@OT:
Der Modtext ist angebracht, weil dein Beitrag für ein Forum eigentlich total unangebracht ist - entweder hast du einen Beitrag (also nicht nur 2-3 Wörter und Antworten) oder du schreibst er keinen, wenn es dir deine Zeit nicht wert ist überhaupt eine eigene Meinung/Fakten/whatever zu bringen.
Aber schön, wenn es nicht nur mir alleine auffällt, da könnte man ja von persönlichem Bias ausgehen.

Wenn man in einem Forum nachfragt, dann wäre selbst eine Faulenzerantwort mit 2-3 Argumenten und einem seriösen Link nett, alles andere ist ne arrogante Schiene.

@Gandharva: für binärdokumente jeder Art ist das dezentrale aber nüscht. Da kann man oft nicht patchen und auch wenn es dem Konzept des CVS widerspricht, es wird gemacht - und da hat man dann einen Nachteil.

=Floi=

2010-05-14, 11:58:43

Es gibt sehr gute und sehr viele Quellen mit Informationen darüber die man sich nur zur Gemüte führen muss, deshalb finde ich es als reine Zeitverschwendung dazu mehr zu schreiben.

es ist hald schade, wenn du dein umfangreiches fachwissen einfach nicht weitergeben willst, und jeder wieder bei 0 anfangen soll. (nur weil du zu faul bist? hier 5 zeilen in 3 minuten zu schreiben?) so wäre die menschheit nicht da wo sie heute ist und warum soll jeder den gleichen harten weg gehen, wenn du ihn schon gegangen bist?
echt schwach von dir. fachlich bist du echt eine bereicherung für das forum, aber menschlich ist es echt schade um dich.