AW: [Allegro] Argumente fuer git

[Klaus Lehmann]

On Sat, 21 Aug 2010 12:22:52 +0200 Fischer, Thomas wrote:
<>Hallo Herr Eger,
<>
<>soweit ich sehe, treffen die ersten vier Punkte auch auf Subversion
zu (bei 4 lokale Version 'Working Copy' statt clone).

tach an alle, 
ich bin dafür bei svn zu bleiben!
himmel, was spricht dafür, unbedingt die pferde zu wechseln?
svn ist sogar von eines apache's subprojekten. es kann einem doch
nichts besseres passieren, wenn man einen apache-server hat. 
bitte, bitte bei svn bleiben.


dennoch info: 
git-svn - Git tools for importing Subversion repositories
Version: 1.6.0.2-7.28.37
Authors: Linus Torvalds , Junio C Hamano

anderes info:
zu svn gibt es ein dt.sprachiges(!) buch: versionskontrolle mit
subversion (o'reilly-verlag), liegt mir vor.


gruß klaus lehmann


<>Und da bleibt bei mir die Frage, ob wir mit svn zu wenige oder mit
git zu viele Möglichkeiten haben, die ich beim jetzigen Stand meines
Wissen nicht entscheiden kann; hinzu kommt, dass die Struktur der
Entwicklung von Allegro ja auch noch nicht klar ist.
<>Interessant wäre vielleicht noch, ob man mit svn starten und dann
relativ einfach auf git umsteigen kann, wenn man an etwaige Grenzen
stößt.
<>
<>Mit freundlichen Grüßen
<>Thomas Fischer
<>
<>________________________________________
<>Von: allegro-bounces at biblio.tu-bs.de
[allegro-bounces at biblio.tu-bs.de] im Auftrag von Anando Eger
[a.eger at aneg-dv.de]
<>Gesendet: Samstag, 21. August 2010 10:43
<>An: Allegro-C Diskussionsliste
<>Betreff: [Allegro] Argumente fuer git
<>
<>Hallo Herr Fischer,
<>
<>ich denke, dass man nicht alle Funktionen nutzen muss,
<>die es gibt. Wenn man sich auf das benötigte einschränkt,
<>bleibt es für den Anf(a|ä)ng[er] übersichtlich.
<>
<>Ich finde an 'git' positiv, dass
<>- eine erfahrene Entwicklergruppe dahintersteht,
<>- dass die Integration in die M$-Entwicklungsumgebung
<>  gut gelöst ist
<>- dass es relativ unkompliziert zu verwalten ist
<>- dass man sich unkompliziert einen privaten clone anlegen kann
<>  (mindestens zum Probieren gut)
<>- und: vieleicht braucht man eine der vielen Funktionen
<>  doch einmal - warum soll man sich von vornherein
<>  beschränken?
<>
<>Viele Grüße
<>Anando Eger
<>
<>---------------------------------------------------------------------
<>Anando Eger Datenverarbeitung
<>Herr Dipl.-Ing. Anando Eger
<>Gustav-Voigt-Str. 24
<>01156 Dresden
<>Tel.: +49 (0)351 454 1236  http://www.aneg-dv.de
<>Fax: +49 (0)351 454 1238  mailto:a.eger at aneg-dv.de
<>---------------------------------------------------------------------
<>
<>
<>On 20 Aug 2010 at 15:49, Fischer, Thomas wrote:
<>
<>> Hallo Herr Eger,
<>>
<>> ja, das GitX, dass es dort gibt, sieht recht gut aus, gefällt mir
auch etwas besser als das SmartGit, auf das Herr Lehmann hingewiesen
hat, schönen Dank.
<>> Allerdings ist mir noch immer nicht klar, ob die zusätzliche
Komplexität, die wir uns mit git gegenüber svn einhandeln würden, zu
irgendetwas nutze ist.
<>> Meine Entwicklungsvorstellung ist immer noch, dass es im
wesentlichen einzelne Produkte (A99, avanti, acon,...) gibt, an denen
alle gemeinsam arbeiten, und da kommt mir die eher lineare Struktur von
svn ganz passend vor.
<>>
<>> Mit freundlichen Grüßen
<>> Thomas Fischer
<>>
<>> > -----Ursprüngliche Nachricht-----
<>> > Von: allegro-bounces at biblio.tu-bs.de
<>> > [mailto:allegro-bounces at biblio.tu-bs.de] Im Auftrag von Anando
Eger
<>> > Gesendet: Freitag, 20. August 2010 14:46
<>> > An: Allegro-C Diskussionsliste
<>> > Betreff: Re: [Allegro] Soll a99a das Hauptprogramm werden?
<>> >
<>> > Liebe Versionskontrollsysteminteressierten,
<>> >
<>> > Herr Fischer meinte, es gäbe nichts für'n MAC:
<>> >
<>> > http://git-scm.com/tools
<>> >
<>> > Geht das nicht?
<>> >
<>> > Viele Grüße
<>> > Anando Eger
<>> >
<>> >
<>> >
<>> > On 19 Aug 2010 at 12:51, Bernhard Eversberg wrote:
<>> >
<>> > > Thomas Berger schrieb:
<>> > > >
<>> > > > Ich halte speziell git inzwischen fuer absolut ungeeignet im
<>> > > > allegro-Zusammenhang: Das Nutzungszenario passt nicht
<>> > wirklich und
<>> > > > es handelt sich um reine Unix-Tools, ...
<>> > > OK, das sind Argumente. Die Würfel sind ja noch nicht
<>> > gefallen, noch
<>> > > nichts ist installiert.
<>> > > Denkbar ist schon, bei SVN zu bleiben, wenn es denn auf der
neuen
<>> > > Plattform entscheidend schneller ist beim Browsing.
<>> > >
<>> > > >
<>> > > > Bei Git hat jeder Entwickler eine volle Kopie des
<>> > Repositories (als
<>> > > > die komplette Versionshistory) auf seiner Platte
<>> > > Es wird sich aber nicht um ein einzelnes Giga-Projekt
<>> > handeln, in dem
<>> > > schlichweg ALLES drin ist, sondern es wird z.B. für das
Programm
<>> > > avanti ein eigenes geben, in dem nur dessen Dateien sind - denn
die
<>> > > haben mit dem Rest nichts gemein. Ferner wird es getrennte
<>> > > Repositorien für die Klassenbibliothek und die Indexroutinen
geben,
<>> > > die man für eigene Sachen dann heranzieht oder eben nicht
braucht.
<>> > >
<>> > >  > ... ich erinnere
<>> > > > mich an Beschwerden hier im Umfeld, die bemaengelten,
<>> > dass SVN wegen
<>> > > > seiner lokalen Kopie des Checkout-Zustands (und nicht der
ganzen
<>> > > > History) doppelt so viel Platz "wie noetig" verbrate...
<>> > > >
<>> > > Womit ich sympathisieren kann; Verschwendung muß man auch so
nennen
<>> > > dürfen. Zu der "history" kann ich nur sagen, daß ich darauf
<>> > so gut wie
<>> > > nie zurückgreife und keinen Fall erinnere, wo ich sie mal echt
<>> > > gebraucht hätte. Das mag total subjektiv sein und jeder mag das
auf
<>> > > seine Weise ganz und gänzlich anders sehen, aber es ist
<>> > immerhin nicht
<>> > > verschwenderisch. Andererseits, klar, wer die Geschichte
<>> > nicht kennt,
<>> > > ist verurteilt, sie zu wiederholen, und weil's Gigabytes ja für
lau
<>> > > gibt, soll, wer's denn will, die History haben. Halten wir uns
doch
<>> > > nicht auf mit Nebenaspekten, solange sie keine Arbeit machen
(auf's
<>> > > Ganze gesehen der teuerste Faktor, das ist doch der Punkt.)
<>> > >
<>> > > > Ich halte SVN oder Mercurial fuer Alternativen, dafuer
<>> > muesste man
<>> > > > aber primaer ventilieren, welches Entwicklungsmodell fuer
allegro
<>> > > > die Zukunft birgt.
<>> > > >
<>> > > Das ist natürlich ein Hauptaspekt.
<>> > > Was für eins wäre Ihnen am meisten sympathisch? Wir wollen
nichts
<>> > > aufoktroyieren, sondern bedarfsoptimal agieren.
<>> > >
<>> > > B.E.
<>> > >
<>> >
<>> >
<>> > _______________________________________________
<>> > Allegro mailing list
<>> > Allegro at biblio.tu-bs.de
<>> > http://sun250.biblio.etc.tu-bs.de/mailman/listinfo/allegro
<>> >
<>> _______________________________________________
<>> Allegro mailing list
<>> Allegro at biblio.tu-bs.de
<>> http://sun250.biblio.etc.tu-bs.de/mailman/listinfo/allegro
<>
<>
<>_______________________________________________
<>Allegro mailing list
<>Allegro at biblio.tu-bs.de
<>http://sun250.biblio.etc.tu-bs.de/mailman/listinfo/allegro
<>_______________________________________________
<>Allegro mailing list
<>Allegro at biblio.tu-bs.de
<>http://sun250.biblio.etc.tu-bs.de/mailman/listinfo/allegro
<>
<>
<>

-- 
Klaus Lehmann
eMail:  allegronet at t-online.de
phone:  03528-452 807(fax 809); mobil 0171-953 7843
adress: allegronet.de Klaus Lehmann
D-01454 Radeberg; Kleinwolmsdorfer Str. 37
http://allegronet.de

Die allegro-Werkstatt mit allegronetOA
Internetkataloge & WebHosting für AllegroC
Praesent auf allen jaehrlichen Fachkongressen
Dave Lester: New Freedom Data Center,1995:
"Our best ideas are born at home"
** 2009: allegro-utf8 für alle Sprachen dieser Welt**
** 2010: Es wird Zeit für einen Wechsel!**