Deterministic UUIDs

[fabiopelosin]

I have been thinking about doing something similar to this for a while and the xUnique revived my interest on this feature.

Context

The algorithm used by Xcode to generate UUIDs is not known. Xcodeproj currently has a conservative approach at tries to make UUIDs which are similar to those generated by Xcodeproj while checking if a duplicate already exists in the project before using a new one. A duplicate UUID would corrupt the project.

xUnique proves that Xcode accepts UUIDs regardless of the length and of the type.

Proposal

• Generate longer UUIDs
• Derive the UUID from a hash of the attributes of the new objects and the UUID of the parents. This would greatly reduce the noise when recreating a project from scratch.
• Add a subcommand to “normalize” projects.

Alternative

• Prefix UUIDs with a string to namespace the ones generated by Xcodeproj and avoid the need to check for collisions.
• Use a hash of the timestamp for the UUIDs.

[fabiopelosin]

@alloy ping

[fabiopelosin]

This feature could be enable optionally. So only clients which are sure that they won't generate projects with duplicates can enable it. This approach could be very simple and yet very effective at the same time.

[segiddins]

30,000 line merge commits really aren't fun, so this would be 👍

[alloy]

ZOMG I like this idea!

[alloy]

(It would be nice if we could still conform to the format of Xcode’s UUIDs, though.)

[AliSoftware]

👍 ^ 💯 !!

[AliSoftware]

Instead of generating deterministic UUIDs, couldn't we keep UUIDs of existing files and object references in some hash when reading the project, and reuse the ones already assigned when regenerating/ resaving the project, or sthg like that?

I mean based on @fabiopelosin 's introduction in this issue it seems that Xcodeproj already "has a conservative approach" and "checks if a duplicate already exists in the project before using a new one", but when CP regenerate the Pods.xcodeproj project it seems that it does not "open the existing Pods.xcodeproj project then adds and/or remove new/deleted files, and save the project again" but it seems that it wipes everything out and starts from scratch, right? (Or maybe I'm mistaken and sthg has changed in the last versions that I missed?).
If it's the case, the issue is more with CP's use of Xcodeproj than with Xcodeproj itself, obviously.

[fabiopelosin]

@AliSoftware I considered your approach as well. It requires to solve a similar problem to this proposal: identify which attributes determine if the UUID of deleted object should be used for the newly created one. It could also have performance implications.

The proposed approach has also the benefit of leading to consistent UUIDs in more cases.

From CocoaPods side it is just much simpler to generate the project from scratch than trying to change a existing Pod project to a consistent state. Also from experience I know that it would be lead to problems wanting to customize the Pods project in creative ways. Anyway I have a patch with incremental editing in a PR. I just changed my mind later.

[AliSoftware]

@fabiopelosin I was not implying to change the existing Pod project, but merely to read the existing project to memoize used UUIDs and reuse them when generating the new one from scratch.

E.g. open the existing project, enumerate on all the objects in the project, create a hash / lookup table — whose keys are some hash function of each Xcodeproj's object and the value their UUID — then upon regenerating the new Xcodeproj (from scratch), use the UUID from the previously built lookup table if there is a match (thus reusing the same UUID if the object is exactly the same — has the same hash — as before) and generate a new UUID if not.

But I guess that's quite some work and a hit in performance just in order to keep the generated UUIDs unchanged and with an Xcode-like format… instead of using our own custom format. I'm probably too afraid of what Xcode would do with UUIDs that won't match the format it uses internally. I guess I should trust xUnique POC more ;)

[AliSoftware]

Ok tried and played with xUnique and I'm now convinced 😉

[mrousavy]

I think I'm experiencing an issue with deterministic UUIDs here, does anyone have an idea what might be wrong here?