Hi Richard, On Tue, Jun 16, 2009 at 11:46:47AM +0200, Richard van den Berg wrote: > On Tue, June 16, 2009 00:44, H. Langos wrote: > > My first idea now is to > > strip the iTunesDB of the stuff that is optional. > > Absolutely. I was thinking the same thing. More along the lines of setting > all titles, artists and albums to a single character. But leaving out > complete mhods makes a lot more sense.
Shortening might not change a lot if memory management is "generous" and memory alignment of those objects occures on something more than word borders. But you could find out simply by taking the first not-ok state, shorten lots of attributes and try again if the newly genereated iTunesDB works. That would be valuable information regardless of how we solve the problem in the end. > > Last friday I wrote a patch that will not add them if they are empty. I > > just need to commit it. > > Please do, or send me the patch. I'm planning to work on it tonight, and > it would be good if my code did not conflict with yours. It's a simple one line patch .. I already commited it. > If it works, I'll probably make a switch for it to mktunes.pl. That might be a good idea. My patch only takes out one attribute for one file format. Having a universal switch for big collections could be a good idea. The code there could weed out the not-so-important fields and maybe limit the size of others. Kind of a last-resort switch for big collections. > > BTW: I've started converting the CVS gnupod repository into a git > > repository. > > If Adrian agrees I'd like to give you write access to it. > > That would be very helpful, thanks. I now keep my custom patches in files, > and reapply them when needed. To do that you don't even need write access. You simply clone the upstream repository, create your own local branch and from time to time you pull the changes from origin and either merge the master into your private branch or rebase your private branch onto the HEAD of the master branch. Lets hope Adrian finds time to answer some of my questions so that I can compete the transition to git realy soon. > After rcs, sccs, cvs and svn git will be the 5th versioning system I'll > have to master. :-) You will love it. I worked with rcs and cvs before but git simply feels better. Working with local branches makes things also much easier. And I actually _enjoy_ working with git. Something that never happend with CVS. Just one example.. When weeding out those empty desc attributes, I inittially commited the patch with a '== ""' comparison. Comparing a string numerically with the empty string (Did I mention that I hate weakly typed languages). Then I did some other changes and, commited those. Then I realised that the comparison was wrong, reverted that commit fixed the problem once more. Now my commit history was correct but looked messy. 1. wrong fix 2. some other change 3, revert of 1. 4. correct fix git-rebase to the rescue! You can give it a past commit and it will "replay" the patches and commits from that past commit to the current state. So I used "git-rebase -i" to edit the requence of patches, simply took out the initial wrong commit, and the revert and only left 2. and 4. in there. I also could have "squashed" 1.,3. and 4. into one commit. Or instead of reverting in 3. and commiting a new patch in 4. I could have used rebase when I realized that 1. was wrong. I could have used rebase to replay both commits but "pause" after applying 1. before commiting it, manually "fixed the fix", and then continue that git-rebase. With git you are realy in control of your repository and if you screw up you while manipulating the local history can even reset those changes (before you run garbage collect to remove unaccessible objects from the git repository). cheers -henrik _______________________________________________ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
