reverts if object key does not change wouldn't work

[discentem]

Right now objects are stored like pantri/repo/go1.18.3.darwin-arm64.pkg but this is might not be unique enough as we are just relying on filename. We should consider storing stuff like pantri/path/to/object/HASH_GOES_HERE/object

[natewalck]

I'm not sure if this is truly necessary.

With git, you have multiple versions of the same file with the same name, in the same path.

With binary storage, you generally don't have this issue, mainly due to the fact that it is impossible to have two files of the same name in the same directory. (Plus, I'd categorize that as a user error).

I think the paradigm of having Firefox.dmg be multiple possible versions of Firefox is one that we don't really want to promote. Firefox-101.0.1.dmg should be preferred and suggested.

Let's keep it simple until we find a specific case where we need to get fancy.

[discentem]

Definitely appreciate the reply/explanation and agreed. I think I was over thinking this. Closing out until we find some edge case that would warrant this.

[discentem]

@natewalck @radsec and I were discussing this a lot recently in Slack. We're split on if this is necessary but we all agree that if we implement it should NOT be with a hash in the path as this would break Munki and other known use cases for Cavorite.

One suggested solution for s3 by @radsec was object versioning. We could add a field to .cfile to track this.