Vorlage:Auschecken
Der Tuxbox Quellcode wird derzeit bei Sourceforge bereitgestellt. Dort befinden sich die Hauptentwicklungszweige des Projektes in Form von 5 Git-Repositries
Die Struktur der momentan verfügbaren Repositories, entspricht in etwa der Modulstruktur, wie man sie vor Umstellung von CVS auf Git kannte, wobei es noch zu diversen Anpassungen kommen dürfte. Welche Art diese Anpassungen sind, ist noch nicht vollständig geklärt. Weitere Hintergründe dazu im Tuxbox-Forum.
Als Normalbenutzer werden die Quellen anonym "ausgecheckt", was bedeutet, dass diese auf die eigene Festplatte kopiert werden, indem man zuerst auf einer (lokalen) Festplatte mit "ordentlich" freiem Platz ein leeres Verzeichnis erstellt, z.B. /tuxbox-cvs und in diesen Ordner wechselt, und diese Befehle oder auch Scripte dort ausführt.
Inhaltsverzeichnis
Klonen der Repositories
- Erzeuge ein Verzeichnis tuxbox-cvs und wechsle in dieses Verzeichnis:
mkdir tuxbox-cvs
cd tuxbox-cvs
Klonen
Die Methoden zum Klonen unterscheiden sich etwas gegenüber der für den normalen Gebrauch, da man nur lesenden Zugriff auf die Quellen benötigt und keine direkten Änderungen upstream vornehmen möchte. Eine Erstellung eines Patches ist jederzeit möglich! Der Zugriff für Developer unterschiedet sich nur in der Art des Zugriffs, bei Sourceforce wird dies über einen SSH Zugriff ermöglicht.
Benutzer | Developer |
---|---|
REPLIST="apps boot cdk driver hostapps sandbox"
for f in $REPLIST ; do
git clone git://git.code.sf.net/p/tuxbox-cvs/$f $f
done Dies geht auch über http: REPLIST="apps boot cdk driver hostapps sandbox"
for f in $REPLIST ; do
git clone http://git.code.sf.net/p/tuxbox-cvs/$f $f
done |
REPLIST="apps boot cdk driver hostapps sandbox"
for f in $REPLIST ; do
git clone ssh://[user_name]@git.code.sf.net/p/tuxbox-cvs/$f $f
done |
Nach dem Klonen befinden sich 5 Repos in ../tuxbox-cvs
Auf einen Branch wechseln
Standardmäßig wird automatisch nach dem Klonen auf den Master-Branch gewechselt. Möchte man aber z.B. den dreambox-Branch wechseln, welcher bisher nur im Remote Repository vorhanden ist, wird dieser so ausgecheckt:
$ git checkout -b dreambox origin/dreambox
Branch dreambox set up to track remote branch dreambox from origin.
Switched to a new branch 'dreambox'
Klonen mit Vorbereitung zum Bearbeiten der Sourcen
Wer (intensiv) Änderungen am Quellcode vornehmen möchte, legt üblicherweise einen lokalen Zweig (Branch) an, auf dem man arbeitet. Auch dies kann man vorab schon beim Klonen erledigen und einen lokalen Zweig namens [USERNAME]_local anlegen und darauf wechseln. Der Master-Branch ist zur Bearbeitung prinzipiell Tabu, siehe auch: Development:Git Workflow.
REPLIST="apps boot cdk driver hostapps sandbox"
for f in $REPLIST ; do
git clone git://git.code.sf.net/p/tuxbox-cvs/$f $f
cd $f
git checkout -b `logname`_local
cd ..
done
Nur um es sinnbildlich zu verdeutlichen, entspricht nun dieser lokale Zweig im Kontext zur früheren Arbeitsweise mit CVS als nicht verteiltes VCS, dem frisch ausgecheckteten Stand vom CVS-Server, mit dem man arbeitet. Der Master-Branch schlußfolglich wäre Quasi der CVS-Server, auf dem man für gewöhnlich keinen Schreibzugriff hat.
Abgleichen des lokalen Standes mit dem Remote Repositories
Für alle Repos können diese Scripte zum Updaten verwendet werden.
Einfaches Abgleichen ohne vorhandene lokale Änderungen
# this will update all repos in your clone directory
# change to the directory that contains all repositories and execute this script
# ensure that you have changed to branch 'master' !
CVSREPOS="apps boot cdk driver hostapps"
DIR=`pwd`
REPLIST="$CVSREPOS"
GITPULL="git pull --rebase origin master"
#pull all
for f in $REPLIST ; do
cd $DIR/$f
$GITPULL
cd ..
done
Abgleichen bei vorhandenen lokale Änderungen
Wenn Änderungen vorhanden sind, die noch nicht comittet wurden, wird sich GIT mit Sicherheit beschweren und verlangen, dass man dies erst machen soll. Abgeschlossene Änderungen sollte man natürlich comitten, aber wenn es notwendig ist, hilft es auch die Änderungen kurz "zu parken". Hier besteht die Möglichkeit mit git stash, seine Änderungen vorübergehend "wegzulegen" und mit git stash pop wieder einzupflegen.
Git kann lokale Änderung in der Regel recht gut mit dem Remote-Stand mergen, jedoch kann es trotzdem zu Konflikten kommen. Diese müssen dann natürlich von Hand aufgelöst werden.
REPLIST="apps boot cdk driver hostapps"
DIR=`pwd`
GITPULL="git pull --rebase origin master"
#pull all
for f in $REPLIST ; do
cd $DIR/$f
git stash
$GITPULL
git stash pop
cd ..
done