wenn, dann gleich auf SVN umstellenderget hat geschrieben:Update: Server läuft
Allerdings wird er gerade nur mit Klebeband zusammen gehalten ......
(übertragen gesprochen)
SSH login ist disabled !
Aber CVS über SSH geht !
Ich werden das CVS in den nächsten Wochen komplett neu aufsetzten.
Die Frage stellt sich, wollen wir wechseln zu svn oder wat weiss ich.
Macht mal Vorschläge.
[Umfrage] CVS-Alternativen: Git, SVN etc...
-
- Tuxboxer
- Beiträge: 4332
- Registriert: Dienstag 7. Mai 2002, 16:04
Re: DNS-Eintrag cvs.tuxbox.org?
-
- Administrator
- Beiträge: 2675
- Registriert: Donnerstag 28. September 2006, 18:18
Re: DNS-Eintrag cvs.tuxbox.org?
Na, das selbe in grün, ein wirklicher Fortschritt wäre das nicht, da kann man gleich dabei bleiben.Tommy hat geschrieben:wenn, dann gleich auf SVN umstellen
-
- Erleuchteter
- Beiträge: 625
- Registriert: Samstag 8. September 2007, 15:17
Re: DNS-Eintrag cvs.tuxbox.org?
GIT!dbt hat geschrieben:Na, das selbe in grün, ein wirklicher Fortschritt wäre das nicht, da kann man gleich dabei bleiben.Tommy hat geschrieben:wenn, dann gleich auf SVN umstellen :wink:
Wenn man sich mal dran gewöhnt hat will man nix andres mehr. gitorious.org oder github...
-
- CDK-Experte
- Beiträge: 4335
- Registriert: Donnerstag 3. April 2008, 13:05
Re: DNS-Eintrag cvs.tuxbox.org?
Ich sehe immer noch keinen Grund, von CVS abzurücken
@derget: Danke für die Reparatur!
@derget: Danke für die Reparatur!
-
- Administrator
- Beiträge: 2675
- Registriert: Donnerstag 28. September 2006, 18:18
Re: DNS-Eintrag cvs.tuxbox.org?
[quote="rhabarber1848"]Ich sehe immer noch keinen Grund, von CVS abzurücken
...aber auch keinen, auf SVN umzusteigen.
...aber auch keinen, auf SVN umzusteigen.
-
- CDK-Experte
- Beiträge: 4335
- Registriert: Donnerstag 3. April 2008, 13:05
Re: DNS-Eintrag cvs.tuxbox.org?
Wenn schon nicht mehr CVS, dann git und nichts anderes. SVN ist für mich absolut kein Thema. Just my 2 centsdbt hat geschrieben:...aber auch keinen, auf SVN umzusteigen.
-
- Erleuchteter
- Beiträge: 625
- Registriert: Samstag 8. September 2007, 15:17
Re: DNS-Eintrag cvs.tuxbox.org?
++derget hat geschrieben:Die Frage stellt sich, wollen wir wechseln zu svn oder wat weiss ich.
Macht mal Vorschläge.
Also wenn das so einfach geht, dann zu GIT. Das raucht CVS uns SVN mal eben in der Pfeife von Seiten der Funktionalität.
-
- CDK-Experte
- Beiträge: 4335
- Registriert: Donnerstag 3. April 2008, 13:05
Re: DNS-Eintrag cvs.tuxbox.org?
Es ist nur die Frage, ob das Tuxbox-Projekt wirklich die Funktionalität von git benötigtStriper hat geschrieben:von Seiten der Funktionalität.
oder ob es nicht overkill ist. Meine Bedürfnisse hat CVS immer gut erfüllt, ich persönlich
finde git unübersichtlich. Mehr möchte ich eigentlich nicht dazu schreiben, da Diskussionen
dieser Art woanders sicherlich schon öfter und länger geführt wurden.
Ich werde nicht weglaufen, wenn ein Umstieg auf git erfolgen sollte, nur müsste die gesamte
history und die vielen branches aus dem CVS lückenlos portiert werden, damit es Sinn macht.
In diesem Fall würde ich mich freuen, wenn man mir mit den ersten Schritten mit git hier
kurze Fragen beantworten könnte, ohne mich auf seitenlange Howtos zu verweisen
Allein das erstellen eines diffs aus git, was von den U-Boot-Maintainern akzeptiert wurde, war
wirklich ein ziemlicher Aufwand, den ich ungerne wiederholen möchte... Das hat nun nichts
mit git an sich zu tun, sondern eher mit den Methoden der U-Boot-Entwickler - die ich aber
verstehen kann, da git eine große Hilfe für deren Entwicklung ist -, nur frage ich mich, ob wir
hier wirklich Bedarf für git haben. Wir haben nur einen branch (abgesehen von Kernel 2.6@
dbox2), keine custodians oder große externe repos, die regelmäßig zu mergen wären.
Grr, jetzt habe ich doch mehr geschrieben als ich ursprünglich wollte, jetzt ist aber Schluß
-
- Erleuchteter
- Beiträge: 625
- Registriert: Samstag 8. September 2007, 15:17
Re: [Umfrage] CVS-Alternativen: Git, SVN etc...
Ich kann nur jedem wärmstens die GUI git-cola empfehlen. Damit fällt der Umstieg um einiges leichter. Das ist auf jedem Rechner der Python installiert hat in 3 Minuten eingerichtet.
http://cola.tuxfamily.org/
Für einige Sachen greife ich dann doch noch zu Console, aber das meiste lässt sich problemlos über die git-cola GUI erledigen. Diffs etc... sind in 30 Sekunden erstellt damit. Mit ein paar Einträgen in der Config lassen sich mehrere Repos in Sekundenschnelle abgleichen.
http://cola.tuxfamily.org/
Für einige Sachen greife ich dann doch noch zu Console, aber das meiste lässt sich problemlos über die git-cola GUI erledigen. Diffs etc... sind in 30 Sekunden erstellt damit. Mit ein paar Einträgen in der Config lassen sich mehrere Repos in Sekundenschnelle abgleichen.
Diese Argumentation hinkt miho aber gewaltig. Selbst für weitaus weniger komplexe Projekte (grade klein ist das hier ja nicht finde ich...) lohnt ein Umstieg auf ein komfortableres Versionierungssystem immer. Mal ganz ehrlich, ich denke die meisten Gegner scheuen schlicht die Einarbeitung ins Neuland. ;)rhabarber1848 hat geschrieben:Es ist nur die Frage, ob das Tuxbox-Projekt wirklich die Funktionalität von git benötigtStriper hat geschrieben:von Seiten der Funktionalität.
oder ob es nicht overkill ist.
Re: [Umfrage] CVS-Alternativen: Git, SVN etc...
Es wäre möglicherweise hilfreich, wenn jemand mal eine gegenüberstellende Übersicht erstellt, die die Vor- u. Nachteile anzeigt.
-
- Developer
- Beiträge: 4189
- Registriert: Sonntag 2. November 2003, 12:36
Re: [Umfrage] CVS-Alternativen: Git, SVN etc...
Naja. Verteilte VCS haben auch ihre Tücken. Ich persönlich scheue eine unübersichtliche History wenn z.B. wild kreuz und quer hin und her gemerged wird. Man bekommt das sehr schnell kaputt, und hinterher nur noch sehr schwer gefixt.
Wenn ich sehe, wie unsorgfältig teilweise schon im CVS eingecheckt wird etc, dann will ich diese Leute nicht auf ein git-repo loslassen.
Ein schönes Beispiel, wie man es nicht machen sollte, ist z.B. mein tripledragon repo... Aber es hat halt einige Übung gebraucht, bis ich raus hatte, wie man es richtig macht.
Für ein Projekt wie tuxbox würde das mit git IMHO nur ordentlich funktionieren, wenn es einen integrator gäbe, der am schluss alles zusammenmerged und ins "offizielle" Repo pushed. So wie es übrigens bei den meisten grösseren Projekten ist.
Die Frage ist, ob das wirklich gewollt ist. Für das jetzige development-Modell ist CVS eigentlich ausreichend, auch wenn es ein extrem anstrengendes Tool ist. SVN wäre deswegen besser, weil man von git aus problemlos bidirektional mit SVN interagieren kann. Es fixt für dieses Projekt *das* Hauptproblem von CVS: keine changesets. Mehr ist eigentlich IMHO nicht nötig (auf keinen Fall will ich nochmals lokal mit was anderem als git oder mercurial, oder was vergleichbarem arbeiten).
Die CVS History komplett in git zu importieren ist mir IMHO schon gelungen, dasselbe tool macht auch die "Konvertierung" für SVN, das sollte also auch kein Problem sein.
Gegenüberstellung der Features: http://better-scm.berlios.de/
Wenn ich sehe, wie unsorgfältig teilweise schon im CVS eingecheckt wird etc, dann will ich diese Leute nicht auf ein git-repo loslassen.
Ein schönes Beispiel, wie man es nicht machen sollte, ist z.B. mein tripledragon repo... Aber es hat halt einige Übung gebraucht, bis ich raus hatte, wie man es richtig macht.
Für ein Projekt wie tuxbox würde das mit git IMHO nur ordentlich funktionieren, wenn es einen integrator gäbe, der am schluss alles zusammenmerged und ins "offizielle" Repo pushed. So wie es übrigens bei den meisten grösseren Projekten ist.
Die Frage ist, ob das wirklich gewollt ist. Für das jetzige development-Modell ist CVS eigentlich ausreichend, auch wenn es ein extrem anstrengendes Tool ist. SVN wäre deswegen besser, weil man von git aus problemlos bidirektional mit SVN interagieren kann. Es fixt für dieses Projekt *das* Hauptproblem von CVS: keine changesets. Mehr ist eigentlich IMHO nicht nötig (auf keinen Fall will ich nochmals lokal mit was anderem als git oder mercurial, oder was vergleichbarem arbeiten).
Die CVS History komplett in git zu importieren ist mir IMHO schon gelungen, dasselbe tool macht auch die "Konvertierung" für SVN, das sollte also auch kein Problem sein.
Gegenüberstellung der Features: http://better-scm.berlios.de/
Re: [Umfrage] CVS-Alternativen: Git, SVN etc...
Nochwas dazu:seife hat geschrieben:
Gegenüberstellung der Features: http://better-scm.berlios.de/
http://people.apache.org/~sgoeschl/down ... 5-27_3.pdf
-
- Developer
- Beiträge: 16
- Registriert: Samstag 3. Februar 2007, 15:32
Re: [Umfrage] CVS-Alternativen: Git, SVN etc...
Hallo zusammen,
ich wollte mich auch mal wieder zu diesem Thema melden. Habe so etwas schon hier http://www.tuxbox-cvs.sourceforge.net/f ... =7&t=45342 angedacht.
Es wäre auf jeden Fall sinnvoll von cvs auf svn umzusteigen. Git halte ich für das TuxBox-Projekt nicht machbar. Ich kann hier nur seife vollkommen zustimmen.
Svn hat den Vorteil gegenüber cvs, das es nicht mehr mit Dateien agiert, sondern alle Aktionen auf Verzeichnisse bezieht. Desweiteren sind die sogenannten Externals eine große Erleichterung, um externe Repos einzubeziehen. So könnte man entweder TuxBox in verschiedene Projekte teilen (z.B. CDK, Applikationen, etc.) oder externe Projekte einbinden. Die Verwaltung von Branches und Tags ist sehr komfortabel. Da kann cvs nicht mithalten. Git sehe ich als den totalen Overkill für TuxBox an und ohne einen Integrator wird es da nicht gehen.
Ein vollständiger Import vom cvs ins svn ist gar kein Problem. Ich habe selber diverse Projekte migriert. TuxBox habe ich damals mal auf SourceForge angelegt und ins svn eingecheckt. Könnt ihr euch auf sf.net anschauen (Projekt: tuxbox2).
Wenn man nun auch noch svn mit git synchen kann, dann hätte das evtl. auch noch Vorteile für die Git-Wütigen
Für den Normal-User halte ich git für sehr, sehr unhandlich. Ich will hier aber keinen Glaubenskrieg über Versionierungssysteme anfangen. Das haben andere schon gemacht. Der Ausgang solcher Diskussionen ist immer der Gleiche: Es gibt keine Gewinner. Das ist wie bei Kunst oder bei gutem Essen. Geschmackssache eben!
Vielleicht noch einen Tipp. Mit dem CommitMonitor (http://tools.tortoisesvn.net/CommitMonitor) kann man jederzeit auf dem Laufenden gehalten werden über svn checkins. Das könnte für den einen oder anderen ja auch interessant sein.
Ok, genug geschrieben. Dies waren meine Erkenntnisse / Ideen zu diesem Thema. Wie immer ist dies alles nur meine Meinung und natürlich zu diskutieren.
Grüße
Christian
ich wollte mich auch mal wieder zu diesem Thema melden. Habe so etwas schon hier http://www.tuxbox-cvs.sourceforge.net/f ... =7&t=45342 angedacht.
Es wäre auf jeden Fall sinnvoll von cvs auf svn umzusteigen. Git halte ich für das TuxBox-Projekt nicht machbar. Ich kann hier nur seife vollkommen zustimmen.
Svn hat den Vorteil gegenüber cvs, das es nicht mehr mit Dateien agiert, sondern alle Aktionen auf Verzeichnisse bezieht. Desweiteren sind die sogenannten Externals eine große Erleichterung, um externe Repos einzubeziehen. So könnte man entweder TuxBox in verschiedene Projekte teilen (z.B. CDK, Applikationen, etc.) oder externe Projekte einbinden. Die Verwaltung von Branches und Tags ist sehr komfortabel. Da kann cvs nicht mithalten. Git sehe ich als den totalen Overkill für TuxBox an und ohne einen Integrator wird es da nicht gehen.
Ein vollständiger Import vom cvs ins svn ist gar kein Problem. Ich habe selber diverse Projekte migriert. TuxBox habe ich damals mal auf SourceForge angelegt und ins svn eingecheckt. Könnt ihr euch auf sf.net anschauen (Projekt: tuxbox2).
Wenn man nun auch noch svn mit git synchen kann, dann hätte das evtl. auch noch Vorteile für die Git-Wütigen
Für den Normal-User halte ich git für sehr, sehr unhandlich. Ich will hier aber keinen Glaubenskrieg über Versionierungssysteme anfangen. Das haben andere schon gemacht. Der Ausgang solcher Diskussionen ist immer der Gleiche: Es gibt keine Gewinner. Das ist wie bei Kunst oder bei gutem Essen. Geschmackssache eben!
Vielleicht noch einen Tipp. Mit dem CommitMonitor (http://tools.tortoisesvn.net/CommitMonitor) kann man jederzeit auf dem Laufenden gehalten werden über svn checkins. Das könnte für den einen oder anderen ja auch interessant sein.
Ok, genug geschrieben. Dies waren meine Erkenntnisse / Ideen zu diesem Thema. Wie immer ist dies alles nur meine Meinung und natürlich zu diskutieren.
Grüße
Christian
-
- CDK-Experte
- Beiträge: 4335
- Registriert: Donnerstag 3. April 2008, 13:05
Re: [Umfrage] CVS-Alternativen: Git, SVN etc...
Damit kann ich gut leben.Feynman hat geschrieben:Es wäre auf jeden Fall sinnvoll von cvs auf svn umzusteigen.
++Feynman hat geschrieben:Git halte ich für das TuxBox-Projekt nicht machbar. Ich kann hier nur seife vollkommen zustimmen.
-
- Contributor
- Beiträge: 1833
- Registriert: Mittwoch 10. April 2002, 14:39
Re: [Umfrage] CVS-Alternativen: Git, SVN etc...
evtl. solltest du die abstimmung "nachträglich änderbar" umstellen.
ich laufe der diskussion kommen ja doch einige argumente die evtl. eine andere entscheidung rechtfertigen.
ich laufe der diskussion kommen ja doch einige argumente die evtl. eine andere entscheidung rechtfertigen.
-
- Developer
- Beiträge: 4189
- Registriert: Sonntag 2. November 2003, 12:36
Re: [Umfrage] CVS-Alternativen: Git, SVN etc...
btw ist git prinzipiell schon auch für "ein Zentrales Repo auf das alle zuarbeiten" geeignet, aber wenn weiter so gepfuscht wird wie bisher, ist der Schaden, der angerichtet werden kann, potenziell grösser. Da müsste etwas mehr Disziplin herrschen
Ausserdem wird ja nicht wirklich parallel an verschiedenen Sachen gearbeitet - es gibt so geschätzt 5 Aktive, also ist das VCS nicht der Flaschenhals. Insofern darf es auch CVS bleiben.
Ausserdem wird ja nicht wirklich parallel an verschiedenen Sachen gearbeitet - es gibt so geschätzt 5 Aktive, also ist das VCS nicht der Flaschenhals. Insofern darf es auch CVS bleiben.
Re: [Umfrage] CVS-Alternativen: Git, SVN etc...
Dann wäre es doch am einfachsten, wenn man gewisse "Etikette" als Regelwerk festlegt, damit jeder weiß woran man sich zu halten hat. Also sowas wie Commitregeln. Hier gibts ja auch Boardregeln, auf die man (leider) hin und wieder hinweisen muss. Mit den Gepflogenheiten kenn ich mich zwar nicht so aus, aber ich kann mir nicht vorstellen, dass das so ein großes Problem sein soll. Wenn das der ultimative Knackpunkt sein sollte, dann bleiben wir lieber bei CVS.
-
- Erleuchteter
- Beiträge: 448
- Registriert: Samstag 26. November 2005, 00:35
Re: [Umfrage] CVS-Alternativen: Git, SVN etc...
Als Kompromiss könnte man doch auf SVN umsteigen diesen als stable nutzen in dem alles drin ist wie es "tut" und das Git als unstabile und testing . Damit könnten dann die Dev's die auch gerne mal rumprobieren sich austoben im Git gut rumwerkeln, die Meckermäuler die nur auschecken haben ihren stabilen Zweig und die positiven Sachen würden dann immer in einen Zweig zurück ins SVN finden und sind dann dort in einem Zweig da . Soweit ich das laß, arbeiten ja svn und git ganz gut miteinander zusammen.
Nur so mal als Vorschlag
Martin
Nur so mal als Vorschlag
Martin
-
- Developer
- Beiträge: 1475
- Registriert: Dienstag 4. Februar 2003, 22:02
Re: [Umfrage] CVS-Alternativen: Git, SVN etc...
Erstmals finde ich eine Abstimmung etwas unglücklig: Es tendiert nur
Fronten zu bilden, statt gemeinsam die beste Lösung zu suchen. Und,
etwas wie Dietmar sagte, das Abstimmen und das Diskutieren kommt
leicht in der falsche Reihenfolge. Demokratie in Sinn von "eine
Person, eine Stimme" ist hier nicht wirklich angebracht.
Lass uns die Abstimmung als Stimmungsbarometer verstehen, nicht als
Entscheidungsgrundlage.
überflächliche "Kodierrichtlinien" (Zeilenlängen <= x, Kommentare in
bestimmte Sprache und Zeichensatz, Einrücken mit ..., Keine ..., etc) meint,
sondern mehr inhaltlich, etwas was ein Reviewer/Koordinator/Integrator
erfordert. Z.B. selbst bin ich alles anders als glücklig über den
#ifdef-Flut wir letzte Jahren erlebt haben.
Das Projekt, am mindestens in der jetztigen Form, befindet sich in
seinem Schlussstadium. Die jetztige Entwicklungsaktivitäten sind
relativ anspruchslos und hat mehr ein Charakter von vervollständigung
und zusätzliche, nichtessentielle Zusatzfeatures (IMHO, hoffe dass niemand
sich verletzt fühle.). Portierungsarbeit scheint ad-hoc (jemanden
hat sich ein xxx-Box gekauft...) und #ifdef-basiert abzulaufen statt
zu versuchen, die HW-Abhängigkeiten sauber aus Applikationsprogramme
zu isolieren. (Nochmals, hoffe dass niemand
sich verletzt fühle.) Und ich sehe keine Zeichen, dass es sich in der nahe
Zukunft ändern wird.
Es ist nicht schlimmes dadrin, eher ein "mission accomplished". Die
Ergebnisse werden weiterleben, oft in veränderter Form. Die
Developers werden in andere freie Softwareprojekte das gewonnene Knowhow
weiterverwenden.
Was folgt hieraus? Ich bin mir hier nicht ganz sicher. Stabilität,
Zuverlässigkeit und Verfügbarkeit in der Zukunft (auch in Sinn von
Knowhowträger) ist sicherlich wichtigere als anspruchsvolle
Features.
Vielleicht sollte wir erst die Frage um Ziele für die nächste Jahre
stellen, und erst danach die um eine eventuelle Versionsmanagementmigration?
@Feynman: Nett dich wieder zu sehen/lesen!
Fronten zu bilden, statt gemeinsam die beste Lösung zu suchen. Und,
etwas wie Dietmar sagte, das Abstimmen und das Diskutieren kommt
leicht in der falsche Reihenfolge. Demokratie in Sinn von "eine
Person, eine Stimme" ist hier nicht wirklich angebracht.
Lass uns die Abstimmung als Stimmungsbarometer verstehen, nicht als
Entscheidungsgrundlage.
seife hat geschrieben: ...aber wenn weiter so gepfuscht wird wie bisher, ist der Schaden, der angerichtet werden kann, potenziell grösser. Da müsste etwas mehr Disziplin herrschen
Naja, ich glaube nicht, dass seife eine Reihe mit relativdixidix hat geschrieben: Dann wäre es doch am einfachsten, wenn man gewisse "Etikette" als
Regelwerk festlegt, damit jeder weiß woran man sich zu halten
hat. Also sowas wie Commitregeln. Hier gibts ja auch Boardregeln, auf
die man (leider) hin und wieder hinweisen muss. Mit den
Gepflogenheiten kenn ich mich zwar nicht so aus, aber ich kann mir
nicht vorstellen, dass das so ein großes Problem sein soll.
überflächliche "Kodierrichtlinien" (Zeilenlängen <= x, Kommentare in
bestimmte Sprache und Zeichensatz, Einrücken mit ..., Keine ..., etc) meint,
sondern mehr inhaltlich, etwas was ein Reviewer/Koordinator/Integrator
erfordert. Z.B. selbst bin ich alles anders als glücklig über den
#ifdef-Flut wir letzte Jahren erlebt haben.
Das Projekt, am mindestens in der jetztigen Form, befindet sich in
seinem Schlussstadium. Die jetztige Entwicklungsaktivitäten sind
relativ anspruchslos und hat mehr ein Charakter von vervollständigung
und zusätzliche, nichtessentielle Zusatzfeatures (IMHO, hoffe dass niemand
sich verletzt fühle.). Portierungsarbeit scheint ad-hoc (jemanden
hat sich ein xxx-Box gekauft...) und #ifdef-basiert abzulaufen statt
zu versuchen, die HW-Abhängigkeiten sauber aus Applikationsprogramme
zu isolieren. (Nochmals, hoffe dass niemand
sich verletzt fühle.) Und ich sehe keine Zeichen, dass es sich in der nahe
Zukunft ändern wird.
Es ist nicht schlimmes dadrin, eher ein "mission accomplished". Die
Ergebnisse werden weiterleben, oft in veränderter Form. Die
Developers werden in andere freie Softwareprojekte das gewonnene Knowhow
weiterverwenden.
Was folgt hieraus? Ich bin mir hier nicht ganz sicher. Stabilität,
Zuverlässigkeit und Verfügbarkeit in der Zukunft (auch in Sinn von
Knowhowträger) ist sicherlich wichtigere als anspruchsvolle
Features.
Vielleicht sollte wir erst die Frage um Ziele für die nächste Jahre
stellen, und erst danach die um eine eventuelle Versionsmanagementmigration?
@Feynman: Nett dich wieder zu sehen/lesen!
-
- Developer
- Beiträge: 4189
- Registriert: Sonntag 2. November 2003, 12:36
Re: [Umfrage] CVS-Alternativen: Git, SVN etc...
Ich kann Barf da nur zustimmen (mit einer Korrektur: Coding Style würde ich schon wichtig finden ), das Projekt ist einfach in seinem Endstadium angekommen. Neue Sachen kann man nicht einbauen, weil dann die dbox2-Fans das nicht mehr in ihren begrenzten flash-Speicher bekommen (noch mehr #ifdef? - es ist jetzt schon unwartbar genug), oder es halt mal zwischendurch weniger stabil wäre. Die Anzahl der Optionen ist jetzt schon nicht mehr über/durchschaubar, geschweige denn mit vertretbarem Aufwand verifizierbar.
Insofern wird es einfach dahinsiechen , bis endlich die Letzte dbox2 mit einem leisen Rauchzeichen das Zeitliche gesegnet hat, und die Entwicklung wird auf neueren, weniger begrenzten Plattformen weitergehen.
Passiert zumindest bei mir seit längerem so, und ich habe bisher nichts vermisst
Insofern wird es einfach dahinsiechen , bis endlich die Letzte dbox2 mit einem leisen Rauchzeichen das Zeitliche gesegnet hat, und die Entwicklung wird auf neueren, weniger begrenzten Plattformen weitergehen.
Passiert zumindest bei mir seit längerem so, und ich habe bisher nichts vermisst
-
- Erleuchteter
- Beiträge: 595
- Registriert: Donnerstag 1. Januar 2004, 16:59
Re: [Umfrage] CVS-Alternativen: Git, SVN etc...
Schade das es hier kein Danke-Button für Thread im Forum gibt ... sonst hätte Barf und Seife gleich mal eines von mir bekommen
-
- Erleuchteter
- Beiträge: 448
- Registriert: Samstag 26. November 2005, 00:35
Re: [Umfrage] CVS-Alternativen: Git, SVN etc...
Irgendwie hat ja jeder Recht aber für die Zukunft bringt das nichst. Das bedeutet nur das irgendwie alles mehr oder weniger einschläft.
Deshalb habe ich damals schon geschrieben Portierbarkeit.
http://www.tuxbox-cvs.sourceforge.net/f ... 18&t=47652
Das mit den if def usw ist natürlich unglücklich und der eine oder andere würde das heute vermutlich anders machen warum ist es nicht möglich auf der vorhandenen Wissensbasis etwas neues zu machen was für Devs reizvoll ist was wartbar ist was flexibel ist . Es gibt nun soviel werkzeuge da muss es doch möglich sein mit gewissen Kompromissen da eine Schuh draus zu basteln.
Ich gebe zu das ich nicht soviel davon verstehe um sagen zu können so und so muss man es machen oder würde es gehen. Ich bin nur überzeugt davon das es machbar ist . Kluge Köpfe haben an dem Projekt GCC und Toolchain bewissen was alles machbar ist wenn auch nicht ganz trivial.
Von daher wäre ein umstieg auf Git und SVN richtig aufgesetzt gut und würde eventuell Altlasten beseitigen.
Martin
Deshalb habe ich damals schon geschrieben Portierbarkeit.
http://www.tuxbox-cvs.sourceforge.net/f ... 18&t=47652
Das mit den if def usw ist natürlich unglücklich und der eine oder andere würde das heute vermutlich anders machen warum ist es nicht möglich auf der vorhandenen Wissensbasis etwas neues zu machen was für Devs reizvoll ist was wartbar ist was flexibel ist . Es gibt nun soviel werkzeuge da muss es doch möglich sein mit gewissen Kompromissen da eine Schuh draus zu basteln.
Ich gebe zu das ich nicht soviel davon verstehe um sagen zu können so und so muss man es machen oder würde es gehen. Ich bin nur überzeugt davon das es machbar ist . Kluge Köpfe haben an dem Projekt GCC und Toolchain bewissen was alles machbar ist wenn auch nicht ganz trivial.
Von daher wäre ein umstieg auf Git und SVN richtig aufgesetzt gut und würde eventuell Altlasten beseitigen.
Martin
-
- Developer
- Beiträge: 4189
- Registriert: Sonntag 2. November 2003, 12:36
Re: [Umfrage] CVS-Alternativen: Git, SVN etc...
Nein, das alleine würde keine Altlasten beseitigen. Und für jede Altlast, die man beseitigt kommen mindestens 5 Leute und heulen rum.
Martin, keine Angst, du kriegst schon ein ordentliches Neu-Trino auf deine TD. Dann wirst du das alte vermutlich nicht mehr vermissen
Martin, keine Angst, du kriegst schon ein ordentliches Neu-Trino auf deine TD. Dann wirst du das alte vermutlich nicht mehr vermissen
-
- Developer
- Beiträge: 809
- Registriert: Montag 4. Juli 2005, 17:45
Re: [Umfrage] CVS-Alternativen: Git, SVN etc...
Hallo zusammen,
also ich kenne git nicht (nur CVS und SVN).
Für mich wäre wichtig, dass wir die Unterstützung der verschiedenen Boxen "zusammenfahren" und wenn es zu einem Wechsel kommt, es einen einfachen Weg zu Einarbeitung gibt.
Wir haben bei Tuxbox = CVS, Coolstream = SVN, seife = git.
Für mich macht es die Entwicklung für das yWeb (z.B. auf der Coolstream) schwierig, so dass ich momentan denn neuen Code nicht releasen werde.
Wir reden momentan über das Tools zuerst und aus meiner Sicht noch zu wenig darüber, was wir erreichen wollen.
Weiterhin halte ich es für wichtig, dass die Community den "neuen" Weg mit geht, den wichtiger als ein Tool ist, dass wir nicht weiter Entwickler verlieren.
Falls dies nicht so ist, bitte ich mein mangelndes Wissen hier zu entschuldigen, aber dies ist mein Eindruck.
Gruß
yjogol
also ich kenne git nicht (nur CVS und SVN).
Für mich wäre wichtig, dass wir die Unterstützung der verschiedenen Boxen "zusammenfahren" und wenn es zu einem Wechsel kommt, es einen einfachen Weg zu Einarbeitung gibt.
Wir haben bei Tuxbox = CVS, Coolstream = SVN, seife = git.
Für mich macht es die Entwicklung für das yWeb (z.B. auf der Coolstream) schwierig, so dass ich momentan denn neuen Code nicht releasen werde.
Wir reden momentan über das Tools zuerst und aus meiner Sicht noch zu wenig darüber, was wir erreichen wollen.
Weiterhin halte ich es für wichtig, dass die Community den "neuen" Weg mit geht, den wichtiger als ein Tool ist, dass wir nicht weiter Entwickler verlieren.
Falls dies nicht so ist, bitte ich mein mangelndes Wissen hier zu entschuldigen, aber dies ist mein Eindruck.
Gruß
yjogol
-
- Erleuchteter
- Beiträge: 625
- Registriert: Samstag 8. September 2007, 15:17
Re: [Umfrage] CVS-Alternativen: Git, SVN etc...
Ich sehe es leider nicht das das Tuxbox CVS/GIT/SVN oder wie auch immer, in Zukunft der Hort für ein Neutrino-HD sein wird.
Die Entwicklung von Neutrino-HD findet im Coolstream SVN statt und als Buildsystem dient, mir zumindest, das aus seifes GIT Repo. Soll ja Leute geben die drauf stehen das per Hand zusammen zu schrauben...
http://gitorious.org/neutrino-hd/buildsystem-cs
Ich finde das so auch sehr schön übersichtlich und vermisste das "alte" Buildsystem im Tuxbox CVS auch überhaupt nicht. War fast erschreckend wie simpel sowas sein kann. Ich glaube auch nicht das sich die Coolstream Devs da groß auf Experimente einlassen werden die für eine echte Zusammenarbeit nötig wären.
Sicherlich wäre schön das weitere Plugins aus dem CVS mal auf der Coolstream oder anderen Plattformen laufen, aber wie soll man da am besten vorgehen ohne alles noch mehr zu verkomplizieren?
Die Entwicklung von Neutrino-HD findet im Coolstream SVN statt und als Buildsystem dient, mir zumindest, das aus seifes GIT Repo. Soll ja Leute geben die drauf stehen das per Hand zusammen zu schrauben...
http://gitorious.org/neutrino-hd/buildsystem-cs
Ich finde das so auch sehr schön übersichtlich und vermisste das "alte" Buildsystem im Tuxbox CVS auch überhaupt nicht. War fast erschreckend wie simpel sowas sein kann. Ich glaube auch nicht das sich die Coolstream Devs da groß auf Experimente einlassen werden die für eine echte Zusammenarbeit nötig wären.
Sicherlich wäre schön das weitere Plugins aus dem CVS mal auf der Coolstream oder anderen Plattformen laufen, aber wie soll man da am besten vorgehen ohne alles noch mehr zu verkomplizieren?