FlightGear Git: splitting FGData: Difference between revisions
mNo edit summary |
|||
Line 11: | Line 11: | ||
*** Might be fixed by using Git submodules.<ref>[http://book.git-scm.com/5_submodules.html Git Community Book: Submoduldes]</ref> | *** Might be fixed by using Git submodules.<ref>[http://book.git-scm.com/5_submodules.html Git Community Book: Submoduldes]</ref> | ||
** How to deal with licences? Until now there was a COPYING file in fgdata. When aircraft are split in seperate repositories, they'll likely need to include a license reference themselves. | ** How to deal with licences? Until now there was a COPYING file in fgdata. When aircraft are split in seperate repositories, they'll likely need to include a license reference themselves. | ||
** Need a concept for release management, maintaining version numbers, release branches et. al. | |||
== Starting new aircraft == | == Starting new aircraft == |
Revision as of 18:33, 16 October 2011
Aircraft are split to seperate Git repositories, under the FlightGear Aircraft project at Gitorious.
Reasons to split fgdata
- Advantages
- Aircraft authors can get commit access to their own aircraft, without granting them global fgdata access.
- When pulling fgdata, one won't have to download several gigs of aircraft data. People will have to pull the base package, but any additional aircraft will be optional.
- It will be easier for aircraft authors to check the history of their aircraft.
- Commiting will go faster, because Git will no longer have to check those thousands of files to see whether they were edited.
- Disadvantages
- It will be harder to keep a local up to date copy of all aircraft. No more "git pull" to fetch all the latest updates.
- Might be fixed by using Git submodules.[1]
- How to deal with licences? Until now there was a COPYING file in fgdata. When aircraft are split in seperate repositories, they'll likely need to include a license reference themselves.
- Need a concept for release management, maintaining version numbers, release branches et. al.
- It will be harder to keep a local up to date copy of all aircraft. No more "git pull" to fetch all the latest updates.
Starting new aircraft
New aircraft should not be commited to fgdata. A seperate repository should be created instead. Contact a FlightGear Aircraft admin to get your repository included in the FlightGear Aircraft project. You, as author, will get full admin rights for that repository.
The current fgdata developers will have access to every single aircraft repository. In order to maintain aircraft that no longer have an active author, fix global bugs etc. Other users can create merge requests to get their fixes/improvements commited.
Step 1: Split aircraft into seperate repositories
- You need to have up-to-date fgdata to do this.
- Expect one aircraft to take 5-30 minutes (depending on the filesizes, number of commits (date of last commit?) etc.).
- You need access to the FlightGear Aircraft project. However, for testing you can always push to your own repository.
There are two workflows that both do the trick:
Method 1
Note: the split branch (737-300-split in this example) must NOT exist beforehand.
cd $FG_ROOT git subtree split -P Aircraft/737-300 -b 737-300-split mkdir -p ../split-aircraft/737-300 cd ../split-aircraft/737-300 git init git fetch $FG_ROOT 737-300-split git checkout -b master FETCH_HEAD git push git@gitorious.org:flightgear-aircraft/737-300.git master
Method 2
(need to check this one)
cd fgdata git clone --no-hardlinks /fgdata /737-300 git filter-branch --subdirectory-filter Aircraft/737-300 HEAD -- --all git reset --hard rm -rf .git/refs/original/ git reflog expire --expire=now --all git gc --aggressive --prune=now
Step 2: Remove all aircraft from fgdata
Fgdata will be renamed, so we can keep it for some time until we're sure everything is safe. We can then put the "new" fgdata (without all the aircraft data) up.
References |