Register color not set saved to xml
Hi. I upgraded to 2.4 (Windows) and played a little with this new version... After that I compared the gnucash xml files before and after. I noticed that every account I have modified has slot with color not set assigned: slot slot:keycolor/slot:key slot:value type=stringNot Set/slot:value /slot Is it by purpose? I do not like the extra data in file... In addition to making file larger it also makes comparing changes harder. (I use non-compressed xml format and store the file in svn repository). Gert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: 2.4 and sqlite...
I trust that everyone who is troubled by this issue has registered that it affects them with the Ubuntu bug https://bugs.launchpad.net/ubuntu/+source/libdbi-drivers/+bug/673307. The more attention it gets the more likely it is to be fixed. Colin ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Splitting the slots table
John Ralls jra...@ceridwen.us writes: The policy that Derek declared a couple of weeks ago was that stable has to have added to it the ability to read dev's data. You're absolutely right that it shouldn't be able to write to a higher-rev's database; it should have to save as. I'm fine with this approach. I do believe that latest stable needs to read dev, however I do not belive it needs to 'write' dev. Granted, I'm not sure how we accomplish that in the current methods. We don't really have readonly status, and it's harder in a SQL solution because if you know how to read SQL you can generally write it. We don't *have* to drop XML support: There's a very capable XML query language (XQuery) and several backends that support it. To mix it with sql would require an abstraction layer, of course, but we'll want that anyway so that there aren't sql strings scattered around the codebase. It probably makes sense to provide an XML export/import facility as well. I'm happy with (eventually) relegating XML to an import/export format and removing it as a primary file storage solution. Regards, John Ralls -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Public Git repo
Hey Derek, a few notes on this, from a patch submitter's point of view :-) So.. Feel free to play with git. But don't expect your SHA history to remain 100% complete or that the repo you create will at all resemble the offical git repo, assuming we do change over to git. I think a bunch of us have been using Git (git-svn to be precise) to interact with the canonical SVN repo for a while now. The gatekeeper repo would just simplify things for us–it would move the synchronization step into one point instead of spread out among the (several? many?) Git users. Do we really have a synchronization problem? What exactly do you mean by that? I think the synchronization meant here is the regular import of SVN revisions into a git repository. Currently, a bunch of developers do this on their own systems (and especially the initial import is a lot of work), so there is some double work. I think the main advantage of having an official git mirror is that everyone uses the same base git repository: Which also allows for developers to directly pull commits from each other in an easy way. I've recently been submitting some bigger patch series consisting of multiple patches: If I could have added an url to my online git repository, the developer committing those patches wouldn't have had to bother with downloading each of the patches seperately and feeding them into git, but could have directly pulled from my repository. *THIS* is where I disagree. After we get some experience with git and after we'd figured out the proper incantations to completely migrate from svn, then we should *not* work from the gatekeeper repo but instead we should start with a fresh Master repo off SVN and make that the official repo. Do you mean a completely new repository, without history, or just redo the entire import? If the latter, I guess I agree (though if we redo the import a few times during the experimentation until we are happy with the result, a re-import might not even be needed). feature but still: GitHub is pretty cool :-) It may be cool, but we don't control it. :-/ I think the main advantage of something like Github is that people (developers and non-developers alike) can easily publish their experimentations. This can of course happen with git-svn as well, but having a public git repository makes things easier for people. Compared to svk: can’t say. I don’t know svk. :-) See, you should look into svk! SVK provides many of the features you're asking about. One of the things I totally like about git (and thus git-svn) is its history rewriting capabilities. You can just start working on a patch series, doing selective committing with git add -p, and edit patches later on using git rebase and --amend, etc. This is ideal for developing and polishing patches before they are submitted or committed. I know that there are other tools for this (I've used quilt in particular), but git just makes this so very painless and Just Work. I guess the summary is that I rather like git and that having an official git repository (either on top of an svn repository or as the canonical repository) would make it easier for people to get started on GnuCash using git (or to start using git altogether, which I can only encourage ;-). Gr. Matthijs signature.asc Description: Digital signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Where can I find the portable version of Gnucash 2.4.0
Hi, I use the gnucash2.4.0 everyday. Where can I find the portable version? Can you help me? Thanks a lot! James 2011-01-04 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
gnucash 2.4.0 slow windows startup
I have what seems to be a common issue - gnucash 2.4.0 hangs at the splash screen for 5-10 minutes before starting on windows XP. I ran Sysinternals Process Monitor while gnucash was starting and found it was going through every file name in the top level direcotry (C:\) and trying to open a reg key based on the name. After going through the entire list of file names, it started within a minute. Not sure why it's doing this or even doing anything with network access at this point. Maybe the following trace can help those that know the code: gnucash.exe 148 QueryDirectory C:\ SUCCESS 0: .idlerc, 1: .nx, 2: .qtnx, 3: .rnd, SNIP gnucash.exe 148 DeviceIoControl \Device\NetWareRedirector BAD NETWORK NAME gnucash.exe 148 RegOpenKey HKLM\Software\Novell\NetWareWorkstation\ServerCache\.IDLER NAME NOT FOUND SNIP gnucash.exe 148 CloseFile C:\WINDOWS\system32\drivers\etc\hosts SUCCESS gnucash.exe 148 RegOpenKey HKLM\System\CurrentControlSet\Services\Tcpip\Parameters SUCCESS gnucash.exe 148 RegQueryValue HKLM\SYSTEM\ControlSet001\Services\Tcpip\Parameters\Domain SUCCESS gnucash.exe 148 RegCloseKey HKLM\SYSTEM\ControlSet001\Services\Tcpip\Parameters SUCCESS gnucash.exe 148 RegOpenKey HKLM\System\CurrentControlSet\Services\Tcpip\Parameters SUCCESS gnucash.exe 148 RegQueryValue HKLM\SYSTEM\ControlSet001\Services\Tcpip\Parameters\Domain SUCCESS gnucash.exe 148 RegCloseKey HKLM\SYSTEM\ControlSet001\Services\Tcpip\Parameters SUCCESS gnucash.exe 148 DeviceIoControl \Device\NetWareRedirector BAD NETWORK NAME gnucash.exe 148 RegOpenKey HKLM\Software\Novell\NetWareWorkstation\ServerCache\AUTOEXEC.BA NAME NOT FOUND -John D ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Bug 611936] Sqlite3: assertion `gnc_numeric_check(amt) == GNC_ERROR_OK' failed
In my opinion, since this is an OS-distribution-related problem rather than a core-to-the-library problem, spending a lot of valuable dev time on fixing it seems inappropriate. I would suggest something along the lines of testing for the library bug, alerting the user if it exists (with a checkbox for Don't tell me again), and disabling the SQLite3 option if it exists. There is test code distributed in libdbi-drivers-0.8.3-1/tests/test_dbi.c that may be useful, perhaps combined with tempfile. I don't know if there is a Windows equivalent of tempfile; another option would be to disable the test on Windows builds (or only enable it for Linux, as it seems to have only surfaced with Linux builds of the library). Running test_dbi on an Intel(R) Atom(TM) CPU 330 @ 1.60GHz user0m0.028s sys 0m0.008s so it would seem that the overhead of performing the test for the bad data types: the_longlong: in:-9223372036854775807 out:0 the_ulonglong: in:9223372036854775807 out:0 the_double: in:1.7976931348623157E+307 out:0.00e+00 the_datetime: in:'2001-12-31 23:59:59' out:2001-12-31 0:0:0 the_datetime_tz: in:'2001-12-31 23:59:59 -10:00' out:2001-12-31 0:0:0 the_time: in:'23:59:59' out:0:0:0 the_time_tz: in:'23:59:59-10:00' out:0:0:0 on each start-up would not be a huge burden. Jeff On 01/04/2011 04:14 AM, GnuCash (bugzilla.gnome.org) wrote: https://bugzilla.gnome.org/show_bug.cgi?id=611936 GnuCash | SQL Backend | SVN Christian Stimmingstimming changed: What|Removed |Added Status|RESOLVED|REOPENED CC||stimm...@tuhh.de Resolution|NOTGNOME| --- Comment #32 from Christian Stimmingstimm...@tuhh.de 2011-01-04 12:14:30 UTC --- Reopening because it's a bug that seems to hit an increasing number of users, and we need to find a better way around it than just saying try a different libdbi version. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Public Git repo: Status update
The second try stopped at r15521 for reasons that aren't entirely clear to me. Trying to get it to go further with git svn rebase are met with an error message: Unable to determine upstream SVN information from working tree history. I still don't know what that means. In trying to find out, I read to the bottom of the git-svn man page, where I found a section called Caveats. The first paragraph says: For the sake of simplicity and interoperating with a less-capable system (SVN), it is recommended that all git svn users clone, fetch and dcommit directly from the SVN server, and avoid all git clone/pull/merge/push operations between git repositories and branches. The recommended method of exchanging code between git branches and users is git format-patch and git am, or just 'dcommit’ing to the SVN repository. It goes on to explain why (it has to do with the problems that SVN has with merges). Rather suggests that this approach may not work out the way we'd hoped. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Public Git repo: Status update
Hi John, On 2011-01-04, at 15:11, John Ralls wrote: […] In trying to find out, I read to the bottom of the git-svn man page, where I found a section called Caveats. The first paragraph says: For the sake of simplicity and interoperating with a less-capable system (SVN), it is recommended that all git svn users clone, fetch and dcommit directly from the SVN server, and avoid all git clone/pull/merge/push operations between git repositories and branches. The recommended method of exchanging code between git branches and users is git format-patch and git am, or just 'dcommit’ing to the SVN repository. It goes on to explain why (it has to do with the problems that SVN has with merges). Rather suggests that this approach may not work out the way we'd hoped. I have a feeling it’ll work. I’m running an import now following the instructions in Version Control with Git.[1] In it, Jon Loeliger mentions that the trick to avoiding all sorts of problems is having one gatekeeper Git repository, and many plain Git repositories which interact with the gatekeeper and each other. The main thing is that the gatekeeper repo pulls in all relevant branches, flattens them into a linear history, then dcommits them to the SVN repo. That way, all Git users will be dealing with the same commit IDs and therefore the same history. I don’t want to jinx it, but I’m hopeful. Regards, Yawar [1] http://oreilly.com/catalog/9780596520137/ PGP.sig Description: This is a digitally signed message part ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Public Git repo
Hi Derek, On 2011-01-03, at 11:53, Derek Atkins wrote: […] Apparently there are also issues with importing branches and tags appropriately, as per John's other email. There is an issue in that git-svn imports branches and tags as remote refs (roughly, pointers to the head of a branch). But I’m fairly sure I can work around that. I’m running an import right now, following the instructions in [1]. I’ll write up a description when I’m sure it works. […] Do we really have a synchronization problem? What exactly do you mean by that? This is something only git-svn users experience. Cloning a large remote SVN repository in Git is a long operation. Committing back to SVN is also a little tricky in certain situations. A gatekeeper would move all that to one point, giving Git users a Git repo that ‘just works’. It would collect all Git users’ work. Then someone comfortable with the way git-svn works could commit all the collected work into the SVN trunk or other branches. […] […] After we get some experience with git and after we'd figured out the proper incantations to completely migrate from svn, then we should *not* work from the gatekeeper repo but instead we should start with a fresh Master repo off SVN and make that the official repo. Sure, that’s not a problem. You’ll probably want to do it though, on the machine that physically stores the SVN repo, because it is a long and bandwidth-intensive operation. […] Is remembering the 'branchy development' really a requirement here? SVN certainly supports feature and bugfix branches, and we've certainly used it that way. It does have a problem that you cannot really merge multiple times, so you have to worry about multiple merges from a branch back to trunk. Multiple merges (or rebases for people doing private work) would certainly be very convenient in certain situations. […] Here's where I have to question: does this experimentation have to happen in a way that is easily publically published? In what way does the status quo not allow this? That’s a good point. I guess it comes down to how comfortable you are with creating and maintaining (i.e. periodically merging in the latest changes from trunk) multiple branches in SVN versus in Git. I find Git easier, especially the maintaining part. […] […] you still have to manually deal with code divergence.. And that is really the hard part of merging. […] Sure, merge conflicts are hard for every VCS, because they’re a human/social problem. Not a technical one. […] OpenPGP signatures on tagged commits. SHA1 verification of repo integrity (tamper-proofing, malicious intent or otherwise). Built-in author attribution–Git records both who authored the patch and who committed it to the repo. And, not directly a Git I don't think these features matter all that much, do they? SHA1 repo integrity is very cool because all your repo backups (clones) spread out across the internet can be verified just by checking that a single SHA1 sum (say, that of the latest tagged release) matches a known-good SHA1. […] I think any system has its own archana. It's all a question of what you're used to and what you know. Learning a new system always takes time. True. […] See, you should look into svk! SVK provides many of the features you're asking about. I’ll look into it one of these days but a little swamped right now with work stuff :-) Regards, Yawar [1] http://oreilly.com/catalog/9780596520137/ PGP.sig Description: This is a digitally signed message part ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Where can I find the portable version of Gnucash 2.4.0
James, I frequently use GnuCash from my USB key too. The PortableApps.com people do a really good job, but as you have stated, have not released GnuCash 2.4.0 yet. I am sure that they will at some stage. I use X-GnuCash 2.4.0 which you can download from www.winpenpack.com It is stable, and is a very good portable implementation which will play well with your PortableApps.com menu. I have used their 2.3.x beta series for many months, and am now very happy with their 2.4.0 portable version. If you are using John Haller's PortableApps.com menu, then simply create a X-GnuCash subdirectory in the PortableApps directory, and extract the winpenpack zipped X-GnuCash_2.4.0_rev11.zip file into it. When you refresh of load the menu, X-GnuCash will appear in the menu. It remembers all settings, and will run very happily in portable mode allowing you to take GnuCash on the road and run on multiple machines. If you want to run without the PortableApps.com menu or any other portable launcher menu app - then just create the X-GnuCash directory wherever you want to put it, and extract the x-GnuCash_2.4.0_rev11.zip into it. To run it, you simply run the toip level directory X-GnuCash.exe file. I am a fan of the PortableApps.com menu, so that is my preferred method to launch my various portable applications. Regards, Kim -- View this message in context: http://gnucash.1415818.n4.nabble.com/Where-can-I-find-the-portable-version-of-Gnucash-2-4-0-tp3173948p3174391.html Sent from the GnuCash - Dev mailing list archive at Nabble.com. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
