Borg: get rid of master/slave terminology

[ThomasWaldmann]

master/slave was used a lot in the code that deals with hardlinks:

when we archive multiple hardlinks pointing to same inode (file contents), this happens:

• the first encountered hardlink is treated like any regular file: its file contents are chunked, chunks written to repo, file metadata and chunkid_list is written to the archived item.
• all afterwards discovered hardlinks referring to same inode also create a regular file item, but its source attribute points back to the name of the first encountered hardlink. these items do not have a chunkid_list and thus no own content.

so we need new terminology for this now, please suggest.

[ThomasWaldmann]

maybe:

• full hardlink vs. reference hardlink
• contentful hardlink vs. contentless/reference hardlinks

don't like:

• primary / secondary (because there might be any amount, not just 2. also, in the filesystem, hardlinks are fully symmetric)

[ThomasWaldmann]

related: #5247

background: https://www.vice.com/en_us/article/8x7akv/masterslave-terminology-was-removed-from-python-programming-language

[strugee]

canonical/alias maybe?

[ThomasWaldmann]

@strugee i know that terminology rather from naming things. but in our case, hardlink names are all equally "good" in the filesystem (only for symlinks, there is a asymmetry).

So this is rather about how borg stores these items in the archive.

[strugee]

Yeah, I see what you're saying :thumbsup:

* contentful hardlink vs. contentless/reference hardlinks

The more I think about it the more I like this pairing. It does a pretty good job communicating the idea right in the name, without needing a ton of further explanation.

[ThomasWaldmann]

Not sure why there is a thumbs down on the top post, but maybe it needs some clarification:

Of course renaming some words in an open source project does not change history nor does it improve the situation of slaves that still exist in today's world.

but keeping such negatively loaded terminology without a good reason or opposing to change them would be even worse, so let's just change them.

of course they were never meant in any negative way.

[deathtrip]

no need to inject divisive politics into open source software

[enkore]

primary/reference, stored/referencing [hardlink], first/following (<-- this is very accurate, but the terms are possibly too generic to be immediately registered as "jargon"). Contentful/contentless is very accurate and descriptive as well, but imho as far as contrasting pairs go both are pretty similar if you squint your eyes.

no need to inject divisive politics into open source software

As far as I can tell this is your first comment on a borg repo, perhaps contribute something else before trying to tell people what to do.

[enkore]

master chunks index -> primary/main chunks index (when referring to .../cache/.../chunks) and reference chunks index (in the case of borg.hashindex.ChunkIndex.stats_against -- the docstring basically calls it this already).

Renaming base branches might be a little bit annoying, but I'd suggest develop over latest, so that people are less tempted to run "the latest version" in production. Honestly "master" as a base branch name in git has always made little sense, if any. A poor default.