mikrocontroller.net

Forum: www.mikrocontroller.net SVN-Server für eure Projekte


Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Seit kurzem gibt es auf Mikrocontroller.net einen SVN-Server. Wer es nicht kennt: SVN (Subversion) ist ein Versionsverwaltungssystem, in dem Sourcecode und sonstige Dateien (z.B. Schaltpläne und Layouts) an einer zentralen Stelle verwaltet werden. Jede Änderung kann kommentiert werden und sämtliche alten Versionen werden archiviert. Dadurch lässt sich einfach der Verlauf der Entwicklung mitverfolgen, was besonders bei Projekten an denen mehrere Entwickler arbeiten nützlich ist.

Der SVN-Server steht allen Benutzern zur Verfügung die ein Open-Source-Projekt starten möchten, egal ob es ein größeres Projekt mit Hard- und Software oder nur eine kleine Bibliothek mit ein paar Funktionen ist. Wer Interesse hat, der kann sich per E-Mail melden um sich das Projekt auf dem Server einrichten zu lassen. Der Zugriff für weitere Benutzer lässt sich dann selbst über ein Webinterface konfigurieren.

Mehr Informationen gibt es im Wiki unter Hilfe: SVN. Eine Liste der aktuell auf dem SVN-Server gehosteten Projekte gibt es hier.


: Verschoben durch Admin
Autor: Olli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wow, cool, vielen Dank schonmal - werde bei Bedarf drauf zurückgreifen!

Autor: M1 T0 (m1t0)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mikrocontroller.net ist eine super Seite, aber in Zeiten von verteilten 
Versionskontrollsystemen noch ein Subversion-Repository aufzusetzen 
solltet ihr nochmal überdenken.

Liebe Grüße MiT0

Autor: zachso (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich findes es wirklich super dass ihr solcen service anbietet, aber 
warum kein git? das waere ein wenig zeitgemaeser gewesen, und man soll 
ja schliesslich mit der zeit gehn... ;) trotzdem vielen dank fuer den 
service! das wird bestimmt anklang finden.

Autor: Michael Haberler (mah)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
zachso schrieb:
> ich findes es wirklich super dass ihr solcen service anbietet, aber
> warum kein git? das waere ein wenig zeitgemaeser gewesen, und man soll
> ja schliesslich mit der zeit gehn... ;) trotzdem vielen dank fuer den
> service! das wird bestimmt anklang finden.

Ich kann mich dem nur anschliessen - ein Versionskontrollsystem ist 
sicher eine Hilfe bei der Suche nach der aktuellen Version und Studium 
der Geschichte von Code. Aber SVN macht mich schreiend davonlaufen, 
insbesonders wenns um kompliziertere Merges geht.

Könntet Ihr das nochmal überdenken? Git + Gitweb wärs gewesen.

Jetzt sind erst drei Projekte drin. Die Migration SVN->Git ist auch 
ziemlich easy.

liebe Grüsse,
Michael

ps: Linus Torvalds zum Thema: Youtube-Video "Tech Talk: Linus Torvalds on git"

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
zachso schrieb:
> das waere ein wenig zeitgemaeser gewesen,

git ist anders, aber warum sollte es zeitgemäßer sein?  Ich
persönlich kann mich damit gar nicht anfreunden, weil ich darin
immer die latente Gefahr sehe, dass jeder sein Süppchen kocht und
alles prima auseinander läuft.

Ob git für die hier in Frage kommenden Projekte eventuell besser
geeignet wäre als SVN, will ich damit nicht in Abrede stellen (dafür
habe ich zu wenig Gefühl für diese Projekte).  Ich bestreite
lediglich den Ausdruck "zeitgemäßer", nur weil sich vielleich dieses
oder jenes prominente Opensource-Projekt nach jahrzehntelanger
Abstinenz von jeglicher Versionsverwaltung mal dafür entschieden hat.

Wenn's unbedingt verteilt sein soll, käme außerdem noch Mercurial
mit ins Spiel.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
RTFM: http://www.mikrocontroller.net/articles/Hilfe:SVN -> "Warum SVN?" 
;)

SVN ist am weitesten verbreitet, wird in vielen Firmen verwendet und ist 
auch unter Windows gut benutzbar. Bei den verteilten Systemen gibt es 
git, Mercurial, Bazaar, darcs, und jeder will was anderes verwenden. Und 
mal ehrlich, wie kompliziert werden die merges bei den Projekten um die 
es hier geht? Das sind keine Linux-Kernel mit tausenden von Dateien und 
dutzenden Branches, das sind Projekte mit ein paar C-Dateien, einem 
Boardlayout oder zwei, und das war's. Da ist git u.ä. völliger Overkill, 
und macht das ganze nur undurchsichtiger, besonders für Benutzer die 
wenig Erfahrung mit Versionskontrollsystemen haben. Wenn sich 
herausstellen sollte dass sich immer mehr Leute für git interessieren, 
und es auch wirklich Gründe gibt das zu nutzen, dann kann man da in 
Zukunft sicher eine Lösung finden. Im Moment halte ich SVN aber für die 
beste Lösung.

Autor: byte (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> ich findes es wirklich super dass ihr solcen service anbietet, aber
> warum kein git? das waere ein wenig zeitgemaeser gewesen, und man soll
> ja schliesslich mit der zeit gehn... ;)

??? SVN ist der nachfolger von CVS. Es wird u.a. auch auf Windows sehr 
gut unterstützt (Tortoise). Und für solche Projekte find ich SVN besser. 
Bei den anderen (Git, Mercurial, etc.) Murxen immer alle kreuz und quer, 
jeder stickt sein eigenes Zeug, und keiner gibts weiter. Leider sind 
Programmmierer teilweise ein sehr eigenbrötlerisches Volk.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Schwarz schrieb:
> Und mal ehrlich, wie kompliziert werden die merges bei den Projekten um
> die es hier geht?

Genau das ist der Punkt. Es geht hier um eine möglichst einfach zu 
bedienende Zugriffsmöglichkeit auf die jeweils aktuelle Version. Sonst 
nichts. Und dafür ist svn das Mittel der Wahl.

> Da ist git u.ä. völliger Overkill,

Overkill? Das glaube ich nun weniger. Git ist für den angepeilten Zweck 
wenig geeignet, weil es gerade kein zentrale Repositorium hat - dessen 
Funktion wird mit Hilfe von Schreibrechten auf öffentlich zugängliche 
Repositorien simuliert, was aber impliziert, daß diese Repositorien 
administriert werden müssen, man also sowas wie Projektleiter braucht.

> und macht das ganze nur undurchsichtiger, besonders für Benutzer die
> wenig Erfahrung mit Versionskontrollsystemen haben.

Nein es würde nur die bisher benutze, unbefiedigende Methode - bei der 
man sich die neuste Version aus irgendwelchen Threads rauspulen mußte - 
"modernisieren", ohne wirklich was daran zu ändern. Gemerged wurde hier 
bisher so gut wie überhaupt nicht und wenn ich es richtig sehe, hat sich 
daran auch so gut wie keiner gestört.

byte schrieb:
> Bei den anderen (Git, Mercurial, etc.) Murxen immer alle kreuz und quer,
> jeder stickt sein eigenes Zeug, und keiner gibts weiter. Leider sind
> Programmmierer teilweise ein sehr eigenbrötlerisches Volk.

Genau, ohne Projektleitung kann das nicht funktionieren.

Also liebe Modernisierer, nicht alles Neue ist gut, nur weil es neu 
ist...

Autor: Marc Prager (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank, Super Service!

Zum Gl"uck gab es nicht nur Stimmen f"ur git und gegen Subversion, wie 
es in den ersten paar Beitr"agen den Anschein hatte. Mit geht's fast 
schon auf den Hammer, wie die Leute hinter einem Linus T. herlaufen ohne 
nachzudenken. Wer svn und git benutzt wird merken, dass bei git nicht 
alles besser ist. Das Modell ist sogar noch komplizierter. Wozu?

Als ich mir git genauer anschaute und f"ur meine mittlerweile recht 
umfangreiche Bibliothek benutzen wollte musste ich feststellen, dass es 
keine Entsprechung zu den 'externals' von Subversion gab. Ich benutze 
als single user die Versionskontrolle um mehrere Architekturen 
(i386,SAM7s,LPC21,LPC23 und LPC17) zu unterst"utzen und maximal viel 
Code gemeinsam nutzen zu k"onnen. Dazu muss ich den Code in viele 
Klassen einteilen wie: C freestanding/C linux/C++/C-LPC21/C-LPC23/...
Da finde ich die externals ein brilliantes Werkzeug und das vor allem 
seit Version 1.6 . Da hat git was nachzuholen!

Gruss Marc

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dieses " macht deinen Text aber nicht besonders viel lesbarer :O

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Simon K. schrieb:
> Dieses " macht deinen Text aber nicht besonders viel lesbarer :O

Vielleicht kann ja sein PDA oder Navi nicht anders... ;-)

...

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hannes Lux schrieb:
> Vielleicht kann ja sein PDA oder Navi nicht anders... ;-)

...oder er hat eine englische Tastatur.  Ist bei manchen old-time-
Hackern recht beliebt.  Das vorangestellte Anführungszeichen ist die
LaTeX-Abkürzung für die Umlaute (braucht man bei LaTeX aber auch
schon 10 Jahre lang nicht mehr).

Autor: Simon Budig (nomis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marc Prager schrieb:
> Als ich mir git genauer anschaute und für meine mittlerweile recht
> umfangreiche Bibliothek benutzen wollte musste ich feststellen, dass es
> keine Entsprechung zu den 'externals' von Subversion gab.

Ich bin nicht 100%ig sicher, ob es eine genaue Entsprechung ist, aber es 
gibt in git das Konzept von "submodules", das mir sehr ähnlich 
erscheint.

An dieser Stelle schließe ich mich auch nochmal den Git-Fans an, wer 
einmal mit einer großen Sourcecodebasis und git gearbeitet hat, weiß es 
zu schätzen, dass git einfach rattenschnell ist, auch bei komplexen 
Operationen. Das bewusste einkalkulieren, dass Entwicklung nicht 
unbedingt immer linear stattfindet macht git manchmal etwas schwer 
zugänglich, ist aber häufig eine große Hilfe. Klar, solange es nur um 
Mini-Projekte geht merkt man das nicht unbedingt, aber bei größeren 
Sachen wundert man sich schon manchmal wie einfach mit Git manchmal 
Dinge gehen, die mit SVN immer wieder gerne mal aufgeschoben werden, 
weil sie so lästig sind...

Viele Grüße,
        Simon

Autor: Tire D. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> SVN ist am weitesten verbreitet, wird in vielen Firmen verwendet und ist
> auch unter Windows gut benutzbar

Sollen das pro oder contra-punkte sein?

> Bei den anderen (Git, Mercurial, etc.) Murxen immer alle kreuz und quer,
> jeder stickt sein eigenes Zeug, und keiner gibts weiter. Leider sind
> Programmmierer teilweise ein sehr eigenbrötlerisches Volk.

Dafür machen es die verteilten systeme auch einfacher branches wieder 
zusammenzuführen.

> Mit geht's fast
> schon auf den Hammer, wie die Leute hinter einem Linus T. herlaufen ohne
> nachzudenken

Ist halt wie damals mit Bill G. und nun mit Steve J. ... Wie Andreas 
schon schrieb ist git wohl eher overkill von daher wär evtl. Tatsächlich 
Mercurial, wegen seiner geringeren komplexität, eine alternative.


@Andreas: trotzdem eine schöne Sache =)
@Rechtschreib/GramatikNazis: geht wo anders spielen

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tire D. schrieb:
> Dafür machen es die verteilten systeme auch einfacher branches wieder
> zusammenzuführen.

...die man allerdings in kleineren Projekten eher selten benötigt.

Autor: Tire D. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> Tire D. schrieb:
>> Dafür machen es die verteilten systeme auch einfacher branches wieder
>> zusammenzuführen.
>
> ...die man allerdings in kleineren Projekten eher selten benötigt.

Naja vielleicht ergibt sich ja aber eine neue kultur was die Projekte 
angeht. Ich meine es ist mit dezentralen Systemen schmerzfreier 'mal 
ebend was zu machen' und dieses evtl. danach in den Trunk einzuführen, 
wodurch die hemmschwelle fallen könnte an dem Projekt teilzuhaben. 
(Denke dadurch entsteht auch dieser besagte Wildwuchs, aber auch ein 
blindes Huhn findet mal ein Korn;))

Grad Mercurial ist ja recht simpel mit seinem einen komando + ein paar 
optionen, wohingegen git da ja genau den anderen ansatz fährt. Aber (ka 
obs wirklich so ist) ich denke da gibts für beide (wenn nicht jetzt 
schon, so doch in absehbarer Zukunft) schicke frontends die einem das 
ganze recht einfach gestalten. Von daher frag ich mich wo der Vorteil 
von SVN liegt.

scnr Aber wahrscheinlich ist das alles auch nur Wunschdenken :)

Autor: joachim7777 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt es hier irgendwo eine Beschreibung wie man genau an die Projekte
rankommt. Ich bekomme hier nur kryptische Fehlermeldungen

Autor: Michael M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Schwarz schrieb:
> Mehr Informationen gibt es im Wiki unter "Hilfe:
> SVN":http://www.mikrocontroller.net/articles/Hilfe:SVN. Eine Liste der
> aktuell auf dem SVN-Server gehosteten Projekte gibt es
> "hier":http://www.mikrocontroller.net/svn/list.

http://www.google.de/search?hl=de&q=subversion

Autor: joachim7777 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sehr witzig, da steht doch überhaupt nix.
"Sie sind nicht dazu berechtigt diese Seite aufzurufen."

Wenn ich versuche z.B. auf svn://mikrocontroller.net/test zuzugreifen
kommt die Meldung:

Can't connect to host 'mikrocontroller.net': Es konnte keine Verbindung
hergestellt werden, da der Zielcomputer die Verbindung verweigerte.


Frage also: Gibt es irgendwo eine einfach Anleitung wie man sich mit
dem Repository verbindet, oder ist das auch so ein krytisches Linuxzeug

MfG

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
joachim7777 schrieb:
> Wenn ich versuche z.B. auf svn://mikrocontroller.net/test zuzugreifen

naja, ich kann zugreifen.

Wie probierst du es denn? Mit dem Browser?

Unter Linux geht es einfach, in der Konsole konnte ich eben mit:
svn co svn://mikrocontroller.net/avr-fat32
testweise ein Projekt holen (svn co... zum Aus{}checken, den Rest
aus der Liste http://www.mikrocontroller.net/svn/list).
Wenn das zu kryptisch ist: was ist einfacher?

joachim7777 schrieb:
> Sehr witzig, da steht doch überhaupt nix.
> "Sie sind nicht dazu berechtigt diese Seite aufzurufen."

Sowohl auf den Link http://www.mikrocontroller.net/articles/Hilfe:SVN
als auch http://www.mikrocontroller.net/svn/list
kann ich problemlos zugreifen.

Autor: joachim7777 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich versuche es mit dem

Windows-Explorer, rechte Maustaste -> TortoiseSVN->Checkout

Wenn ich die Repository-URL svn://.... eingebe kommt die vorher genannte
Meldung

wenn ich die http-Url angebe kommt die Meldung

OPTIONS of 'http://www.mikrocontroller.net/svn/list';: 200 OK

es wird aber nix geladen.

Linux habe ich  leider zuhause nicht, mir reicht es wenn ich mich
mit dem Mist in der Firma beschäftigen muss.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe jetzt mal auf einem Reserve-Windows Tortoise installiert
(nachdem ich sonst nur den Mist nehme).

Dann gehe ich im Explorer auf Check out...., bis dahin scheint es ja bei 
dir zu klappen.

Als URL gebe ich ein:
svn://wwww.mikrocontroller.net/rfm12
oder ein anderes Projekt aus der Liste.
Ggf. den lokalen Pfad anpassen, und es wird geholt und lokal 
gespeichert.

Soweit klappt das bei mir. Wo weicht es genau ab bei dir?

(Dagegen kannst du bei checkout nicht:
http://www.mikrocontroller.net/svn/list
angeben, weil das eine http-URL ist.
Da kann man mit dem Browser hingehen, z.B. Mozilla, firefox oder IE.
Da bekommt man die Liste der Projekte.)

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag:

1. In meinem obigen Beispiel ist ein w zuviel;
es müsste heißen:
Als URL gebe ich ein:
svn://www.mikrocontroller.net/rfm12
...

2. Ich habe mal spaßeshalber die obige URL (mit nur 3 w :-) im
Firefox eingegeben (Version 3.6, unter Windows XP).
Dann bietet er mir gleich Tortoise an als Anwendung, darüber
kann man auch die Dateien holen (man hat in dem folgenden Dialog
mit der Baumansicht des Projekts mit der rechten Maustaste wieder
ein Menü mit "Check out.." drin).

Autor: Hannes Wagner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
also ich hab die ganzen Beiträge sehr interessiert gelesen und frag mich 
nur was die ganzen Diskussion soll? (git <-> svn; und dann wieder linux 
<-> windows)
Ich nutze 4 verschiedene Rechner an 4 verscheidenen Orten mit insgesamt 
3 verschiedenen Betriebssystemen mit all ihren Vor- und Nachteilen. Mich 
würde jetzt nur interessieren, da ich mich mit svn nun mal garnicht 
auskenne, ob ich dann meine hochgeladenen Projekte "passwortschützen" 
kann und von überall dran arbeiten kann? Damit wäre mir schon sehr 
geholfen und ich hätte dann die komplette Entwicklung eines Projektes 
auf einem Fleck und müsste nicht nachträglich alles zusammensuchen bzw. 
immer alles per Mail/USB hin und her schieben.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja, kannst du.

Ob der svn-Server bei mikrocontroller.net jetzt dafür gedacht ist,
daß du selbst deine Projekte als einziger bearbeitest, glaube ich
mal nicht.

Aber ansonsten geht das prima mit svn.
Ich habe ziemlich alles, was für mich auf irgendeinem Rechner
irgendwie relevant ist (Quelltexte, Briefe, Steuererklärungen,
Doku, Adressen, Termine...) inzwischen in svn und kann an jedem
Rechner auf die gleichen Daten zugreifen, gelegentliches
Einchecken und Updaten vorausgesetzt natürlich.
Als svn-Server habe ich einen PC zuhause, der über dyndns
und ssh von außen erreichbar ist, d.h. ich kann notfalls
vom Laptop aus über irgendeinen Internetzugang auf alles
zugreifen. (Das ist aber kaum nötig, weil ich ja vor dem
Weggehen i.d.R. auf dem Laptop ein svn update mache und
dadurch mit dem aktuellen Stand losziehe, daheim ändert bei
mir niemand etwas.)

Mit ssh auf einem Linuxserver halte ich das für hinreichend
sicher.

PS: ich nutze als Clients Linux und Windows, unter Windows
zusammen mit putty wg. der Verschlüsselung über ssh.
Das klappt auch gut.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag: ich schütze i.d.R. nicht die Projekte selbst mit einem
PW oder ähnlichem, sondern die gesamte Verschlüsselung findet
über ssh statt.

ssh dient primär dazu, von einem Rechner auf einen anderen zu
gelangen und dort Kommandos auszuführen, ähnlich wie beim guten
alten telnet, nur halt die Übertragung verschlüsselt und komprimiert.

Um jetzt nur auf einem lokalen Rechner sowohl den svn-Server
zu betreiben und auch dort als Client auszuchecken, würde man das
svn-eigene Protokoll svn angeben und verwenden, also z.B.
holen mit dem Kommando:
svn co svn://svn/meintollesprojekt
, falls man das Projekt als svn/meintollesprojekt angelegt hatte.
Mit GUI-Spielen wie tortoise etc. halt entsprechend.

Läuft auf dem Server gleichzeitig ein ssh-Server, dann kann man
darauf einfach über das Netz zugreifen mit dem Protokoll svn+ssh.
Das würde dann irgendwo im Internet so aussehen:
svn co svn+ssh://meinbenutzername@meinrechner.dyndns.org/svn/meintollesprojekt

Was ich damit sagen will: nicht svn wird das verschlüsseln,
sondern es wird letztlich eine ssh-Verbindung für einen bestimmten
Nutzer aufgebaut, und darin findet die Verschlüsselung statt.

Die meisten Sachen, die ich im svn habe, gehören demnach einfach
zu meinem Benutzernamen.
Gelegentlich kommt es vor, daß ich externe Leute auf einzelne
Teile zugreifen lassen möchte.
Dann richte ich für die einen neuen Benutzer ein (unabhängig
von svn, einfach als Benutzer auf dem Server), packe diesen
in eine eigene Gruppe und nehme mich selbst in diese Gruppe
dazu. Normale Benutzerberechtigungen in Unix halt.
Das Projekt im svn gehört dann diesem neuen Benutzer, der
kann dann auch einfach außen genau auf dieses Projekt zugreifen
und ich natürlich auch, weil ich in der Gruppe bin.
Er kommt dagegen nicht an meine Sachen ran.

---

Hauptvorteil neben dem schönen Abgleichen aller Daten ist für
mich, daß ich genau eine Stelle habe, an der ich Datensicherung
machen muß. Das ist nämlich genau das svn-Repository.

Auf allen Rechner ist nichts wichtiges drauf, was nicht auch
im svn-Repository steht.
Ich mache also regelmäßiges Backup nur auf einem Rechner.

Allerdings sollte man nicht das Repository direkt als Dateien
sichern, sondern einen Dump machen, und diesen sichern.
Sonst läuft man Gefahr, daß der Server irgendwann stirbt und die
Sicherung nur genutzt werden könnte, wieder einen svn-Server
DERSELBEN Version wie der alte damit füttern zu können.
Bei einem Dump im Backup dagegen kann man davon ausgehen, daß
es auch eine neuere svn-Version einspielen kann.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nur zur Info: Es gibt auch TortoiseGit und Mercurial!

Meiner Erfahrung in der Firma ist, dass SVN zu kompliziert für embedded 
Programmierer ist!

Sobald man wegbranched kennt sich keiner mehr aus. Bei git/mercurial 
einfach Repo-Dir kopieren (oder clonen... je nach Geschmack) und passt. 
Vorallem kann man lokal das machen, ohne dass es im Repo aufscheint (z.B 
um schnell mal eine dumme idee auszuprobieren)

IDE Integration in Netbeans/Eclipse (sorry aber Keil/IAR sind keine 
IDEs, sonder maximal mit PN2 zu vergleichen) is brauchbar, also würde 
ich zumindest Git/Mercurial/Bazar einmal RICHTIG ausprobieren bevor ich 
von angeblicher komplexität spreche.

Typischer Workflow von Mercurial/GIT:

Repo anfordern
Repo auschecken
ändern (vielleicht lokale commits um Änderungen verfolgen zu können)
hochladen (push)

änderungen herunter holen (pull)
repo auf neuen stand bringen (update/merge so ähnlich wie in svn)
ändern
push

das wars eigentlich!



Übrigends ich arbeite jetzt in der Firma lokal mit gitSVN. Damit arbeite 
ich lokal mit allen vorteilen von git und veröffentliche auf einem SVN 
ohne dummes reintegrieren von dem man spätestens beim mergen hirnödeme 
bekommt ;)

privat habe ich einen Mercurial server auf einem shared webspace 
laufen... geht wunderbar weil sich mercurial über cgi benutzen lässt 
(bei git habe ich mir das noch nicht angeschaut). Auch ganz nett ;)

Autor: K. J. (theborg0815) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hans schrieb:
> Nur zur Info: Es gibt auch TortoiseGit und Mercurial!
>
> Meiner Erfahrung in der Firma ist, dass SVN zu kompliziert für embedded
> Programmierer ist!
>
> Sobald man wegbranched kennt sich keiner mehr aus. Bei git/mercurial
> einfach Repo-Dir kopieren (oder clonen... je nach Geschmack) und passt.
> Vorallem kann man lokal das machen, ohne dass es im Repo aufscheint (z.B
> um schnell mal eine dumme idee auszuprobieren)
>

Bei SVN ist das nicht anders.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich meinte lokal ausprobieren, aber versioniert....

http://whygitisbetterthanx.com/#svn

naja ist schon zu offtopic -> klinke mich aus... ich kann auf jeden fall 
jedem empfehlen git/mercurial einmal auszuprobieren...

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hans schrieb:
> Ich meinte lokal ausprobieren, aber versioniert....

Was sich dafür auch gut macht ist, mal schnell ein Mercurial-Repo
über eine SVN-Arbeitskopie zu legen.  Da kann man dann lokal
versionieren, und entweder wirft man's hinterher wieder weg, oder
man spielt irgendwann das Ergebnis komplett upstream ins SVN
zurück.

Autor: Johannes S. (demofreak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> Was sich dafür auch gut macht ist, mal schnell ein Mercurial-Repo
> über eine SVN-Arbeitskopie zu legen.

Oder eben wahlweise gleich git zu nehmen. Das kann auch mit dem 
zentralen svn-Repo umgehen und das Ergebnis der lokalen Arbeit dort 
einchecken.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johannes S. schrieb:
> Das kann auch mit dem
> zentralen svn-Repo umgehen und das Ergebnis der lokalen Arbeit dort
> einchecken.

Warum sollte man das wollen?  Wenn ich es auf den Server zurück
schreiben will, kann ich doch allemal den svn-Befehl nehmen.

Der Vorteil des lokalen Overlays ist ja gerade, dass man eine
(temporäre) Versionierung hat (und damit die Möglichkeit, bestimmte
Zwischenschritte zu sichern), ohne alles auf den Server
rüberschieben zu müssen.  Finde ich manchmal praktischer als eine
reine Mercurial-Umgebung, bei der jeder meiner Mini-Commits dann
hinterher dauerhaft im Repo ist.  (Könnte man vermutlich auch mit
einem lokalen Branch lösen, ist aber auch nur Arbeit.  Ein hg init
… lokales Arbeiten … svn commit; rm -rf .hg ist einfacher.)

Was ich an git absolut nicht leiden kann ist der Evangelismus, der
damit zuweilen betrieben wird …

Autor: Johannes S. (demofreak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> Warum sollte man das wollen?  Wenn ich es auf den Server zurück
> schreiben will, kann ich doch allemal den svn-Befehl nehmen.

Du brauchst svn überhaupt nicht dafür, deswegen "sollte man das wollen". 
Man muss sich nicht mit beiden Systemen auseinandersetzen.

> Der Vorteil des lokalen Overlays ist ja gerade, dass man eine
> (temporäre) Versionierung hat (und damit die Möglichkeit, bestimmte
> Zwischenschritte zu sichern), ohne alles auf den Server
> rüberschieben zu müssen.

Genau das tut man ja mit git lokal. Man hat gern auch mehrere Branches, 
entwickelt gleichzeitig an 17 Varianten herum, committed "early and 
often" (so wie man das ja auch tun soll) und schiebt aller Naselang nur 
die Ergebnisse seiner Arbeit ins zentrale svn. Nach einer Weile wird das 
zentrale svn dann von einem zentralen git abgelöst, vertrau mir. :-P

> Finde ich manchmal praktischer als eine
> reine Mercurial-Umgebung, bei der jeder meiner Mini-Commits dann
> hinterher dauerhaft im Repo ist. (Könnte man vermutlich auch mit
> einem lokalen Branch lösen, ist aber auch nur Arbeit.  Ein hg init
> … lokales Arbeiten … svn commit; rm -rf .hg ist einfacher.)

Abgesehen davon, dass das mit git logischerweise ganz genauso 
funktioniert, büsst man dann aber seine eigenen kleinen Commits ein. Ich 
will ja am Projekt weiterarbeiten, vielleicht auch meine angefangenen 
Basteleleien verfolgen und eventuell irgendwann einfließen lassen.
Die Mini-Commits kommen ja im svn gar nicht an, weil man die eben in 
einem der (nur) lokalen Entwicklungs-Branches hat. Die 
Zwischenergebnisse merged/cherry-picked man in den svn-Branch rüber, 
kann sie nach Belieben rebasen und zusammenfassen und committed dann 
nach svn.

> Was ich an git absolut nicht leiden kann ist der Evangelismus, der
> damit zuweilen betrieben wird …

Soll ich dir was sagen? Das ging mir genauso, bis ich mir das mal näher 
angeschaut habe. Was es letzten Endes besser macht als alle anderen 
bisher versuchten Systeme ist das zum Einen diese Flexibilität in jede 
Richtung (es gibt schlicht kein Szenario, welches man nicht irgendwie 
damit darstellen kann, auch ohne das vorher eingeplant haben zu 
müssen) und zum Anderen das Mergen. Das geht derart automatisch, dass 
man überhaupt nicht mehr drüber nachdenkt, an welcher Stelle in welchem 
Branch man an was rumentwickelt, weil man es einfach ohne manuelle 
Nacharbeit zusammenmergen und Commits aus dem einen in einen anderen 
Branch schieben kann.

Inzwischen ist es bei mir anders herum: ich kann absolut nicht leiden, 
wenn geradezu evangelistisch das Festhalten an anderen Systemen 
gepredigt wird, nur weil man damit ja ebenfalls irgendwie zurechtkommt 
bzw. weil man es schon immer so gemacht hat. Das wirkt so ein bisschen 
wie "Früher hatte ich kein Händy, als plötzlich alle eins haben mussten. 
Und jetzt renne ich diesem Hype namens git genauso nicht nach! 
*fußaufstampf*". :-)

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johannes S. schrieb:

>> Warum sollte man das wollen?  Wenn ich es auf den Server zurück
>> schreiben will, kann ich doch allemal den svn-Befehl nehmen.
>
> Du brauchst svn überhaupt nicht dafür, deswegen "sollte man das wollen".
> Man muss sich nicht mit beiden Systemen auseinandersetzen.

Im Moment muss ich mich mit git (fast) gar nicht auseinandersetzen,
und SVN und Mercurial sind (im Gegensatz zu git) "straightforward",
wenn man jahrelang CVS gemacht hat.

> Abgesehen davon, dass das mit git logischerweise ganz genauso
> funktioniert, büsst man dann aber seine eigenen kleinen Commits ein.

Ja, aber das ist, nach dem Ende der Experimentierphase, gewünscht.
Es folgt dann ein "upstream commit", das die kleinen zusammenfasst.
Wenn die Phase noch nicht beendet ist, bleibt es einfach.

> Soll ich dir was sagen? Das ging mir genauso, bis ich mir das mal näher
> angeschaut habe.

Mir umgekehrt: habe mir git angesehen.  Ich komm' damit nicht zurecht.
Ich nehme es nur dort, wo es zwingend nötig ist (weil das Projekt
damit arbeitet).

> ... und zum Anderen das Mergen. Das geht derart automatisch, dass
> man überhaupt nicht mehr drüber nachdenkt, an welcher Stelle in welchem
> Branch man an was rumentwickelt, weil man es einfach ohne manuelle
> Nacharbeit zusammenmergen und Commits aus dem einen in einen anderen
> Branch schieben kann.

Mergen ohne Konflikte ging schon unter CVS ganz automagisch.  Haarig
wird es immer nur, wenn Konflikte auftreten.  Wenn nun in zwei
Branches völlig widersprüchliche Dinge passiert sind an der gleichen
Stelle, dann musst du zwangsläufig manuell 'ran, das ist bei
Mercurial oder git nicht anders.  Wenn der eine Branch etwas löscht,
was der andere Branch in der Zwischenzeit geändert hat, wie soll
das Tool entscheiden, welche der beiden Modifikationen überleben
muss?

Aber lass uns das lieber in "PC-Programmierung" diskutieren.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.