SVN oder GIT

Git.

Es ist ein bisschen knifflig in git reinzukommen, aber es ist einfach 
viel durchdachter und moderner als svn und auf lange Sicht sicherlich 
die bessere Wahl. Insbesondere stört an svn diese total fehlgeleitete 
Design-Entscheidung, dass "commit" und "push" dasselbe sind... wie 
falsch das ist, merkt man erst, wenn man von svn auf git wechselt und 
eine Weile damit arbeitet ;)

bobberjahn schrieb:
> In der Vergangenheit habe ich viel mit SVN gearbeitet und kenne es
> daher.

> Zu beachten ist auch, dass ich der einzige im Team bin, der schonmal mit
> Versionskontrollen gearbeitet hat,

Dann nimm SVN. So hat wenigstens einer den Durchblick und kann den
anderen den Weg weisen. Man kann zwar auch Git so verwenden wie SVN,
dann hat man aber keine Vorteile. Und um die Vorteile von Git wirklich
zu nutzen, sollte wenigstens einer schon einmal ein Projekt damit
gemacht haben. Oder er sollte eine Woche Zeit bekommen, sich außerhalb
des eigentlichen Projekts mit der Sache intensiv auseinanderzusetzen.

> Unterschiede, die GIT gegenueber SVN aufweist habe ich folgende gehoert:
> - dezentrailisiert: GIT can ohne Serververbindung comitten, mergen

Das ist vor allem dann ein großer Vorteil, wenn die Software nicht nur
inhouse entwickelt wird, sondern auch vor Ort beim Kunden Änderungen
vorgenommen werden.

> - Mergen soll viel einfacher sein (paralleles Arbeiten am Code, also
> mergen, sollte nicht soo oft vorkommen)

Nicht unbedingt einfacher, aber es gibt mehr Möglichkeiten. Das ist vor
allem dann von Bedeutung, wenn man mit stark verzweigten Repositories
arbeitet.

> - Komplizierter zu bedienen als SVN

Um das Gleiche zu tun wie mit SVN, ist die Bedienung ähnlich einfach,
oft heißen sogar die Befehle gleich. Manche Dinge gehen mit Git sogar
etwas einfacher, bspw. das Anlegen von Branches.

> Ausserdem sollen dort Eagle Layouts und Visual Studio Code gespeichert
> werden. Gerade bei Eagle waeren Erfahrungen mit Versionskontrollen
> hilfreich, da habe ich keine.

Verteiltes Entwickeln macht bei Eagle-Layouts und -Schaltplänen wenig
Sinn, da nicht vernünftig gemerget werden kann, es sei denn, du hast ein
Merge-Tool für Eagle-Dateien. Der Nutzen von SVN oder Git beschränkt
sich hier also darauf, eine (lineare) Chronologie der einzelnen
Entwicklungsstände zu haben und diese zentral auf einem Server zu
halten.

... schrieb:
> Vergleich einfach mal die Clients für GIT und SVN. Das ist viel
> wichtiger als das ein oder andere kleine feature. Tortoise SVN als SVN
> Client für Windows ist sehr schön.

Erstaunlicherweise setzt unterdessen sogar MS auf git...

http://visualstudiogallery.msdn.microsoft.com/abafc7d6-dcaa-40f4-8a5e-d6724bdb980c

Trotzdem: Wenn du SVN kennst nimm SVN, du kannst noch immer später auf 
GIT wechseln falls nötig. (laut deiner Beschreibung wird dir GIT keine 
grossen Vorteile bringen)


mfg Andreas

Ppp schrieb:
> Richtig, GIT ist in Mode gekommen.

Richtig.

> Mehr ist an GIT auch nicht dran,

Falsch.

Es würde kein Aufwand in die Entwicklung von Git gesteckt werden, wenn
SVN genau die gleichen Möglichkeiten bieten würde.

> außer dass sich ein paar Nerds über Funktionen ereifern, die die Welt
> nicht braucht - wenn man nicht gerade einen Kernel baut.

Der Linux-Kernel war zwar der Anlass für die Entwicklung von Git, das
heißt aber nicht, dass dessen Vorteile nur bei der Entwicklung von
Linux-Kernels in Erscheinung treten. Ein großer Schwerpunkt bei Git
liegt sicher in der dezentralen Entwicklung, die bei kleineren Software-
firmen nicht so stark ausgeprägt sein mag.

Dezentralität kann aber auch anders aussehen:

Ein Beispiel habe ich oben schon genannt: Ich gehe zum Kunden, um vor
Ort etwas in Betrieb zu nehmen. Dann habe ich automatisch sämtliche
bisherige Versionen der Software mit dabei und kann nach Belieben neue
Testversionen (d.h. Branches) anlegen, die ich hinterher ohne Probleme
in das Repository auf dem zentralen Server einspielen kann. Ich kann
aber auch problemlos meine Änderungen einem Kollegen überspielen, der
ebenfalls mit unterwegs ist, ohne dass ich dazu den zentralen Server
benötige. Sollte ich am nächsten Tag Urlaub haben, kann der Kollege
seine wie meine Änderungen auf den zentralen Server einspielen.

Ich verwende Git auch gerne in privaten Softwareprojekten, wo ich der
einzige Entwickler bin. Trotzdem arbeite ich mit mindestens drei
Repositories, von denen eins auf dem Desktop-PC, eins auf dem Laptop
(wenn ich am Wochenende woanders bin) und eins auf dem USB-Stick (für
den Datentransport). Mit SVN ist das nicht so einfach, und ich würde
mich wahrscheinlich für ein einzelnes Repository auf dem USB-Stick
entscheiden. So ein USB-Stick geht aber gerne mal verloren, und damit
auch die gesamte Versionsgeschichte, sofern sie nicht regelmäßig
gebackupt wurde. Mit den drei parallelen Git-Repositories kann ich mir
sogar den Backup sparen. Und dafür muss ich nicht einmal undbedingt
einen Git-Server auf einem der Rechner aufsetzen

Alles in allem gesehen bietet mir Git eine unglaubliche Freiheit, weil
ich überall fast alles machen kann und mir keine große Strategie
überlegen muss, an welchem Ort ich ein zentrales Repository halte und
wann ich die einzelnen Repositories untereinander synchronisiere.

bobberjahn schrieb:
> Zur Auswahl
> stehen SVN und GIT.

Ggf. solltest du noch Mercurial (hg) in Erwägung ziehen: ist von den
Ideen her ähnlich wie git (haben gleiche Wurzeln).  Teilweise finde
ich git aber einfach nur willkürlich anders als vorangegangene
VCSe, während hg da gerade von den Begrifflichkeiten noch stärker
an CVS oder SVN anlehnt.  Manche Dinge in git scheinen schon sehr
typisch für die Arbeitsweise der Linux-Kernelentwickler zugeschnitten
worden zu sein.  hg wird übrigens bei OpenSolaris eingesetzt, man
kann also damit durchaus auch eine OS-Entwicklung betreiben. ;-)
(Aber das kann man auch mit CVS oder SVN, schließlich gab es auch
ein Leben vor dem Tod, ähem, vor git.)

Verteilte VCSe haben natürlich auch Nachteile, die man gern ein wenig
unter den Tisch fallen lässt.  Typischerweise schleppt man ein
komplettes Repository pro working copy mit sich rum.  Für größere
Projekte wird das schnell platzhungrig.  Nur so als Vergleich:

CVS: working copy braucht nur wenig mehr, als die eigentlichen Daten
     benötigen

SVN: working copy braucht etwas mehr als doppelt so viel wie die
     eigentlichen Daten, da ein vollständiger Backup des zuletzt
     ausgecheckten Standes mitgeführt wird

git oder hg: working copy braucht Platz für die eigentlichen Daten
     plus die des gesamten Repos

Im Umkehrschluss braucht man bei CVS für praktisch alle Aktionen
einen Zugriff auf den Server.  Bei SVN gehen "diff" und "revert"
lokal, für den Rest braucht man den Server.  Bei git oder hg geht
alles ohne Server, natürlich nur bis zu dem Stand, zu dem man
zuletzt das Repository synchronisiert hat.

Yalu X. schrieb:
> Es würde kein Aufwand in die Entwicklung von Git gesteckt werden, wenn
> SVN genau die gleichen Möglichkeiten bieten würde.

Naja, meines Wissens hat Linus Torvalds lange Zeit keinerlei VCS
für den Linux-Kernel benutzt, während andere Betriebssysteme schon
20 Jahre vorher für sowas eine Notwendigkeit sahen.  Insofern nehme
ich ihm den VCS-Experten nicht ab, als der er von seinen Jüngern
gern dargestellt wird.  Dass verteilte VCSe ihre Vorteile haben,
steht außer Frage, aber dass sie das allein seelig Machende sind,
halte ich für die allermeisten Projekte für an den Haaren herbei
gezogen.

Dafür kann git in wenigen Millisekunden die komplette History auflisten 
oder durchsuchen, oder ohne Netzwerkverbindung sagen wer eine bestimmte 
Zeile zuletzt modifiziert hat. Plus, man kann komplett offline arbeiten, 
wenn man das mal will (zum Beispiel im Zug). Oh, oder der Server geht 
mal nicht -- dann auch. Das klingt nach einer Kleinigkeit, aber wenn man 
mal in der Situation ist, ist es überraschend nützlich. Nach meiner 
persönlichen Meinung wiegt das den Nachteil mit der großen Dateigröße 
locker auf. Für mein Projekt, was History bis zurück zu 2006 und viele 
tausend Commits hat, sind die komplette Repository gerade mal ein paar 
Dutzend MB. Plus, git hat eine --depth Option beim clone, was erlaubt 
auch "shallow" clones einer Repository zu machen, die nicht die 
komplette History enthalten, sondern nur n Commits (von diesen kann 
allerdings unter bestimmten Umständen nicht gepusht werden).
Ein Problem mit der Größe der Repository kriegt man nur dann, wenn man 
"un-diffbare", sich oft ändernde Inhalte versioniert, zum Beispiel den 
aus den Quellen erzeugten Objektcode oder sich häufig ändernde Bilder. 
Das sollte man aber sowieso nicht machen.

Oh, oder dies: Um einem Commit zu machen, muss ich nicht die 
Änderungen der anderen Leute am Repo berücksichtigen. Das heißt, ich 
kann meine Arbeit erstmal sichern, und mich dann in aller Ruhe damit 
beschäftigen, sie mit den Änderungen der anderen zu mergen (indem ich 
erst git commit und dann git pull benutze). Wenn dabei etwas schiefgeht, 
kann ich jederzeit zu dem Punkt zurückkehren, bevor ich die Änderungen 
der anderen mit hineingezogen habe. Bei svn ist das nicht so: Man hat 
irgendetwas fertig und möchte es commiten, und dann hat irgendjemand 
dieselbe Datei geändert, und plötzlich ist der perfekt funktionierende 
Code voller merge conflicts, ehe ich die Chance hatte, ihn durch meinen 
Commit sozusagen abzusegnen (und zu sichern!). Das ist Murks.

Mit git gehe ich meist so vor, wenn ich ein kleineres Feature einbaue:
1) Ich ändere irgendwas am Code.
2) Ich starte git gui (siehe Anhang) und markiere nur einige wenige der 
gemachten Änderungen für einen neuen Commit. Dabei lasse ich zum 
Beispiel eingefügte Debug-Statements weg, und versuche, Kram, der in 
einen Commit kommt, thematisch zu gruppieren.
3) Ich gehe wieder zu 1, solange ich mit dem Endergebnis noch nicht 
zufrieden bin.
4) Bin ich zufrieden, führe ich oft noch git rebase -i aus und sortiere 
Commits um, oder führe mehrere zueinandergehörige zu einem Commit 
zusammen.
5) Erst dann muss ich mich darum kümmern, das ganze mit dem Server zu 
synchronisieren. Oder auch nicht, wenn ich erst noch weiter testen will, 
bevor ich das Ganze mit anderen teile.

Ebenfalls sehr einfach in git und sehr umständlich in svn:
* Schnell mal einen branch erstellen, um etwas auszuprobieren (mit 
Versionierung!), ohne dies mit anderen zu teilen
* Commits zwischen mehreren Branches hin- und herschieben (git merge 
<branch>, git cherry-pick, ...)
* Gerade erst gemachte Commits nochmal schnell ändern (git commit 
--amend, git rebase -i)
* Tags verwalten (git tag)
* Nur einzelne Zeilen oder Chunks für einen Commit verwenden (in git 
kann ich einzelne Zeilen auswählen, die nicht in einem Commit landen 
sollen!)
* Schnell nachsehen, wer und warum eine Zeile zuletzt geändert hat 
(siehe Anhang) (git blame)
* ...

Ich habe jahrelang svn benutzt, und war eigentlich immer ganz zufrieden. 
Dann bin ich irgendwann mehr oder weniger gezwungenermaßen zu git 
gewechselt, und würde um keinen Preis wieder zurückgehen. ;)

Zu hg kann ich keine qualifizierte Meinung äußern, aber ich hab's 
neulich mal ein paar Stunden benutzt, und ehrlich gesagt kam es mir vor 
wie git ohne die ganzen coolen Features ;)
Andere Leute, mit denen ich gesprochen habe, haben diese Meinung 
bestätigt. Zugegebenermaßen waren das aber auch eher git-Anhänger.

Grüße,
Sven

Man kann auch SVN Server haben und auf clientseite (wems gefällt) Git 
verwenden:
http://viget.com/extend/effectively-using-git-with-subversion
Man kann also durchaus auch beide Welten vereinen.

Gerade bei kleinen Teams die in der Regel alle in einem Büro/Firma 
sitzen würde ich erst mal SVN Empfehlen. Wenn die Leute gar keine Ahnung 
haben kann git schon sehr verwirrend und frustrierend sein, auch gibt es 
meist für SVN schon eine Integration in viele Tools für Git wird das mit 
der zeit auch kommen keine Frage...

Rainbow Dash schrieb:
>> Zur Auswahl stehen SVN und GIT.
>
> Git.
>
> http://www.youtube.com/watch?v=4XpnKHJAok8

Naja, das ist ungefähr so, wie wenn du für die Frage "Windows oder
Linux" einen Vortrag von Bill Gates als Entscheidungsgrundlage
nehmen würdest.

Wenn nicht einmal der Autor selbst davon überzeugt wäre, dann wär
das ja wohl ein ganz schlechtes Omen.

Läubi .. schrieb:
> Gerade bei kleinen Teams die in der Regel alle in einem Büro/Firma
> sitzen würde ich erst mal SVN Empfehlen.
Das Problem ist, dass svn einem total die Idee davon kaputt macht, wie 
ein VCS eigentlich funktionieren sollte, und wenn man sich erstmal an 
svn gewöhnt hat, ist es viel schwerer, in git reinzukommen. Da hat 
Torvalds schon recht -- das war auch genau meine Beobachtung, auch ohne 
dass ich das Video gesehen hatte.

> Naja, das ist ungefähr so, wie wenn du für die Frage "Windows oder
> Linux" einen Vortrag von Bill Gates als Entscheidungsgrundlage
> nehmen würdest.
Klar. Trotzdem ist es sicher kein Fehler, sich die Argumente des Autors 
mal anzuhören. ;)
Man kann ja ergänzend noch ein ähnliches Video über svn anschauen.

Grüße,
Sven

Außer branches, tags, staging area, Commits die nur einige Zeilen 
enthalten, getrenntes commit/push, "funktioniert auch wenn der Server 
nicht verfügbar ist", schnelles blame/log, ... ;)
Ok -- es gibt anscheinend echt Leute, die das nicht nutzen, obwohl sie 
es kennen. Ich kann das nicht ganz nachvollziehen, aber ich gebe zu: svn 
ist das einfachere der beiden Systeme. Nur, wie erwähnt, denke ich 
dass die Vereinfachungen den Verlust an Funktionalität nicht aufwiegen.

Ja, jahrelang. Aber verglichen mit dem, was git unter Branches und Tags 
versteht, ist das meiner Meinung nach Murks. ;)
In git ist halt branches echt so einfach:
git branch experimental_feature
git checkout experimental_feature
...
git commit ...
git checkout master
...
Und das ist alles lokal.

Nix mit "svn copy", und so ein branch braucht auch nur wenige Bytes 
Speicher. Ich kann nach einem halben Jahr in dem Branch "git rebase 
master" machen. Ich kann aus dem Branch weitere Branches abzweigen. etc

Tags macht man in svn ja auch mit copy. In git kann man einfach
git tag v1.4.0 HEAD
machen. Das ist wieder eine Operation, die nur wenige Bytes Speicher 
benötigt. Will sagen: git branch / git tag sind zwei Tools, die speziell 
für tags und branches gebaut sind und perfekt funktionieren. Bei svn 
sind das nur irgendwelche Workarounds. Dass es offizielle Workarounds 
sind, macht die Sache nicht besser.

Wofür ich das branch feature zum Beispiel oft nutze, ist um irgendein 
Feature zu bauen, von dem ich nicht weiß, ob es funktionieren wird, oder 
ob es vielleicht Quatsch ist. Sowas will ich nicht als Kopie der 
Repository auf dem Server haben.

Grüße,
Sven

Sven B. schrieb:
> Ich kann nach einem halben Jahr in dem Branch "git rebase
> master" machen.

Aber eben auch nur, wenn die beiden nicht gerade grundlegend
auseinandergelaufen sind.  Solange es keine Konflikte gibt, ist
ein Merge (rebase, wie auch immer) immer recht einfach.

Allerdings ist es richtig, Branches in git oder hg sind sehr viel
leichtgewichtiger als in CVS oder SVN.  Andererseits kann man für
lokale Experimente immer noch über eine SVN working copy ein git
oder hg lokal drüberlegen. ;-)  Für die genannten Dinge (lokale
Branches, lokale Commits) ist es ja völlig unabhängig, welches VCS
dann auf dem zentralen Master läuft.

Jörg Wunsch schrieb:
> Sven B. schrieb:
>> Ich kann nach einem halben Jahr in dem Branch "git rebase
>> master" machen.
>
> Aber eben auch nur, wenn die beiden nicht gerade grundlegend
> auseinandergelaufen sind.  Solange es keine Konflikte gibt, ist
> ein Merge (rebase, wie auch immer) immer recht einfach.
Stimmt, aber das ist ein Problem der Sache an sich und nicht Schuld oder 
Aufgabe des VCS. Was ich damit sagen wollte, git bietet die 
Funktionalität um diesen Prozess so einfach wie möglich zu gestalten, 
nämlich "git rebase master", was ungefähr eine Viertelsekunde dauert.

> Andererseits kann man für
> lokale Experimente immer noch über eine SVN working copy ein git
> oder hg lokal drüberlegen. ;-)  Für die genannten Dinge (lokale
> Branches, lokale Commits) ist es ja völlig unabhängig, welches VCS
> dann auf dem zentralen Master läuft.
Hahaha, das stimmt natürlich, aber ob das so das optimale Modell ist, 
bezweifle ich einfach mal. Ich hab' das auch schon gemacht... aber wenn 
es sich vermeiden lässt, ist es natürlich besser.

Grüße,
Sven

Sven B. schrieb:
> Das Problem ist, dass svn einem total die Idee davon kaputt
> macht, wie ein VCS eigentlich funktionieren sollte
Wer bestimmt eigentlich wie "es" funktionieren sollte? Der "Erfinder" 
von GIT?

Sven B. schrieb:
> Außer ...
Alles schön und gut, aber wenn man es braucht weil man sich irgendwie 
erleuchtet fühlt kann man ja git-svn nutzen, aber wie gesagt wenn eh 
alle im gleichen Haus/Büro sitzen bringt mir das alles nichts, und der 
Verwaltungsoverhead ist auch geringer da eh jeder auf den Zentralen 
Server commiten "muss"...

Sven B. schrieb:
> Ich kann nach einem halben Jahr in dem Branch
> "git rebase master" machen
Wenn nicht zwischenzeitlich die Festplatte/USB Stick o.ä. 
verlorengegangen ist wo dein alleiniger lokaler branch liegt.

Gerade in Firmen ist es einfach nicht so, dass jeder "mal so zum testen" 
rumwerkelt sondern wenn dann arbeitet man oft gemeinsam auf einem Bugfix 
Stand und den will man sowieso zentral haben auf dem Server haben und 
nicht irgendwo auf dem USB Stick des Entwicklers der mit diesem gerade 
im Zug Richtung Süden für einen zweiwöchigen Urlaub sitzt ;-)

Für stark verteilte (z.B. gemeinschaftliche OS Projekte) ist git eine 
gute Sache, für "lokale" Entwicklung bringt es erstmal nur 
Verwaltungsoverhead mit sich und der einzelne Entwickler kann ja mit git 
arbeiten wenn er den unbedingt sich persönlich entfalten will (siehe 
git-svn)...

Sven B. schrieb:
> Hahaha, das stimmt natürlich, aber ob das so das optimale Modell ist,
> bezweifle ich einfach mal.

Hat durchaus auch Vorteile: man muss sich bei den commit messages
nicht weiter große Mühe geben, da sie eben auch nur lokal sind.
Wenn man dann die komplette Änderung zurück zum Master bringt,
"compiliert" man sich daraus eine politisch korrekte commit message
fürs zentrale VCS.

Wenn sich der ganze experimentelle Branch als großer Murks
herausstellt, macht man einfach ein rm -rf .hg (oder .git), und
gut' ist's.

Hi,

Läubi .. schrieb:
> Sven B. schrieb:
>> Das Problem ist, dass svn einem total die Idee davon kaputt
>> macht, wie ein VCS eigentlich funktionieren sollte
> Wer bestimmt eigentlich wie "es" funktionieren sollte? Der "Erfinder"
> von GIT?
Ich bestimme das, weil ich muss es ja schließlich auch benutzen. Du 
kannst natürlich eine andere Meinung davon haben, wie ein VCS 
funktionieren sollte.

> Sven B. schrieb:
>> Außer ...
> Alles schön und gut, aber wenn man es braucht weil man sich irgendwie
> erleuchtet fühlt kann man ja git-svn nutzen, aber wie gesagt wenn eh
> alle im gleichen Haus/Büro sitzen bringt mir das alles nichts, und der
> Verwaltungsoverhead ist auch geringer da eh jeder auf den Zentralen
> Server commiten "muss"...
Mache ich auch, wenn ich mal mit einem svn-Projekt konfrontiert werde. 
Viele gibt es zum Glück nicht mehr. ;)

> Sven B. schrieb:
>> Ich kann nach einem halben Jahr in dem Branch
>> "git rebase master" machen
> Wenn nicht zwischenzeitlich die Festplatte/USB Stick o.ä.
> verlorengegangen ist wo dein alleiniger lokaler branch liegt.
Ich kann den Branch auch problemlos irgendwohin pushen -- andere Leute 
merken nichts davon, wenn sie nicht explizit diesen Branch anfordern.

> Gerade in Firmen ist es einfach nicht so, dass jeder "mal so zum testen"
> rumwerkelt sondern wenn dann arbeitet man oft gemeinsam auf einem Bugfix
> Stand und den will man sowieso zentral haben auf dem Server haben und
> nicht irgendwo auf dem USB Stick des Entwicklers der mit diesem gerade
> im Zug Richtung Süden für einen zweiwöchigen Urlaub sitzt ;-)
Wenn man Code schreibt, ist das -- zumindest bei mir -- immer "mal so 
zum testen". In den meisten Situationen finde ich es schwer, vorher zu 
beurteilen ob das Endergebnis sowohl vom Code als auch von der 
Funktionalität her akzeptabel sein wird, und finde es deshalb von 
Vorteil, den Kram in einem eigenen Branch (ob lokal oder mit irgendeinem 
Server synchronisiert) ausprobieren zu können, ohne andere dabei zu 
stören. Bei Bugfixes ist das natürlich alles etwas einfacher, aber 
Entwicklung an einer Anwendung besteht ja nicht nur aus Bugfixes.

> Für stark verteilte (z.B. gemeinschaftliche OS Projekte) ist git eine
> gute Sache, für "lokale" Entwicklung bringt es erstmal nur
> Verwaltungsoverhead mit sich und der einzelne Entwickler kann ja mit git
> arbeiten wenn er den unbedingt sich persönlich entfalten will (siehe
> git-svn)...
Hm, das verstehe ich nicht ganz? Also meine Projekte fangen immer damit 
an, dass ich einen leeren Ordner anlege und dort "git init" ausführe. In 
den meisten Fällen kommt dann eh nur Murks raus, und ich vergesse das 
Ganze. Wenn's doch was wird, pushe ich die Repository irgendwann auf 
github oder so. Das muss ich mir aber nicht überlegen, bevor ich das 
Projekt beginne -- ich kann alles lokal machen, und dann irgenwann die 
komplette History pushen. Das geht mit svn sicher auch irgendwie, aber 
bei git ist es so entworfen, dass das so funktioniert, und es ist auch 
dementsprechend einfach (nämlich quasi kein Aufwand, zwei Kommandos oder 
so).

Grüße,
Sven

Sven B. schrieb:
> Ich bestimme das, weil ich muss es ja schließlich auch benutzen.

Naja, aber eben deshalb finde ich (private Meinung) das gerangel um ein 
"besseres" oder "richtigeres" VCS quatsch.

Sven B. schrieb:
> In den meisten Fällen kommt dann eh nur Murks raus, und
> ich vergesse das Ganze. Wenn's doch was wird, pushe ich
> die Repository irgendwann auf github oder so
Das ist aber halt meist nicht der Prozess welchen man in einem 
(Firmen-)Team hat. Und so hört es sich beim TE aber an, deswegen sage 
ich ja für verteilte (OS) Projekte ist git sicher das Mittel der Wahl, 
es als Allheillösung oder "besseres SVN/CSV/..." anzupreisen meiner 
Meinung nach aber nicht zielführend.

Hi,

Manchmal unterscheiden sich Meinungen, weil es tatsächlich 
unterschiedliche Meinungen sind. Oft aber unterscheiden sie sich auch, 
weil die Person A mit Meinung A einfach ein paar wichtige Sachen nicht 
verstanden hat, die Person B mit Meinung B weiß. Und wenn Person B der 
Person A diese Sachen erklärt, würde A seine Meinung vielleicht ändern. 
Aus diesem Grund finde ich es nicht unsinnig, über solch ein Thema zu 
diskutieren, auch wenn es im Endeffekt Geschmackssache ist, welches 
VCS man bevorzugt. (Ich möchte damit nicht sagen, dass ich mich mit 
Person B identifiziere)

> Das ist aber halt meist nicht der Prozess welchen man in einem
> (Firmen-)Team hat.
Zum einen kann man git genau so nutzen wie svn: wenn man git commit und 
git push immer zusammen verwendet und branches immer pusht, gibt's da 
nur wenig Unterschiede. Bis darauf, dass git schneller ist.
Zum anderen ... siehe Anfang meines Beitrags. Vielleicht läuft das nur 
so ab, weil es sowieso keine andere Möglichkeit gibt, und vielleicht 
würde es besser funktionieren, wenn es anders wäre. Vielleicht.

Grüße,
Sven

Jörg Wunsch schrieb:
> Andererseits kann man für
> lokale Experimente immer noch über eine SVN working copy ein git
> oder hg lokal drüberlegen. ;-)  Für die genannten Dinge (lokale
> Branches, lokale Commits) ist es ja völlig unabhängig, welches VCS
> dann auf dem zentralen Master läuft.

Wenn die Entwickler in Git so gut eingearbeitet sind, dass sie es
gewinnbringen lokal benutzen können, spricht eigentlich wenig dagegen,
es auch serverseitig zu verwenden. Ja, ich habe deinen Smiley schon
gesehen und liefere deswegen ebenfalls einen ;-)

Bei bobberjahn ist jedoch die Situation die, dass er SVN bereits kann,
Git aber noch nicht. Deswegen habe ich ihm weiter oben vorgeschlagen,
erst einmal bei SVN zu bleiben (auch wenn ich persönlich lieber Git
benutze). Er verzichtet damit zwar auf die tollen Git-Features, aber das
heißt ja nicht, dass man mit SVN nicht ebenfalls produktiv arbeiten kann
(bei Git würde auf Grund der Einarbeitung erst einmal eine unproduktive
Phase entstehen).

Yalu X. schrieb:
> Wenn die Entwickler in Git so gut eingearbeitet sind, dass sie es
> gewinnbringen lokal benutzen können, spricht eigentlich wenig dagegen,
> es auch serverseitig zu verwenden.

Ich schrieb ja "git oder hg".  In meinem Falle komme ich mit git rein
gar nicht zurecht (weil "alles ganz anders ist"), mit hg dagegen sehr
wohl.  (hg wiederum steht dem TE nicht zur Verfügung.)  Außerdem hat
diese Vorgehensweise den Vorteil, dass gewissermaßen SVN der kleinste
gemeinsame Nenner zwischen allen beteiligten Entwicklern ist, aber
diejenigen, die die erweiterten Möglichkeiten eines DVCS nutzen
wollen, das per Overlay trotzdem tun können (ohne dass die anderen
überhaupt was davon merken).

Verstehe ich nicht. Kannst du die Situation mal genauer erklären?

Ja, ok.

Sowas geht mit git tatsächlich nicht, weil es halt als 
Versionierungssystem gedacht ist für Dateien die sich auch tatsächlich 
versionieren lassen -- was bei Word-Dokumenten ohne weiteres nicht der 
Fall ist ;)

Grüße,
Sven

Ich sehe nicht wirklich, warum man das machen muss? Man macht z.B. einen 
Branch für ein stable release und sagt den Leuten "keine Feature-Commits 
in diese Branch". Wenn man ein Release macht, macht man einen Tag dafür, 
dann kann man den Stand bei diesem Tag jederzeit nachsehen.

Das mit dem Schlüssel verstehe ich noch weniger. Wenn der nicht geändert 
werden soll, dann ändert ihn halt niemand. Wo ist das Problem?

Wenn du sowas technisch erzwingen willst, kannst du einen Commit-Hook 
bauen.

Grüße,
Sven

P.S.: Das Wort heißt "lock" ;)

Klabauter schrieb:
> Sinn und Zweck eines VCS ist es ja, die Entwickler im Zaum zu halten.
Da bin ich anderer Meinung. Sinn eines VCS ist, ein möglichst flexibles 
Werkzeug zur Versionierung für den Entwickler zu sein.

> Mündliche Absprachen sollten da eigentlich nicht notwendig sein ;-)
Naja, du kannst doch kein Release einer Anwendung machen, indem du 
deinem VCS sagst "ab jetzt darf keiner mehr in diesen Branch 
schreiben"... wie soll das denn funktionieren. Natürlich müssen sich die 
Entwickler mündlich absprechen, dass sie dann und dann ein Release mit 
den und den Features machen wollen.

> Insofern ist es schon gut, wenn das VCS alles Unerwünschte
> unterbindet...
Unerwünscht, wie zum Beispiel...?
Die Entwickler müssen schon selbst entscheiden, wann sie in einen Branch 
schreiben wollen oder nicht. Wer soll das sonst entscheiden -- der 
Server-Admin? Wieso sollte der das besser wissen als die Entwickler?
Wer nicht will, dass jemand anders dazwischen funkt, kann sich ja selbst 
eine Kopie vom Repo anlegen und nicht pullen -- das ist ja das tolle an 
"verteilt" ;)

> Das mit den Hooks sagt mir jetzt nicht, viel, geht aber vermutlich in
> diese Richtung?
Du kannst ein Skript schreiben, was irgendwelche Checks macht, bevor ein 
Commit vom Server akzeptiert wird, und wenn das Skript nicht zufrieden 
ist, lehnt es den Commit ab. Die KDE-Server akzeptieren zum Beispiel 
keine Commits, die Objektcode enthalten.
Auf die Art ist es natürlich auch möglich, ganze Branches oder Repos zu 
sperren -- oder Dateien.

Grüße,
Sven

chris schrieb:
> Wie sieht es bei GIT aus zwecks looks ?
> Wenn die aktuelle SW ein review gemacht wird, ein Build eingefroren
> werden
> muss, weil es releast wurde und die sourcen so bleiben müssen wie es
> releast
> wurde, usw , wie geht das bei GIT ? Bei SVN lookt man den
> Build/branch/...
> und gut is.
> Auch z.B. Keys, ein Beispiel für Bootloader verschlüsselung, usw,
> sollten nicht änderbar sein. Wie wird das in GIT gemacht ?

Mit Tags.
Tags können im Nachhinein nicht verändert werden.

Zusatz Empfehlung: einen Branch für jedes release, sodass bugfixes genau 
auf dem Branch eingepflegt werden können (und dann ohne probleme auf den 
master/Head/trunk branch gezogen werden können)

bobberjahn schrieb:

> Eingesetzt werden soll das repo zum Speichern von uC Code, der mit MPlab
> generiert wurde. MPLab bietet out of the box SVN support, aber kein Git
> wie ich gesehen habe. Ausserdem sollen dort Eagle Layouts und Visual
> Studio Code gespeichert werden. Gerade bei Eagle waeren Erfahrungen mit
> Versionskontrollen hilfreich, da habe ich keine.

Damit Du Eagle vernünftig mit einer Versionsverwaltung einsetzen kannst, 
ist ein Update auf die Version 6 notwendig. Ab dieser Version werden 
alle Dateien (sch/brd/lbr) als XML abgespeichert und nicht mehr als 
Binärblobs. Das heißt dann auch: Erst ab dieser Version kann eine 
Versionsverwaltung ein richtiges diff machen und bei Änderungen nur die 
Deltas abspeichern anstelle des gesamten Blobs.

Beim Update musst Du darauf achten, dass Du ALLE sch/brd/lbr einmal mit 
Eagle 6 lädst und neu speicherst, um alles als XML vorliegen zu haben.

fchk

Ich arbeite nicht als Software-Entwickler, ich kenne das nur aus der 
Open-Source-Welt ;)

Aber ja, sowas läuft bei git tatsächlich deutlich anders. Das Video von 
Torvalds von weiter oben aus dem Thread behandelt genau diese 
Unterschiede relativ ausführlich. Er beschwert sich auch sehr laut 
darüber, dass es bei CVS & Co immer extra Leute gibt, die sich um das 
Branching kümmern müssen ;)

In git würde halt irgendjemand den Merge von einem Branch vornehmen, und 
zwar lokal -- der Branch müsste dafür dann nicht gesperrt werden, denn 
wenn sich etwas ändert, kann man einfach, nachdem der erste Merge 
abgeschlossen ist, noch einen Merge machen. Der wird dann ja in der 
Regel sehr einfach sein. Git kümmert sich darum, dass nicht dieselben 
Änderungen zweimal gemerged werden.

Grüße,
Sven

Frank K. schrieb:
> Beim Update musst Du darauf achten, dass Du ALLE sch/brd/lbr einmal mit
> Eagle 6 lädst und neu speicherst, um alles als XML vorliegen zu haben.

Wobei natürlich ein Merge von XML-Daten trotzdem noch heikel ist.
Je nach Änderungen kann die Benutzbarkeit des Ergebnisses durchaus
sehr unterschiedlich ausfallen. ;-)  Aber natürlich allemal besser
als reine Binärblobs.

Jörg Wunsch schrieb:
> Frank K. schrieb:
>> Beim Update musst Du darauf achten, dass Du ALLE sch/brd/lbr einmal mit
>> Eagle 6 lädst und neu speicherst, um alles als XML vorliegen zu haben.
>
> Wobei natürlich ein Merge von XML-Daten trotzdem noch heikel ist.
> Je nach Änderungen kann die Benutzbarkeit des Ergebnisses durchaus
> sehr unterschiedlich ausfallen. ;-)  Aber natürlich allemal besser
> als reine Binärblobs.

DANKE für diese Info. Ich hab das jetzt mehrmals hier im Forum gelesen, 
dass das so toll sei, dass EAGLE jetzt in einem menschenlesbaren Format 
abspeichert und man viel besser die SVN Features nutzen kann. Und jedes 
mal habe ich mich beispielsweise gefragt, was passiert, wenn der eine 
ein Bauteil hinzufügt und jemand zweites ein anderes Bauteil einfügt, 
die im Board beispielsweise an die gleiche Position platziert werden. 
Das gibt doch das totale Durcheinander.

Das Problem ist, dass die Merge-Funktionalität zeilenweise arbeitet.
Für XML müsste sie aber auf der Ebene von XML-Elementen arbeiten,
völlig unabhängig davon, ob nun alle XML-Elemente auf einer Zeile
stehen oder "klassisch" eingerückt sind.

Konflikte wie deiner würden natürlich trotzdem nicht erkannt, da
das sich ergebende XML zwar valide ist, aber sinnlos.

Naja, das Zeilen-Problem ließe sich evtl. mit einem Commit Hook lösen, 
der das XML in ein für den Merge passendes Format bringt.

Es bleibt meiner Meinung nach nach wie vor sinnlos, so etwas zu tun. 
Also warum sollte man das XML Problem lösen?

Ich glaube auch nicht, dass es sinnvoll ist, Schaltpläne im XML-Format
auf Textebene zu mergen:

- Dinge, die im Schaltplan logisch eng miteinander verknüpft sind,
  stehen in der XML-Datei nicht unbedingt eng beieinander, so dass
  Konflikte nur schwer erkennbar sind.

- Bei einem gewöhnlichen Quellcode-Merger kann es passieren, dass das
  Merge-Ergebnis so verhunzt ist, dass es von Eagle nicht mehr gelesen
  wird. Man müsste dann die Korrekturen manuell auf XML-Ebene durchfüh-
  ren.

- Auch ein manuelles Mergen auf XML-Ebene ist praktisch unmöglich, da
  die logischen Zusammenhänge der Schaltung aus dem XML-Text praktisch
  überhaupt nicht ersichtlich sind.

Ein spezielles Eagle-Merge-Tool würde diese Probleme prinzipiell lösen,
aber selbst dann ist es für einen Entwickler sehr aufwendig, das Merge-
Ergebnis auf elektrische Korrektheit zu prüfen. Da er nicht weiß, wo
genau die Änderungen gemacht wurden, müsste er nach jdem Merge jedes
Detail der Schaltung aufs Neue überprüfen.

Bei Platinenlayouts wird die Sache noch schwieriger, da dort eine kleine
Änderung (wie bspw. das Verschieben eines Bauteils um 1 mm oder die
Verbreiterung einer Leiterbahn) einen ganzen Rattenschwanz an weiteren
Änderungen (bspw. das Verschieben vieler Leiterbahnen, Vias u.ä. in der
Umgebung) nach sich zieht. Gleichzeitige Änderungen von mehreren
Entwicklern werden deswegen fast immer zum Konflikt führen.

Wesentlich sinnvoller als ein automatischer Merger wäre ein interaktives
Tool, das die Unterschiede zwischen zwei Schaltplänen in einem
grafischen Editor farblich hervorhebt und dem Benutzer die Möglichkeit
bietet, jeden dieser Unterschiede in die neue Version zu übernehmen oder
zu verwerfen. So ein Tool müsste aber wohl erst noch geschrieben werden.

Solange es dieses Tool nicht gibt, ist es am besten, den Schaltplan
(bzw. bei modular aufgebauten Schaltplänen jedes Modul) und das Layout
immer nur ein einem Entwickler gleichzeitig bearbeiten zu lassen. Es ist
die Aufgabe des Projektleiters, jeweils einen geeigneten Entwickler zu
bestimmen, der für eine bestimmte Änderung zuständig ist. Dann muss die
Datei auch nicht gelockt werden.

Oder sowas wie gobby oder Google Docs, was Bearbeiten eines Dokumens von 
mehreren Leuten gleichzeitig erlaubt und die Änderungen der anderen 
Personen sofort darstellt.