4,400
edits
FlightGear Git: splitting FGData: Difference between revisions
Jump to navigation
Jump to search
m
FlightGear Git: splitting FGData (view source)
Revision as of 13:22, 26 February 2012
, 26 February 2012Robot: Automated text replacement (-aircaft +aircraft)
m (Robot: Automated text replacement (-aircaft +aircraft)) |
|||
| Line 34: | Line 34: | ||
** Clone the repository from a faster mirror, such as the mapserver. | ** Clone the repository from a faster mirror, such as the mapserver. | ||
It should further be noticed that git's merging and update algoritms are sufficiently efficient to deal with our ever increasing repository, so no immediate problems are to be expected in this area. Given these considerations, it appears that there are sufficient alternatives to circumvent the initial clone problem, and that the size of the git repository as such poses no immediate problem. That said, there are a number of additional reasons that make it desireable to split the fgdata repository in smaller, more manageable chunks. Splitting off the aircraft directory from the rest is a logical first step, and the main question is how to proceed with this. There are a number of possible alternatives: 1) Split off all aircraft and keep then all in a single, but separate repository. 2) Move each aircraft to its own repository, and 3), organize aircraft by logical units. Here are the advantages and disadvantages of keeping all | It should further be noticed that git's merging and update algoritms are sufficiently efficient to deal with our ever increasing repository, so no immediate problems are to be expected in this area. Given these considerations, it appears that there are sufficient alternatives to circumvent the initial clone problem, and that the size of the git repository as such poses no immediate problem. That said, there are a number of additional reasons that make it desireable to split the fgdata repository in smaller, more manageable chunks. Splitting off the aircraft directory from the rest is a logical first step, and the main question is how to proceed with this. There are a number of possible alternatives: 1) Split off all aircraft and keep then all in a single, but separate repository. 2) Move each aircraft to its own repository, and 3), organize aircraft by logical units. Here are the advantages and disadvantages of keeping all aircraft in a single repository: | ||
=== Keeping all aircraft under a single project === | === Keeping all aircraft under a single project === | ||