[MERGE] include tortoise icons in windows binary distributions

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark Hammond wrote:
>> ^- Using 'chdir()' is rather ugly. Can't you just do:
> 
> "rather ugly" is getting fairly subjective given the intent was always
> relative filenames, but I've changed it.

Changing the working directory is a global state change, and IMO should
be avoided when possible. I don't believe we ever 'chdir()' in bzrlib
code, though the test suite is known to chdir() quite a bit.

It is just something I avoid unless it is really necessary.

I'm sorry if it feels I'm nitpicking or being especially difficult. I
think the fundamental issue is that I'm uncomfortable with what is being
done, and only allowing it for pragmatic reasons. But it keeps tripping
over the "why are we doing this". For example, you are making
incompatible changes to how things are being packaged, but I'm only
seeing 1/2 of it, because I'm not seeing any of the TBZR changes that
accompany it.

So the problem basically boils down that you have control over TBZR, and
thus you can do it as you see fit. But I'm uncomfortable with it
happening inside of the bzr codebase. I'll try to be a bit looser with
stuff that falls under your coverage.

>> I'm a bit uncomfortable using a pickle, as it is a known unsafe data
>> structure.
> 
> Unsafe how?  The pickled bytes are being written to the executable - if we
> are concerned about the implications of random/targetted bytes being changed
> in the executable, the behaviour of pickle wouldn't be near the top of the
> list ;)

So... the only place we use pickle inside the bzr codebase is to write
out lsprof Stats objects (if you name them something other than .txt and
.callgrind). I believe the format is reasonably stable, but it is close
to just op-codes for the python interpreter, so you can run arbitrary
python code at load time. Also, I've used it in the past for other
projects, and if you serialize anything other than basic data
structures, you run into a lot of problems if you modify the associated
code. (Pickle an instance of a class, and if the code for the class
changes the pickle will fail to load. Or if you move a class around,
rename it slightly, etc.)

You're only pickling a dict, and you have tight control over it, so your
specific use case is probably fine. It isn't something I would do for
any bzr structures, but again, this is for TBZR.

...

> Yes, we discussed this via private email over the last couple of days and
> explicitly agreed we would go for the lowest impact patch for the 1.7 cycle
> and look at splitting setup.py for 1.8+.  I'm surprised you feel the need to
> keep reminding me about your longer term desires in this area, but again for
> the record, I understand and fully agree.
> 
> Cheers,
> 
> Mark

I'm also sorry that I'm the only one speaking up on your patches, as
then it seems I have a personal vendetta against you. I honestly don't,
and I'm happy seeing TBZR developed. It would be nice if Robert or
Martin would mention how they feel, so it isn't just my opinion.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjAITgACgkQJdeBCYSNAAOI/QCgrFgQZjnwqMaG6fzevm4APQHF
dUEAnjDXCVBFqlzV4SZYxDUP5JLccDDd
=efTZ
-----END PGP SIGNATURE-----