On Tue, May 18, 2010 at 6:17 PM, Peter Morgan wrote:
> On Sat, May 15, 2010 at 7:12 PM, Csaba wrote:
> > During discussions on IRC, the idea came up of creating a downloadable
> > bundle of the new gitorious fg-data repository.
> What I want is for a someone to aqquire the "terrain for swanea and s
On Sat, May 15, 2010 at 7:12 PM, Csaba Halász
wrote:
During discussions on IRC, the idea came up of creating a downloadable
bundle of the new gitorious fg-data repository. The primary reason is
to make the initial clone operation resumable in case the connection
breaks. Our understanding is that
Heiko Schulz wrote:
> So the next question is:
As far as I can tell, details are being arranged after the repositories
have been migrated properly - which, obviously, is the most relevant
step now.
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends
On Wed, May 12, 2010 at 4:37 PM, Heiko Schulz wrote:
>
> So the next question is:
> Will be the system of permission to upload things to the repo be the same
> like we had with CVS?
>
> My opinion on this is, that it was not always easy to maintain your work of
> you don't have permission to upl
.2010:
> Von: Torsten Dreyer
> Betreff: Re: [Flightgear-devel] GIT or CVS - Confusion
> An: "FlightGear developers discussions"
>
> Datum: Mittwoch, 12. Mai, 2010 22:16 Uhr
> Short answer:
>
> http://www.flightgear.org/cvs.html
>
> Torsten
>
> Am 12
Short answer:
http://www.flightgear.org/cvs.html
Torsten
Am 12.05.10 22:02, schrieb Heiko Schulz:
>
> Hi @all,
>
> I'm confused- CVS seems to be down. But in the forum I heard rumors that we
> now changed to GIT finally.
>
> The official FlightGear page doesn't show anything like that we switch
Csaba Halász wrote:
> 2) fix a crash in SGSoundMgr::stop() due to invalid iterator usage:
> http://gitorious.org/~jester/fg/jesters-sg-clone/commit/12604fb231631252b13af1338020926e2ca1a605
> Thanks to Vivian for reporting.
That one still bites me once in a while. I don't like itterators all
that
Original Message-
>> From: Csaba Halász [mailto:csaba.hal...@gmail.com]
>> Sent: 26 October 2009 16:47
>> To: FlightGear developers discussions
>> Subject: Re: [Flightgear-devel] [GIT] various fixes including
>> atcvoice,commlist and nans
>>
>> On Mon, Oct
discussions'
> Subject: Re: [Flightgear-devel] [GIT] various fixes including
> atcvoice,commlist and nans
>
> With the current CVS and VC++ 2008 Express I now get this compilation
> error:
>
> "Compiling...
> fg_init.cxx
> ..\..\..\src\Main\fg_init.cxx(149) : err
quot;#include " in perfomancedb.cxx,
FGDeviceConfiguration.cxx, and simgear/scene/material/matmodel.cxx and
simgear/scene/model/model.cxx
> -Original Message-
> From: Csaba Halász [mailto:csaba.hal...@gmail.com]
> Sent: 26 October 2009 16:47
> To: FlightGear developers discussions
&
Excuse me, sorry for wasting time... Indeed a cvs conflict!
2009/10/26, Csaba Halász :
> On Mon, Oct 26, 2009 at 5:18 PM, stefan riemens
> wrote:
>> Unfortunately, this has broken mingw x-compilation for me:
>> ATCVoice.cxx:42: error: expected unqualified-id before '<<' token
>
> Please make sure
On Mon, Oct 26, 2009 at 5:18 PM, stefan riemens wrote:
> Unfortunately, this has broken mingw x-compilation for me:
> ATCVoice.cxx:42: error: expected unqualified-id before '<<' token
Please make sure you don't have a cvs conflict. Line 42 should be
"using namespace std;" and no << around there.
Unfortunately, this has broken mingw x-compilation for me:
i686-pc-mingw32-g++ -DHAVE_CONFIG_H -I. -I../../src/Include -I../..
-I../../src -I/usr/i686-pc-mingw32/sys-root/mingw/include -O2 -g
-pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
--param=ssp-buffer-size=4 -mms-bitfields -D_REENTRANT -
Csaba Halász wrote:
> On Mon, Oct 26, 2009 at 10:08 AM, James Turner wrote:
>>
>> For these kind of fixes, I'd much rather you committed them straight
>> away to CVS, because it's easy for anyone to look at a single NaN fix
>> (or whatever) and convince themselves it's correct - or raise an
>> obj
On Mon, Oct 26, 2009 at 10:08 AM, James Turner wrote:
>
>
> For these kind of fixes, I'd much rather you committed them straight
> away to CVS, because it's easy for anyone to look at a single NaN fix
> (or whatever) and convince themselves it's correct - or raise an
> objection. When many trivial
On 25 Oct 2009, at 16:35, Csaba Halász wrote:
> Hence, I didn't
> request a merge via gitorious so as to give the respective "owners" of
> the areas I changed a chance to comment on and/or commit my patches
> and not to put this burden on poor Tim :) I can of course supply
> diffs to anybody not
Csaba Halász
> Hi!
>
> I have made some updates available from my gitorious repo (URL:
> http://gitorious.org/~jester), on various branches. Here is a little
> summary:
>
> * branch atcvoice: has a cleaned-up version of
> FGATCVoice::WriteMessage synced to the current state of the sound
> syst
Melchior
>
> MS Windows users who are interested in Git might want to check
> this out:
>
> http://code.google.com/p/gitextensions/
>
> Nice screenshots there as well. :-)
>
Now installed, at second attempt. On brief acquaintance is seems OK.
Certainly worth further investigation. Thanks f
Melchior
>
> MS Windows users who are interested in Git might want to check
> this out:
>
> http://code.google.com/p/gitextensions/
>
> Nice screenshots there as well. :-)
>
> m.
>
I will try it - pity about the "intergation" though
Vivian
On Sun, 8 Feb 2009 16:15:51 +0100, Melchior wrote in message
<200902081615.51...@rk-nord.at>:
> MS Windows users who are interested in Git might want to check
> this out:
>
> http://code.google.com/p/gitextensions/
>
> Nice screenshots there as well. :-)
..aye, how much in the tutorials is
John Denker wrote:
> On 01/07/2009 01:19 PM, James Turner wrote:
>> On 7 Jan 2009, at 19:05, Tim Moore wrote:
>>
>>> I like to fetch and then rebase my local work without merging; it
>>> makes
>>> it much easier to get the commits into CVS via git-cvsexportcommit.
>>> When we move
>>> to git an
On 01/07/2009 01:19 PM, James Turner wrote:
> On 7 Jan 2009, at 19:05, Tim Moore wrote:
>
>> I like to fetch and then rebase my local work without merging; it
>> makes
>> it much easier to get the commits into CVS via git-cvsexportcommit.
>> When we move
>> to git and publish (sometimes) perso
On 7 Jan 2009, at 19:05, Tim Moore wrote:
> I like to fetch and then rebase my local work without merging; it
> makes
> it much easier to get the commits into CVS via git-cvsexportcommit.
> When we move
> to git and publish (sometimes) personal branches, I'll probably
> switch back to
> "gi
James Turner wrote:
> On 27 Dec 2008, at 15:04, Tim Moore wrote:
>
>> Here's my workflow for using git with the FlightGear sources in CVS.
>> Note that
>> there are separate repositories for Fightgear, Simgear and the
>> Flightgear data.
>> This is inconvenient and there may a workaround using
Am Montag 05 Januar 2009 schrieb James Turner:
> - when I want to sync the main repo with the cvs-import one, your
> instructions say 'git fetch', but I seem to need to 'git pull' to get
> the master branch in sync with the origin. It works fine, I guess I'm
> just mis-understanding what fetch a
On 27 Dec 2008, at 15:04, Tim Moore wrote:
> Here's my workflow for using git with the FlightGear sources in CVS.
> Note that
> there are separate repositories for Fightgear, Simgear and the
> Flightgear data.
> This is inconvenient and there may a workaround using git
> submodules, but I
>
James Turner wrote:
> I could benefit from some advice on using git to track (various) local
> changes I'm working on.
>
Here's my workflow for using git with the FlightGear sources in CVS. Note that
there are separate repositories for Fightgear, Simgear and the Flightgear data.
This is incon
On Sunday 17 August 2008 17:28:43 James Turner wrote:
> I'm using git quite happily, it's working well as a way of tracking my
> different threads of development and submitting clean patches. I
> hadn't realised there were so many also using it (with different
> mirrors)
> So, yes, definitely a vot
James Turner wrote:
> On 3 Sep 2008, at 17:37, Tim Moore wrote:
>
>> For the record, it's completely impractical to maintain a bi-
>> directional cvs-git
>> mirror system -- where committers can check into either the cvs or
>> the git
>> repository -- and probably only slightly less so to maint
Bonsoir Frederic,
Frederic Bouvier wrote:
> - "Martin Spott" a ?crit :
> > Hehe, my conclusion is a different one: This is the reason why some
> > people, including me, are proposing to have a single 'authoritative'
> > GIT mirror, last but not least to ensure that the unique identifiers
> >
* Melchior FRANZ -- 9/3/2008 6:26 PM:
> - There's a fake-cvs server that Curt could install alongside of
> GIT. It mimics CVS and allows to access the GIT repo with a CVS
> client as if it were a true CVS. I guess that sooner or later
> there will be the same for SVN.
Oh, and I do also not k
Hey,
looks like I'm late to the party, and others have already answered
the questions, but here's my sermon:
* Frederic Bouvier -- 9/3/2008 2:05 PM:
> there is another thing that is unclear to me. How GIT currently
> interface with CVS ( and tomorrow SVN ) ?
> How do you merge content from CVS i
On 3 Sep 2008, at 17:37, Tim Moore wrote:
> For the record, it's completely impractical to maintain a bi-
> directional cvs-git
> mirror system -- where committers can check into either the cvs or
> the git
> repository -- and probably only slightly less so to maintain a bi-
> directional
> s
Frederic Bouvier wrote:
> - "Martin Spott" a écrit :
>
>> Frederic Bouvier wrote:
>>
>>> While working on git-svn, we realized that there are a few scripts
>>> in msysGit that cannot possibly work (yet), so we excluded them from
>>> the Git installer. These scripts are: archimport, cvsexportco
- "Martin Spott" a écrit :
> Frederic Bouvier wrote:
>
> > While working on git-svn, we realized that there are a few scripts
> > in msysGit that cannot possibly work (yet), so we excluded them from
> > the Git installer. These scripts are: archimport, cvsexportcommit,
> > cvsimport, cvsserv
Frederic Bouvier wrote:
> While working on git-svn, we realized that there are a few scripts in
> msysGit that cannot possibly work (yet), so we excluded them from the
> Git installer. These scripts are: archimport, cvsexportcommit,
> cvsimport, cvsserver, filter-branch, instaweb, send-email, and
Hi Martin,
- Martin Spott a écrit :
> Hi Frederic,
>
> Frederic Bouvier wrote:
>
> > You mean that it is Martin who do the 'cvs update' and we only have to do
> > 'git update' ( or whatever the command is ) ?
>
> The GIT toolbox contains several commands which allow to 'mirror'
> from a di
Hi Frederic,
Frederic Bouvier wrote:
> You mean that it is Martin who do the 'cvs update' and we only have to do
> 'git update' ( or whatever the command is ) ?
The GIT toolbox contains several commands which allow to 'mirror' from
a different SCM system. "git cvsimport" does this for me, there
Hi Fred!
Frederic Bouvier wrote:
> What if I have write access to the CVS repository ? Do I have to maintain
> a seperate CVS workspace and apply my own patch in that workspace before
> CVS commiting ? In that case I don't really see a great benefit ?
For TaxiDraw, I have git repository and a C
On 3 Sep 2008, at 14:24, Frederic Bouvier wrote:
> You mean that it is Martin who do the 'cvs update' and we only have
> to do
> 'git update' ( or whatever the command is ) ?
Not even Martin, it's an automatic sync, currently every 4 hours (I
think) for the src repository, of course this cou
- "James Turner" a écrit :
> On 3 Sep 2008, at 14:05, Frederic Bouvier wrote:
>
> > there is another thing that is unclear to me. How GIT currently
> > interface with CVS ( and tomorrow SVN ) ?
> > How do you merge content from CVS in your GIT repository ?
> > How do you commit changes in
On 3 Sep 2008, at 14:05, Frederic Bouvier wrote:
> there is another thing that is unclear to me. How GIT currently
> interface with CVS ( and tomorrow SVN ) ?
> How do you merge content from CVS in your GIT repository ?
> How do you commit changes in CVS after commiting in GIT ?
The merge from
Hi Melchior,
there is another thing that is unclear to me. How GIT currently interface with
CVS ( and tomorrow SVN ) ?
How do you merge content from CVS in your GIT repository ?
How do you commit changes in CVS after commiting in GIT ?
Thank,
-Fred
--
Frédéric Bouvier
http://my.fotolia.com/frf
* Melchior FRANZ -- 9/3/2008 10:49 AM:
> So you can at the moment not commit files/content with a
> size >2GB after compression(!).
Err, >2GB before compression, as it will use the same file
routines for turning content into blobs. But the difference
doesn't matter, as such big files would probabl
* Thomas -- 8/29/2008 10:46 PM:
> I'm more concerned about the 2 GB repo size limit listed in the "Known
> issues" in the release notes.
That's only worded badly. The 2GB limit isn't for the whole repository,
but for single "blobs" *in* a repository. So you can at the moment not
commit files/conte
Christian Schmitt wrote:
> Stefan C. M?ller wrote:
> > That's of course the safest choise for binary files. But it would
> > certainly mess up the text files.
> > While most windows tools can read LF, they all write CRLF by default,
> > some even to automatic conversion (like VC). We would end u
Christian Schmitt schrieb:
> Huh? From my experience it is more the other way around. I saw many
> Windows tool that displayed LF fext incorrectly but I have never seen a
> CRLF text in Linux being messed up. What exactly do you mean by "all the
> linux tools"?
>
Not "all" of them of course,
- "Frederic Bouvier" a écrit :
> - "Stefan C. Müller" a écrit :
> > Thomas schrieb:
> > > Thanks for that review. I'm still wary of the auto line term
> > > conversion and would probably favor disabling it.
> > >
> > That's of course the safest choise for binary files. But it would
> > cert
Stefan C. Müller wrote:
> That's of course the safest choise for binary files. But it would
> certainly mess up the text files.
> While most windows tools can read LF, they all write CRLF by default,
> some even to automatic conversion (like VC). We would end up having
> files of both types (an
- "Stefan C. Müller" a écrit :
> Thomas schrieb:
> > Thanks for that review. I'm still wary of the auto line term
> > conversion and would probably favor disabling it.
> >
> That's of course the safest choise for binary files. But it would
> certainly mess up the text files.
> While most wi
Thomas schrieb:
> Thanks for that review. I'm still wary of the auto line term
> conversion and would probably favor disabling it.
>
That's of course the safest choise for binary files. But it would
certainly mess up the text files.
While most windows tools can read LF, they all write CRLF by d
Thomas wrote:
> Thanks for that review. I'm still wary of the auto line term
> conversion and would probably favor disabling it.
The usual Unix tools have been _very_ reliable about telling different
file types for decades and I'd assume (read: I'm not certain) that GIT
on Windows would use the s
Christian Schmitt wrote:
> As I already wrote here yesterday, the fgdata repo needs currently
> approx 1GB of diskspace on my machine here.
This is a bit surprising, as the repository _without_ checkout should
have approximately this size:
hypersphere: 15:58:01 ~> du -hs git/fgdata/ GIT/fgdata/
Thomas wrote:
>
> Thanks for that review. I'm still wary of the auto line term
> conversion and would probably favor disabling it.
>
> I'm more concerned about the 2 GB repo size limit listed in the "Known
> issues" in the release notes. I don't think that will work for FG. Am
> I correct in as
On Fri, Aug 29, 2008 at 7:11 AM, "Stefan C. Müller" <[EMAIL PROTECTED]> wrote:
> Hi
>
> I just joined this list a few days ago. And haven't contributed a single
> codeline to flightgear (yet). So its not my place to say what I'd like
> best. But I'm possibly kind of the avarage maybe-contributor wi
Hi
I just joined this list a few days ago. And haven't contributed a single
codeline to flightgear (yet). So its not my place to say what I'd like
best. But I'm possibly kind of the avarage maybe-contributor with svn
and cvs experience (later I have nightmares about), who has never heard
of gi
Just for the record: KDE, one of the biggest F/OSS projects out
there, switched to SVN a few years ago. Now there are plans to
switch to one of the distributed SCM systems. SVN's capabilities
seem to be no longer fit for the job. The project will probably
switch to GIT. Here's an article about it.
Melchior FRANZ wrote:
> * Melchior FRANZ -- 8/26/2008 3:03 PM:
>> But it would make me a bit nervous if an aircraft developer commits
>> several pointless updates of 5MB sound files. GIT can't compress that.
>> We'd collect the whole pile on our disks. How much would disk space
>> requirements grow
* Frederic Bouvier -- 8/27/2008 12:26 PM:
> It is just that nobody explained me the benefits of using GIT over a
> well known system such as CVS and SVN. I am aware of the serious lacks
> of CVS, that's why I am advocating switching to SVN.
Half of the fgfs developers are already using GIT for sg/
On Wednesday 27 August 2008 12:26:34 Frederic Bouvier wrote:
> I am not saying it is useless. It is just that nobody explained me the
> benefits of using GIT over a well known system such as CVS and SVN. I am
> aware of the serious lacks of CVS, that's why I am advocating switching to
> SVN. Now so
Martin Spott wrote:
> I was persuaded to mention that GIT allows you to wrap single steps of
> your private development into independent commits to your local
> repository, even if you don't have any network access while sitting at
> the beach on a remote island
> Once you're back to a place
I think that once GIT can demonstrate strong support for non-unix platforms,
it will be a compelling option for our "OS independent" project.
Best regards,
Curt.
On Wed, Aug 27, 2008 at 8:05 AM, Martin Spott wrote:
> Frederic,
>
> Frederic Bouvier wrote:
>
> > I am not saying it is useless. It
Frederic,
Frederic Bouvier wrote:
> I am not saying it is useless. It is just that nobody explained me
> the benefits of using GIT over [...]
I was persuaded to mention that GIT allows you to wrap single steps of
your private development into independent commits to your local
repository, even if
James Turner wrote:
> On 27 Aug 2008, at 11:08, Martin Spott wrote:
> > What is your reason behind repeatedly expressing concerns wrt. storing
> > the base package in GIT ?
> That git seems very code-orientated, and I don't know of anyone using
> it as a binary data repository.
As I indicated
Frederic Bouvier wrote:
> How do you merge binary files ? What happens when the same texture is
> modified by 2 designers.
If they both push their work to the same repository, the newest
revision will replace the other ones and the older revisions will get
archived in the history.
> I am not say
On 27 Aug 2008, at 11:08, Martin Spott wrote:
> What is your reason behind repeatedly expressing concerns wrt. storing
> the base package in GIT ?
That git seems very code-orientated, and I don't know of anyone using
it as a binary data repository. It's a job CVS is dreadful at, of
course, b
- "Martin Spott" <[EMAIL PROTECTED]> a écrit :
> Hi James,
>
> James Turner wrote:
>
> > [...], a git primary code repo, and the git-svn proxy
> > allowing people who don't wish to use git for whatever reason to
> > continue using SVN. Whether that's true for the data repository is
>
Hi James,
James Turner wrote:
> [...], a git primary code repo, and the git-svn proxy
> allowing people who don't wish to use git for whatever reason to
> continue using SVN. Whether that's true for the data repository is
> another question.
What is your reason behind repeatedly expressing
On 27 Aug 2008, at 10:36, Melchior FRANZ wrote:
> Bah, I just saw a rather cheap 1TB disk offered in the ads of a shop
> that focuses on books, music CDs and paper stuff. I guess that a
> few MB more aren't really an issue nowadays. Hereby I withdraw the
> above consideration. So what's left as a
* Melchior FRANZ -- 8/26/2008 3:03 PM:
> But it would make me a bit nervous if an aircraft developer commits
> several pointless updates of 5MB sound files. GIT can't compress that.
> We'd collect the whole pile on our disks. How much would disk space
> requirements grow each year?
Bah, I just saw
* Curtis Olson -- 8/21/2008 5:46 PM:
> I also really like how svn handles group and user authentication ...
> it does it outside of the unix account system which makes the system
> much easier to manage.
Unix permissions are well understood and not hard to handle. They are
the most straightforwar
James Turner wrote:
> Yep, absolutely, especially since I am very unsure how git deals with
> binary files, [...]
Well, you easily get an answer to this question by trying it out - I've
already done that, many months ago ;-)
Best regards,
Martin.
--
Unix _IS_ user friendly - it's ju
Martin Spott wrote:
> John Denker wrote:
>> On 08/20/2008 02:32 PM, Curtis Olson wrote:
>
>>> Perhaps I misunderstand the scope and capabilities of git
>
>>> And at the end of the day, no matter what source code version control system
>>> we use, and no matter what useful tools it provides f
Curtis Olson wrote:
> Here's another "for what it's worth" ...
>
> I was able to find a set of options to the cvs2svn tool that worked for
> our repository. The FlightGear repository takes about an hour and 45
> minutes to convert. So that part works well. I also really like how
> svn handle
John Denker wrote:
> On 08/20/2008 02:32 PM, Curtis Olson wrote:
> > Perhaps I misunderstand the scope and capabilities of git
> > And at the end of the day, no matter what source code version control system
> > we use, and no matter what useful tools it provides for branching and
> > mergin
On 08/20/2008 02:32 PM, Curtis Olson wrote:
> Perhaps I misunderstand the scope and capabilities of git
> And at the end of the day, no matter what source code version control system
> we use, and no matter what useful tools it provides for branching and
> merging, we still need a human in t
On 21 Aug 2008, at 16:46, Curtis Olson wrote:
> I was able to find a set of options to the cvs2svn tool that worked
> for our repository. The FlightGear repository takes about an hour
> and 45 minutes to convert. So that part works well.
Yep, that's really great news - I have heard some ho
Here's another "for what it's worth" ...
I was able to find a set of options to the cvs2svn tool that worked for our
repository. The FlightGear repository takes about an hour and 45 minutes to
convert. So that part works well. I also really like how svn handles group
and user authentication ..
Richard Bytheway wrote
> > From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> James Turner
> >
> >
> >
> > - git works great on the Mac, or any Unix, but I believe it's never
> going to fly (if you'll pardon the expression) on Windows, due to
> technical limitations there
> >
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
James Turner
>
>
>
> - git works great on the Mac, or any Unix, but I believe it's never
going to fly (if you'll pardon the expression) on Windows, due to
technical limitations there
>
>
FWIW, Cygwin provides git (V1.5.3.5) fo
For what it's worth, I have started playing around with cvs2svn, but only
very recently. I've got nothing anyone can point at yet. Also by the way,
I will be out of town for a work project thursday - sunday. Also by the
way, my summer soccer team made the playoffs (we had to win our last 5 games
"Curtis Olson" wrote:
> Perhaps I misunderstand the scope and capabilities of git, but the way
> things settle out in my mind is that it would make sense to support an
> official GIT repository if (and only if) we decide to move the official
> master code repository to GIT. I don't see what an "o
On Wed, Aug 20, 2008 at 3:52 PM, Martin Spott wrote:
> The FlightGear project has been notoriously behind about getting
> people's source code contributions into CVS - for years. We all know
> the story, it's been the same for years already, no need to repeat it
> here.
>
> So, in order not to loo
On 20 Aug 2008, at 21:14, Frederic Bouvier wrote:
> Migrating from CVS to SVN would already be a very good thing IMO
Just to add some data to this
- git works great on the Mac, or any Unix, but I believe it's never
going to fly (if you'll pardon the expression) on Windows, due to
technica
Martin Spott wrote:
> The FlightGear project has been notoriously behind about getting
> people's source code contributions into CVS - for years. We all know
> the story, it's been the same for years already, no need to repeat it
> here.
>
> So, in order not to loose the respective contributions
Curt, there's yet another point:
"Curtis Olson" wrote:
> What Martin is referring to is a read only git mirror of the official
> FlightGear CVS repository so it should cause no harm as long as we are
> careful not to develop official dependencies that can only be supported on a
> single operating
On Wed, Aug 20, 2008 at 3:27 PM, Martin Spott wrote:
> The (my) GIT mirror doesn't intend to replace Curt's CVS service, at
> least not in the near future. Nevertheless I have in mind to propose a
> switchover to GIT once the Windows support has proven to be reliable in
> all modes of operation.
>
Frederic Bouvier wrote:
> Migrating from CVS to SVN would already be a very good thing IMO
>
> -Fred
>
Sure enough. But if we take a migration into consideration, we sould
probably go the GIT route. Although I'm not too experienced with git
when it comes to committing things to it, from the gi
Heiko,
Heiko Schulz wrote:
> The current SVN and CVS-clients are more comfortable. So in the
> moment I would like to see, that for releases and official things we
> keep on CVS( or maybe SVN?)
The (my) GIT mirror doesn't intend to replace Curt's CVS service, at
least not in the near future. Nev
Migrating from CVS to SVN would already be a very good thing IMO
-Fred
- "Heiko Schulz" a écrit :
> Hi,
>
> Could be that this message comes twice due to an error I had from my
> mailprovider...
>
> GIT:
> I did test it some days ago, and it works, but it is not very
> comfortable. Well,
the moment I would
like to see, that for releases and official things we keep on CVS( or maybe
SVN?)
Regards
HHS
--- Martin Spott <[EMAIL PROTECTED]> schrieb am Mi, 20.8.2008:
> Von: Martin Spott <[EMAIL PROTECTED]>
> Betreff: Re: [Flightgear-devel] GIT; Was: _Sport Model_
>
On Wed, Aug 20, 2008 at 2:43 PM, Frederic Bouvier wrote:
> Hi Curt, Hi Martin,
>
> how git is supported on systems that are not Linux ?
Download Virtual Box from sun (free) and run Linux in a virtual
machine on your mac/windows host.
That said, if anyone is looking for a fun toy ... VirtualBo
Frederic !
Frederic Bouvier wrote:
> how git is supported on systems that are not Linux ?
Depends on whom you ask. I know that GIT support on Windows machines
had been somewhat whacky for quite a while. Primarily GIT had been
relying on some Unix filesystem features that had not been available o
Hi Curt, Hi Martin,
how git is supported on systems that are not Linux ?
-Fred
- Curtis Olson a écrit :
> Hey Martin,
>
> I guess I'd like to ponder this a little while longer. Should be no
> problem
> to use the existing mapserver name (i.e. not having git.flightgear.org
> just
> yet do
Hey Martin,
I guess I'd like to ponder this a little while longer. Should be no problem
to use the existing mapserver name (i.e. not having git.flightgear.org just
yet doesn't impede anyone's development progress), and I guess I'd like to
spend some more time thinking about how official we want t
Pigeon wrote:
> Ah, I did not notice it's only providing http access. The last time
> I tried (maybe a year ago) http was much much slower than git's
> protocol. I think git protocol access is definitely a ++ :)
Ok, try it out - I've adjusted the instructions accordingly at:
http://mapserv
> Hi Pigeon, I hope you're doing well !
I'm good! :)
> Should be feasible, network bandwidth seemingly is not an issue and the
> machine just got an upgrade to 32 GByte RAM. If people dislike GIT over
> HTTP, then I'd check with our 'sponsor' wether I might set up an
> anonymous GIT daemon. Y
Hi Pigeon, I hope you're doing well !
Pigeon wrote:
> Having a central git repo would be great. Perhaps we could use the
> one at mapserver.flightgear.org Martin mentioned? Maybe have a
> git.flightgear.org subdomain or something.
Should be feasible, network bandwidth seemingly is not an iss
> I know some others use the GIT repo at:
>
> [1]http://mapserver.flightgear.org/git/gitweb.pl
>
> as a reference. Maybe now it's the right time to unify on one single
> repository,
>
>I'm using git quite happily, it's working well as a way of tracking my
>different
On 17 Aug 2008, at 17:22, Martin Spott wrote:
I know some others use the GIT repo at:
http://mapserver.flightgear.org/git/gitweb.pl
as a reference. Maybe now it's the right time to unify on one single
repository,
I'm using git quite happily, it's working well as a way of tracking my
diff
201 - 300 of 301 matches
Mail list logo
