On 21.06.2011 00:39, Vivian Meazza wrote: > The bug which was stopping the built-in download running here was trivial - > once we found it: a space in a directory name. Replaced with an underscore > and it worked right out of the tin. The white-space issue is fixed for the new library now. It only applied to external svn. The same problem persists for original terrasync(.exe) - it'll be fixed there once the utility is adapted to use the library (after the release). Same is true for the "trailing '/' issue". Fixed for the library now, persisting for terrasync(.exe) for now.
> Not quite - only the external mode was > available. That turned out to be caused by a non-updated config.h file. > Thanks to Fred for his help and guidance to solve that one. Indeed, thanks to Fred. It did work nicely for automake. I'm sorry that there were issues with the MSVC9 project (or cmake). But I'm depending on others helping me out here. And I truly hope we can have a common build system only one day - cmake maybe. > In doing this I noticed that both the built in and external variants seem to > be functionally similar. I can't even work out how or why the external > variant works - but it does. FG finds, starts, and stops the external SVN > program. Either ThostenB has been very clever, or it's just serendipity > here. I hope it's the former. The code relies on finding "svn" on the system path. Same as terrasync(.exe) did - remember it's (almost) the same code. The latest update (yesterday) has an option to configure a full path to svn(.exe), which resolves the issue with systems where svn(.exe) isn't on the system path. Again, that's not available yet for the terrasyn(.exe) utility - it will be later (see above). And of course, the svn-library/svn-command-line options are functionally similar. > 4. It is handy to be able to switch off/on scenery download at runtime, but > here you only get about 5 of the 10 fps back. I see that once started the > svn program remains loaded: this might be the cause. I don't see "svn" processes sticking. If a "svn" process is still present, then subversion is still active. The call to external svn is blocking - it's impossible that a svn process sticks when you've successfully disabled svn support (see status in GUI). You'll notice that hitting "Apply"/"OK" buttons briefly block the GUI when you disable terrasync: they block since the code waits for the final (blocking) svn operation to return/abort. And I can guarantee that there is no thread or anything running once terrasync is disabled. So, if you see any fps difference and terrasync is disabled, then that difference isn't caused by terrasync/svn. > 5. The automatic refresh works well. There is an occasional grey-out. > Disconcerting at first, but actually not a problem. This is a major > advantage over Terrasync Yesterday, I have limited that feature for the current release to only affect cases where ocean tiles (missing scenery) are replaced by actual scenery. It removes the distracting effect for normal tiles, until we can handle the refresh smoothly (like when they are out of sight). It remains an advantage when missing scenery is replaced by actual data: better to have a brief gray-out and then see the tile with the destination airport, than to keep seeing a patch of ocean/missing scenery. > 5. To use the built-in option requires 2 additional and quite large > dependencies which will need updating etc from time to time. For those of us > that build FG this is a bit of a pain. It's absolutely the same dependency that terrasync(.exe) has. If you haven't used/weren't interested in terrasync(.exe) so far - don't bother about the new feature. If you have used it, then FG can now be built with the same dependencies like terrasync(.exe) was. Again, nothing really changes. cmake/automake will make sure that the svn-library dependency is automatically disabled when the library isn't present (again, sorry, if you're using a fixed MSVC9 project - hopefully cmake will help you soon). Those running pre-built Windows/Mac binaries will be happy about using the svn-library (no separate "svn" utility to worry about) - especially since a "svn" command-line utility isn't common for most normal Win/Mac users/systems. I guess most Linux distros have a "svn" utility pre-installed by default. And those building FG themselves (again, many Linux users I guess) have the option to use external svn. > 6. Both the internal and external variants seem to be using the external > svn.exe. No way. Built-in svn uses the library and doesn't depend on any external svn(.exe). If you saw svn(.exe) being called, then built-in support was disabled (either since the feature wasn't compiled into FG or since the "use-built-in-svn" property was "false"). To make such things more obvious, there's a new status message when svn starts now: it'll tell whether internal or external support is selected/used. Pull yesterday's simgear. > Do we require Windows users to have > installed svn? I have - and that seems to be what is being used. Of course not. See above. > 7. The external variant would seem to meet Csaba's design ideal, without any > apparent drawback. Except from the fact that, AFAIKS, apart from the menu > item, both the external and internal variants are the same. Perhaps that's > not the case for Linux builds. Or perhaps I'm wrong in my assessment. If the > 2 builds are in fact different perhaps the build variant internal/external > could be made conditional. > Summary. We seem to have ended up with 3 overlapping systems, all with > advantages and disadvantages. Would it be possible to combine them? It > certainly would not seem sensible to maintain all 3. I don't see 3 systems. We have _one_ terrasync-library. It can use svn-library support, removing the dependency to external command-line utilities (svn.exe). Using the svn-library provides better control: we can check error messages and evaluate the actual change log (i.e. get information about what files/tiles were truly updated). For example, with yesterday's update, I fixed the issue that errors were reported for ocean scenery areas, since the svn server doesn't have data for these (again, that's only fixed for the new library, will be available for terrasync.exe later). Alternatively, the terrasync-library can use an external "svn" command-line utility which has disadvantages though (no error or status information, and a dependency to an external utility). The _one_ terrasync-library can be used in multiple places. And that's why we have simgear libraries. There will be no (more) code duplication when terrasync(.exe) is changed to use the same library. And only about 200 lines of code remain in the original utility (for command-line and UDP processing) - trivial to maintain. There are advantages for both: terrasync(.exe) and FG-builtin support, we've had that in last week's discussion already. Using a common library ensures we only need to maintain _one_ set of sources. Integration is almost trivial. I don't see a need to trigger a "let's decide now and drop one of them" discussion. And what would you like to drop? The 200 lines of remaining terrasync? Or the 100 lines of FG integration code? If we're serious about reducing maintenance: let's start with aircraft. Why does every Airbus/Boeing/... aircraft type come with a complete copy of all major Airbus/Boeing/... systems? Many, many files in fgdata are identical copies. There's a lot of potential of improvement. cheers, Thorsten ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
