From: Frederic B. <fre...@fr...> - 2008-08-27 10:26:28
|
----- "Martin Spott" <Mar...@mg...> 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 > > > another question. > > What is your reason behind repeatedly expressing concerns wrt. > storing > the base package in GIT ? How do you merge binary files ? What happens when the same texture is modified by 2 designers. In CVS and SVN, the new file simply replace the locally modified one that is renamed for reference. What is the behaviour of GIT ? I'd also say that I simply don't see what GIT will bring me and what are the use cases, not speeking about the new commands to learn. I browsed the different fg GIT mirrors and I see several instance of the FG tree. Some are old. What one is supposed to to with them ? 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 someone has to explain why GIT is superior. A wiki page would be just fine. -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://fgsd.sourceforge.net/ FlightGear Scenery Designer |
From: Martin S. <Mar...@mg...> - 2008-08-27 11:11:12
|
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 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 someone has to explain why GIT is > superior. A wiki page would be just fine. First: GIT allows you to create 'exact' copies of a remote repository "by design". Everyone of us knows about the trouble with 'cvs update' finishing without errors, still letting changes slip?through occasionally. In GIT every file is being checksummed (I'd be happy to learn that this is also the case with SVN). For a nice intro, read this article: http://lwn.net/Articles/131657/ Second: GIT allows you to have local repositories and to pull changes from a co-developer without taking the detour via the 'main' repository. Now, if you push the respective change to the main repo after you did local testing, in the end it looks the same as if your co would have done the merge to 'main' because in GIT every changeset has a unique identifier, no matter on which repository it is being hosted, which route it takes through different repositories. For all the other nice features, read this one: http://utsl.gen.nz/talks/git-svn/intro.html#wtf-why Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- |
From: Frederic B. <fre...@fr...> - 2008-08-30 21:17:08
|
----- "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 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 (and files with a mix inside) in the repository. > And > then we get trouble with all the linux tools not able to handle > CRLF... > > So the convertion is more then just convenience. It's a necessity for > every project with both windows and linux developers. And this is what WinCVS is doing already. We were plaggued in the past by binary file corruption on windows because CVS was not configured to recognize binary file automatically but this is history. SVN flags binary files automatically and GIT should do that the same way. And you can override the settings manually. -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://fgsd.sourceforge.net/ FlightGear Scenery Designer |
From: Frederic B. <fre...@fr...> - 2008-08-30 21:45:07
|
----- "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 > > 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 (and files with a mix inside) in the repository. > > And > > then we get trouble with all the linux tools not able to handle > > CRLF... > > > > So the convertion is more then just convenience. It's a necessity > for > > every project with both windows and linux developers. > > And this is what WinCVS is doing already. We were plaggued in the past > by binary file corruption on windows because CVS was not configured to > recognize binary file automatically but this is history. SVN flags > binary files automatically and GIT should do that the same way. And > you can override the settings manually. There is sometimes the problem of Windows contributors sending CRLF files to Linux commiters. We end up with CRCRLF files with CVS. I hope GIT is smart enough to strip CR on Linux commit. -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://fgsd.sourceforge.net/ FlightGear Scenery Designer |
From: <tho...@jy...> - 2011-10-17 07:11:40
|
> The "Models" folder for example, since that's not maintained there - > it's just a copy of what is maintained in the scenery database > and we shouldn't modify it directly in fgdata. Um... not true. Cloud textures and models currently reside in /Models/Weather/ and as far as I know are modified within fgdata, but are not in the scenery database. * Thorsten |
From: ThorstenB <br...@gm...> - 2011-10-17 07:17:55
|
On 17.10.2011 09:11, tho...@jy... wrote: >> The "Models" folder for example, since that's not maintained there - >> it's just a copy of what is maintained in the scenery database >> and we shouldn't modify it directly in fgdata. > > Um... not true. Cloud textures and models currently reside in > /Models/Weather/ and as far as I know are modified within fgdata, but are > not in the scenery database. Yes, true, we noticed that already. Hence we'll have to leave it as it is right now. A bit unfortunate, this would have really shrunk the archive significantly. But we may still be able to do that one day... cheers, Thorsten |
From: Torsten D. <To...@t3...> - 2011-10-17 07:48:37
|
>> Um... not true. Cloud textures and models currently reside in >> /Models/Weather/ and as far as I know are modified within fgdata, but are >> not in the scenery database. > > Yes, true, we noticed that already. Hence we'll have to leave it as it > is right now. A bit unfortunate, this would have really shrunk the > archive significantly. But we may still be able to do that one day... We have an Environment directory in fgdata. If we move Weather, this should be the right place for it. Torsten |
From: Martin S. <Mar...@mg...> - 2011-10-17 07:36:45
|
ThorstenB, ThorstenB wrote: > Yes, true, we noticed that already. Hence we'll have to leave it as it > is right now. A bit unfortunate, this would have really shrunk the > archive significantly. But we may still be able to do that one day... The two biggest chunks in Models/ are Weather/ (110 MByte) and Geometry/ (35 MByte). If we'd rip these out - just as a thought experiment - the rest which somehow relates to Scenemodels would be only 100 MByte. That's quite small compared to most other subdirectories. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- |
From: <tho...@jy...> - 2011-10-17 07:28:01
|
> Yes, true, we noticed that already. Hence we'll have to leave it as it > is right now. A bit unfortunate, this would have really shrunk the > archive significantly. But we may still be able to do that one day... It's a finite task to move the Weather/ folder elsewhere (i.e. out of Models/) and do a search/replace in the weather code to change to a new location. If you want to get it done after the airplanes have been taken out of the repo, just let me know and I'll change the code. * Thorsten |
From: <tho...@jy...> - 2011-10-17 07:49:04
|
>> Yes, true, we noticed that already. Hence we'll have to leave it as it >> is right now. A bit unfortunate, this would have really shrunk the >> archive significantly. But we may still be able to do that one day... > > The two biggest chunks in Models/ are Weather/ (110 MByte) and > Geometry/ (35 MByte). If we'd rip these out - just as a thought > experiment - the rest which somehow relates to Scenemodels would be > only 100 MByte. That's quite small compared to most other > subdirectories. Half of the textures in /Weather/ will be obsolete soon (= as soon as the new cloud rendering system runs reliably and is tested, i.e. in a month from now?). That can potentially reduce the size here. * Thorsten |
From: Martin S. <Mar...@mg...> - 2008-08-27 13:06:22
|
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 you don't have any network access while sitting at the beach on a remote island .... Once you're back to a place where you have network access, you're easily - without having to deal with a collection of individual patch files - going to push all the accumulated changes at once but still retaining the granularity of the individual steps. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- |
From: Curtis O. <cur...@gm...> - 2008-08-27 14:59:13
|
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 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 you don't have any network access while sitting at > the beach on a remote island .... > Once you're back to a place where you have network access, you're > easily - without having to deal with a collection of individual patch > files - going to push all the accumulated changes at once but still > retaining the granularity of the individual steps. > > Cheers, > Martin. > -- > Unix _IS_ user friendly - it's just selective about who its friends are ! > -------------------------------------------------------------------------- > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Curtis Olson: http://baron.flightgear.org/~curt/ |
From: Christian S. <ch...@il...> - 2008-08-27 16:18:38
|
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 where you have network access, you're > easily - without having to deal with a collection of individual patch > files - going to push all the accumulated changes at once but still > retaining the granularity of the individual steps. > ... which is IMHO one of the most interesting and useful features of GIT for FG development, but also for scenery stuff. SVN is lacking such functionality. Chris |
From: Roy V. O. <roy...@ha...> - 2008-08-27 20:02:20
|
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 someone has to explain why GIT is superior. A wiki page would be > just fine. Linus Torvalds' talk about git: http://www.youtube.com/watch?v=4XpnKHJAok8 Try to ignore Linus' bashing of cvs and svn (and the apparent aesthetic qualities of their users). Focus on the distributed part! Randal Schwartz's talk: http://video.google.com/videoplay?docid=-3999952944619245780 Intro to Distributed Version Control (Illustrated): http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ -- Roy Vegard Ovesen |
From: Melchior F. <mf...@ao...> - 2008-08-28 18:40:45
|
* 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/fg. Not in anticipation of a possible switch, but because GIT offers a lot that neither CVS nor SVN do. So the "well known" is rather misleading. How many are already using SVN for fgfs development because it's so great? My guess is: exactly zero. :-P GIT is well supported on Unix/Linux/Mac/Windows. Windows is supported through msysgit (http://code.google.com/p/msysgit/). This isn't a hostile fork. Merging it with stock git is planned. A tortoise-like click-and-point interface for Windows users is being worked on. Windows using FlightGear developers are certainly smart enough to use the command line for a while until it's finished. GIT isn't difficult. Checking out a GIT repository, making a local branch, committing there, and finally submitting ("pushing") is easy. Additional "familiar" commands can easily get added via GIT aliases. But GIT does offer a lot more than CVS and SVN put together, and some of those capabilities can be harder to grok at first ... until you are familiar with them. But that doesn't make it harder than SVN, because SVN doesn't offer those features in the first place. Why I prefer GIT: Mainly because it supports local feature/topic branches. I do no longer want to work without that. m. |
From: Melchior F. <mf...@ao...> - 2008-08-29 11:55:28
|
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. The discussion may also be interesting for some of you: http://dot.kde.org/1219926799/ Some quotes: "The centralized development system in Subversion's trunk doesn't support team-based development very well, [...] KDE's current revision control system [SVN] doesn't allow for offline commits, making life harder for people without a stable internet connection. [...] Git has already stolen the hearts of many KDE developers, [...]" "Before someone claims Git isn't cross-platform, I'll jump in to say that I use Git with Linux, MacOS X, and Windows on a daily basis, and I can testify to the fact that Git works just fine in Windows now :) Oh, and Git is really not hard to learn at all; it just takes a little time to get started." There are also critical remarks, of course. But don't expect me to quote those. ;-) m. |
From: Stefan C. M. <st...@s-...> - 2008-08-29 12:08:14
|
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 git before and uses windows. I just want to share my first impressions with msysGit, and the results of my binary-handing tests. * Installation was trivial. * Using the console commands works perfectly and there is lots of tutorials and manuals for those around. * The GUI is a bit odd. But using the graphical branch plot works and is simple to use. * It's not comparable with tortoise when it comes to usability, but it gets the job done with acceptable effort. * The speed is ok (tested with the data part of flightgear). * msysGit converts LF/CRLF by default with is very convenient. I did some tests regarding the handling of binary files. GIT seems to be fully able to handle binary files. What you put into a repository you get out identic (checked with md5). There is however a catch. If msysGit converts LF->CRLF on checkout and CRLF->LF on checkin. It does this on files its heuristic regards as textfiles. If this heuristic fails, its possible that binaries get corrupted. The good news is that the heuristic seems working well. It did not classify a single file in fgdata wrong. The conversion can be disabled completely. Also its possible to manually define text/binary on a per file basis, should the heuristic ever fail for a file. I must admit that I was sceptical first, beeing used to subversion for years. But the desciptions (and torwalds talk) of distributed SCM make me insterested in git. I really enjoyed the ease of branching and merging despite the poor gui. This morning at work, using subversion felt suddently much more clumsy, even with tortoise. For new developers looking at fg, it's important to see that there is no CVS in use (I almost walked away when saw it on the page). If git or svn is not that relevant. It took me 10 min to get git installed and start downloading from a remote repository. But it took 2+ days to get it compile (to be honest, it still doesn't). Stefan |
From: Thomas <tho...@gm...> - 2008-08-29 20:46:33
|
On Fri, Aug 29, 2008 at 7:11 AM, "Stefan C. Müller" <st...@s-...> 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 with svn > and cvs experience (later I have nightmares about), who has never heard > of git before and uses windows. I just want to share my first > impressions with msysGit, and the results of my binary-handing tests. > > * Installation was trivial. > * Using the console commands works perfectly and there is lots of > tutorials and manuals for those around. > * The GUI is a bit odd. But using the graphical branch plot works and is > simple to use. > * It's not comparable with tortoise when it comes to usability, but it > gets the job done with acceptable effort. > * The speed is ok (tested with the data part of flightgear). > * msysGit converts LF/CRLF by default with is very convenient. > > I did some tests regarding the handling of binary files. GIT seems to be > fully able to handle binary files. What you put into a repository you > get out identic (checked with md5). There is however a catch. If msysGit > converts LF->CRLF on checkout and CRLF->LF on checkin. It does this on > files its heuristic regards as textfiles. If this heuristic fails, its > possible that binaries get corrupted. The good news is that the > heuristic seems working well. It did not classify a single file in > fgdata wrong. The conversion can be disabled completely. Also its > possible to manually define text/binary on a per file basis, should the > heuristic ever fail for a file. > > I must admit that I was sceptical first, beeing used to subversion for > years. But the desciptions (and torwalds talk) of distributed SCM make > me insterested in git. I really enjoyed the ease of branching and > merging despite the poor gui. This morning at work, using subversion > felt suddently much more clumsy, even with tortoise. > > For new developers looking at fg, it's important to see that there is no > CVS in use (I almost walked away when saw it on the page). If git or svn > is not that relevant. It took me 10 min to get git installed and start > downloading from a remote repository. But it took 2+ days to get it > compile (to be honest, it still doesn't). > > Stefan > 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 assuming that Git under CygWin does not have that limitation? Anyone here tried it? |
From: Christian S. <ch...@il...> - 2008-08-29 22:52:28
|
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 assuming that Git under CygWin does not have that > limitation? Anyone here tried it? As I already wrote here yesterday, the fgdata repo needs currently approx 1GB of diskspace on my machine here. I don't know if msysGit counts this a bit differently, but for the forseeable future, we should be save in this regard, as fgdata is AFAIK the biggest repo we have. Chris |
From: Stefan C. M. <st...@s-...> - 2008-08-30 20:19:28
|
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 default, some even to automatic conversion (like VC). We would end up having files of both types (and files with a mix inside) in the repository. And then we get trouble with all the linux tools not able to handle CRLF... So the convertion is more then just convenience. It's a necessity for every project with both windows and linux developers. Stefan |
From: Christian S. <ch...@il...> - 2008-08-30 21:36:21
|
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 (and files with a mix inside) in the repository. And > then we get trouble with all the linux tools not able to handle CRLF... 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"? Cheers Chris |
From: Stefan C. M. <st...@s-...> - 2008-08-30 21:45:54
|
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, but I'm sure there are such tools. I'd expect many will happily read CRLF but write LF back. giving you a diff changing every single line even if nothing was changed. Stefan |
From: Melchior F. <mf...@ao...> - 2008-09-03 08:49:49
|
* 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/content with a size >2GB after compression(!). I just created a 4.3GB repository under msysgit. Stock git (Linux/Unix/OSX/cygwin-windows) doesn't have that problem at all, only msysgit still has. That's because it uses 32bit file operations through MSVCRT.DLL. There's no fundamental problem, a switch to the 64bit functions shouldn't be hard and will certainly happen in the next time, at the latest when msysgit gets merged into stock git, which is planned. But in any case: 2GB "blobs" ought to be enough for anybody[TM], at least for flightgear. And for the very, *very* unlikely case that we need such before msysgit was fixed, Windows users could still switch to the cygwin flavor of git. (And who knows if CVS would be any better at taking such big files. :-) m. |
From: Melchior F. <mf...@ao...> - 2008-09-03 09:02:34
|
* 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 probably be "random" data, anyway, and would, thus, not really be compressible (i.e. compressed already or random-like sound data). m. |
From: Frederic B. <fre...@fr...> - 2008-09-03 12:05:15
|
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/frfoto/ Photo gallery - album photo http://fgsd.sourceforge.net/ FlightGear Scenery Designer |