> So you are calling for git monkeys that take care of the "tedious"
> process of getting changes into the tree?
If it is as critical to do this right as you say, everyone might be better off
if only people who know what they're doing handle commits and every other
commit goes through them, ra
Hi Thorsten,
Renk Thorsten wrote:
>> Every fgdata contributor who creates complicated xml/shader files should
>> be able to understand basic git workflow as well...
>
> I'm not sure if you really mean every contributor, or every contributor
> with commit rights to FGData. In the second case I'd
> Every fgdata contributor who creates complicated xml/shader files should
> be able to understand basic git workflow as well...
I'm not sure if you really mean every contributor, or every contributor with
commit rights to FGData. In the second case I'd agree with you, but in case
it's the fir
> Hi Pete,
>
> What about the idea I thought you were working
> on of zipping each aircraft - presumably regularly
> updated as more git changes happen - and having
> like the FGx GUI downloading and installing these
> at the users choice/request?
>
> Thus an initial install of fgdata would only ha
On Sun, 2012-09-23 at 17:43 +0100, Peter Morgan wrote:
> I got a really really slow connection
>
> Got around the git problem by using a script on a dedicated to pull
> from git, and "push" to a subversion, which runs twice a day
>
> I then checkout from subversion read only of course, it wor
I got a really really slow connection
Got around the git problem by using a script on a dedicated to pull
from git, and "push" to a subversion, which runs twice a day
I then checkout from subversion read only of course, it works a treat
and get all updates very quickly..
However this approac
-Original Message-
From: Torsten Dreyer
Sent: Sunday, September 23, 2012 3:36 PM
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] fgdata trouble
Hi all,
there is a WIKI page for this topic:
http://wiki.flightgear.org/FlightGear_Git:_splitting_fgdata
Many points
"Alan Teeder" wrote:
> Sorting out the aircraft is then a completely separate problem, and several
> solutions to this have already been proposed. As we all remember one was
> actually implemented last year, but for various reasons not made fully
> public , was promptly abandoned.
You might tr
Hi all,
there is a WIKI page for this topic:
http://wiki.flightgear.org/FlightGear_Git:_splitting_fgdata
Many points have been discussed over and over some time ago.
If there is something new that has developed over time, please add it to
the wiki page before it gets lost on the mailing list.
Martin
Your suggestion of just having the Cessna is a "base package" version of
fgdata is just what is required. I would go further and extend it to
including all those aircraft which are in the regular release versions.
These particular aircraft are on the whole well maintained and showcase th
On Sun, 2012-09-23 at 13:33 +, Martin Spott wrote:
> "Alan Teeder" wrote:
>
> > Brisa script has this line
> >git clone git://gitorious.org/fg/fgdata.git fgdata
> >
> > This is also the default to which all new users are most likely to come
> > across..
>
>
> Q) We need to
"Alan Teeder" wrote:
> Brisa script has this line
>git clone git://gitorious.org/fg/fgdata.git fgdata
>
> This is also the default to which all new users are most likely to come
> across..
Q) We need to use smaller bolts for the railway bridge ! Every time I
try to mount a
Martin wrote:
> "Alan Teeder" wrote:
>
> > Twice I left it running overnight, but it failed both times after
> > several hours during the fgdata clone.
>
> Which server do you clone from ? If you don't already do so, then you
should
> consider fetching the initial clone from mapserver and to c
Stefan Seifert wrote:
> Since really only the initial clone is a problem, we could just offer a
> weekly
> updated tar ball of a bare clone for download. This download would just be ~
> 5
> GiB and would be resumable.
[...]
> Any thoughts?
Good idea. We actually had this for a while, but I d
On Sunday 23 September 2012 10:19:52 Alan Teeder wrote:
> The reason I quoted 10 Gb is that my fgdate/.git/objects directory is
> currently 8.9Gb, and I assumed that is what gets downloaded during a clone.
> I bow to your wisdom if you say that it is "only" 4.9Gb.
Since really only the initial cl
-Original Message-
From: Martin Spott
Sent: Sunday, September 23, 2012 11:42 AM Newsgroups: list.flightgear-devel
To: flightgear-devel@lists.sourceforge.net
Subject: Re: [Flightgear-devel] fgdata trouble
"Alan Teeder" wrote:
> Twice I left it running overnight, but i
Bertrand Coconnier wrote:
> git repack
> git gc
> git prune
Same here, I'm running a similar set as hooks on the mapserver GIT
mirror,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
"Alan Teeder" wrote:
> Twice I left it running overnight, but it failed both times after several
> hours during the fgdata clone.
Which server do you clone from ? If you don't already do so, then you
should consider fetching the initial clone from mapserver and to change
the remote origin after
-Original Message-
From: Bertrand Coconnier
Sent: Sunday, September 23, 2012 10:30 AM
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] fgdata trouble
I have the same size than Martin. For that I execute on a regular
basis the following commands
git repack
git gc
On Sat, 2012-09-22 at 19:44 +, Martin Spott wrote:
> "Alan Teeder" wrote:
>
> > New flightgear git users are faced with an initial download of about 10gb
> > just to get started.
>
> Currently the "fgdata" GIT repo has approx. 4.9 GByte,
>
> Martin.
Hi Martin, Alan, Bertrand, et al..
2012/9/23 Alan Teeder :
>
> The reason I quoted 10 Gb is that my fgdate/.git/objects directory is
> currently 8.9Gb, and I assumed that is what gets downloaded during a clone.
> I bow to your wisdom if you say that it is "only" 4.9Gb.
I have the same size than Martin. For that I execute on a regul
Martin
Last week I set up a Linux partition and ran the Brisa script.
Twice I left it running overnight, but it failed both times after several
hours during the fgdata clone.
Eventually I just copied over all 15gb from my current windows fgdata
directory and did a git pull on this. That seems
Thanks Thorsten for your clear words,
yes, it sucks to see people messing up the history, merging local branches
and then pushing them to gitorious. I personally see another problem in the
way changes that are merged appear in the history: The merge date is there,
but the commits associated to i
"Alan Teeder" wrote:
> New flightgear git users are faced with an initial download of about 10gb
> just to get started.
Currently the "fgdata" GIT repo has approx. 4.9 GByte,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
-
-devel] fgdata trouble
On Fri, Sep 21, 2012 at 11:51 PM, ThorstenB wrote:
> On 21 Sep 2012, at 13:03, Anders Gidenstam wrote:
>> The master branch of fgdata has become messed up. A number of commits
...
> It has happened again, fgdata history is messed up. It looks as if my
> last c
On Fri, Sep 21, 2012 at 11:51 PM, ThorstenB wrote:
> On 21 Sep 2012, at 13:03, Anders Gidenstam wrote:
>> The master branch of fgdata has become messed up. A number of commits
...
> It has happened again, fgdata history is messed up. It looks as if my
> last commits (6d46fe7, f722671) were applied
On 21 Sep 2012, at 13:03, Anders Gidenstam wrote:
> The master branch of fgdata has become messed up. A number of commits
> have become duplicated and some undone (they exist in the history but
> their effect is gone from HEAD).
It has happened again, fgdata history is messed up. It looks as if my
Hi all,
The master branch of fgdata has become messed up. A number of commits
have become duplicated and some undone (they exist in the history but
their effect is gone from HEAD).
I'm not sure how to sort this out or if it is worth the effort to do so
(I can easily push yet another copy of my
28 matches
Mail list logo
