From @ouabache on Wed Mar 21 2018 21:59:29 GMT+0000 (UTC)
The use of UUID’s as directory names is not human friendly at all.
librePCD.org__Resistors__resistor is as unique as 75372c18-3ba4-42e8-b3b2-2eb5039d4
and a lot easier to follow.
Anytime a UUID is presented to the user it should be mapped back to its author,library and component names.
John Eaton
Copied from original issue: https://github.com/LibrePCB/librepcb-rfcs/issues/11
From @hephaisto on Wed Mar 21 2018 22:13:29 GMT+0000 (UTC)
I agree that it is not user-friendly when working on the files manually.
However, as far as I understand, the general idea is to reference anything by its UUID, so it is consistent to do so also on the directory level. Also, there would be need for a big lookuptable that maps some arbitrary tuple of attributes to an UUID.
If this is really a big deal for usability, it would be easy to write a script that creates symlinks from a name to an UUID.
If librepcb strives to as compatible with version-control systems as possible, then having human-readable paths is really important as that’s what shows in reviews for human consumption.
It also messes up version control diffs though when renaming a library element and changing it at the same time. What’s worse, it causes conflicts when two people create pull requests changing the same library element, where someone renames it and the other person changes another property in the element itself.
I don’t currently see the UUIDs as a big problem, since managing them will usually happen through the LibrePCB editor. Finding things can be done by recursive search tools like grep or rg, and an option for opening a library element in the filesystem is alread implemented in LibrePCB.
The advantage of UUID based directories is that LibrePCB can deterministically know where a library element is stored just by looking at the UUID. The name will never change. This allows users to change the name at will, without any consequences regarding the filesystem, version control, or anything like that. It also means that we are free to use any characters in the library element name, without having to consider support in file system paths.