Merge lp://staging/~a1s/brz/3.2 into lp://staging/brz/3.2

This includes changes from the merge proposal https://code.launchpad.net/~a1s/brz/3.2-windows-test_osutils/+merge/412025

The other thing hat has been fixed after that is passing the regression tests run by brz selftes test_config.

Revision 7568 is not ready to be merged, sorry. It went OK on Windows, but then I found that it's broken on *nix. I'm going to fix it and make another commit in a day or two.

Ok, now this is tested on Linux/Python 3.10. Both test_config and test_osutils run without errors.

On Windows, test_config runs without errors, and test_osutils has two failures in test_osutils.Test_CICPCanonicalRelpath. Those I want to leave for another time.

I've replied to all questions asked here in diff comments.

Please check if this can be merged now.

It would still be useful to split this merge proposal into several separate ones, e.g. one with the filesystem type changes, one with the symlink changes, one with the config changes, one with the walkdir fixes, etc.

> It would still be useful to split this merge proposal into several separate
> ones, e.g. one with the filesystem type changes, one with the symlink changes,
> one with the config changes, one with the walkdir fixes, etc.

I surely see the point in submitting each atomic change in a different merge proposal.

The problem is, I'm not sure the regression would run with just one of those things changed and others left as is. Perhaps I would try that if the merge proposals are reviewed in hours, not weeks.

At the moment, my first priority is getting qbrz work on Linux, and then I'm going to take a pause to handle my RL issues. I'd really like to have Breezy working on Windows, but right now Bazaar 2.6 covers my needs there.

> > It would still be useful to split this merge proposal into several separate
> > ones, e.g. one with the filesystem type changes, one with the symlink
> changes,
> > one with the config changes, one with the walkdir fixes, etc.
>
> I surely see the point in submitting each atomic change in a different merge
> proposal.
>
> The problem is, I'm not sure the regression would run with just one of those
> things changed and others left as is. Perhaps I would try that if the merge
> proposals are reviewed in hours, not weeks.
The delay in reviews is actually a function of the size of the merge proposals; for the smaller ones that are easy to understand the full implications of, I usually just process them as part of my regular email reading but for larger ones I need to schedule some time to sit down and understand them.

Jelmer

I do understand. I'm sorry there are too many things to address at once.