bzr-windows team mailing list archive

[Adrian Wilkins <adrian.wilkins@xxxxxxxxx>]

>> - We should support installation in all releases from XP to 7, but not
>> on anything older than that, like 2000 or 95.
>> - We should probably start making NTFS a requirement, since there are
>> filesystem operations that only work on NTFS and not on FAT32 and
>> older which we could benefit from. In a couple years we could drop
>> support for XP and 2003 and start benefiting from the transactional
>> filesystem support that exists in Vista and newer to make certain
>> operations cheaper (this is already exposed in pywin32, AFAICT).
>
> Are you serious? Really?
> This sounds like a very BAD joke for me.
>

FAT32 still gets used enough as a "transfer" filesystem on dual-boot
systems to be popular.

I've never owned a WindowsCE device, but I wouldn't be surprised to find
it gets used a lot there too.

I'm all for supporting newer filesystem features - where they are
available. But if you can do things at an acceptable cost in a platform
agnostic manner, you should stick to it, and keep the code as simple as
possible.

Although Windows does sometimes need some extra loving, I remember how
much faster bzr got when the C extensions received some attention for
Windows.

In particular, supporting the linking features of NTFS6 would be great,
but isn't going to be useful for the majority of installs until Vista
and "7" become more mainstream. Business just isn't going to go there
until "7" is well into it's patch cycle.

I'd much rather see filesystem locking get sorted out first. It makes
the core "shelve" useless on Windows, which also makes useful plugins
like "pipeline" useless.

Rather off the topic of installers though..

+1 on making TortoiseBZR off by default.

Leave qbzr in ; 14MB is not such a large installer ; TSVN is 19MB and
even SVN CLI is not far off 5MB.

Add the xmloutput plugin.

This uses parts of the standard library that don't get bundled in
library.zip currently, so even if you install it later, it doesn't work
with the "exe" distribution. It's required for the Eclipse plugin to
work, and Java developers are not an insignificant minority. I'm either
having to use the Python-based distribution (which involves more
installers and dependencies), or I have to repack library.zip to add the
right libraries.

Compress library.zip

Just a suggestion ; currently the archiver is set to "store". If you use
normal compression, this file shrinks to 5MB instead of 15MB. I'd be
surprised if the difference in startup time was noticeable. It might
even reduce startup time, I'm sure that decompressing ZIP is faster than
disk I/O on modern CPUs.