Re: [Bug-gnupod] mktunes.pl creates corrupt iTunesDB ?

[H. Langos]

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