Add option to restrict rsync to one file system

[fallingrock]

Added the ability to include the --one-file-system option on the rsync command.

This will prevent rsync from going into file systems on other devices and systems.

Fix #1598

[buhtz]

Dear David,
thanks a lot for this contribution. I will have a look onto it.

We need to discuss this in the team but I would say we wait until the upcoming release (round about 15th January) before we merge this. But it is just a (slow-down) feeling of myself. There is no strict technical reason.

[buhtz]

I excluded the Travis job for Python3.12 on a ppc64le machine because of an unfixed Issue on the site of TravisCI. I am in contact with their support.

Open todos for the team:

• Question: Wait until next release?
• Please review the English strings. I am not an expert here.

[emtiu]

Make the spelling consistent with the other options. Careful: Just editing here, I haven't had a chance to test this code.

[buhtz]

Thanks for the review. Do you think we should wait until the (in two weeks) upcoming release?

Make the spelling consistent with the other options.

I agree that consistence will improve code quality in most cases. But ( 😄 ) in this case my focus was more on resources. To the best of my recollection, the decision was not final, but we somehow agreed to stick to PEP8 as a minimal and in the Python world well known and accepted coding style. I would take this into account no matter that it will result in style-mixed code files.
IMHO saying "We are sticking to it because it has always been like this." won't help improving BIT in the long run.

In the end I will stick to the teams opinion here. I am very flexible about that. ❤️

[fallingrock]

Thanks.

As I said, I'm a newbie when it comes to python, so I'm not familiar with standards. I was copying existing code.

[buhtz]

As I said, I'm a newbie when it comes to python, so I'm not familiar with standards. I was copying existing code.

You did a good job. No problem. It is usual that PRs are slightly modified by maintainers.

[buhtz]

OK, I updated to the latest upstream "dev".
I did some manual tests and checked the debug output. Seems to work.

How do we decide about the naming style of the methods involved in this PR? Keep the old non-PEP8 naming convention (e.g. oneFileSystem()) or beginn with PEP8 conformance (e.g. one_file_system()) no matter that this will currently create a mix of two standards in the code? As a PEP8-fanatic I vote for the latter. 🤣

Any objects against merging this?

[aryoda]

beginn with PEP8 conformance (e.g. one_file_system()) no matter that this will currently create a mix of two standards in the code

I also prefer using underscores as word separator due to better readability even though we will have a mix for next years (or decades ;-) I guess.

[aryoda]

longest tooltip I ever saw ;-)

[buhtz]

There are much more of this from-rsync-manpage-copy-and-pasted-tooltips. That is why I introduced the wrapping, to prevent translators from dealing with line breaks them selfs.

[emtiu]

How do we decide about the naming style of the methods involved in this PR? Keep the old non-PEP8 naming convention (e.g. oneFileSystem()) or beginn with PEP8 conformance (e.g. one_file_system()) no matter that this will currently create a mix of two standards in the code? As a PEP8-fanatic I vote for the latter. 🤣

I don't like the idea of introducing a new naming scheme with for one function, so that it is different from all its siblings.

But my objection is not very strong, so you may go ahead.

[buhtz]

I don't like the idea of introducing a new naming scheme with for one function, so that it is different from all its siblings.

Sounds reasonable to me. Also might confuse extern contributors.

[buhtz]

Now I set it back to camel case. 🤣
I think it is even better to modify such PEP8 related things (nearly) en bloc .