4 ms·
Contrived but possible: src/share/test.cpp share/src/test.cpp Also certain implicit build systems, rely on the hierarchy to know what is parent, and what is c
by malkia 17y ago
Contrived but possible:
src/share/test.cpp
share/src/test.cpp
Also certain implicit build systems, rely on the hierarchy to know what is parent, and what is child. You lose that with sets.
I still think it's cool idea, but not for all of your documents...
Besides how would you deal with sharing, inheriting security attributes, etc?
If I have
share/test/something.cpp and share is shared to everyone, would
test/share/something-else.cpp got shared too the same way as the first one?
- dejan 17y agoGood points. but that form of structuring has been imposed by the nature of directories/files. I am not sure what the right solution would be for that case, perhaps internal tags for a set, but that would make things complicated. In the nature of sets, maybe this could be done: "Source Code", "Shared With XYZ", "Application1" Sharing could be defined on the set, "Shared With XYZ" is a tag that when defined could have the permissions etc. When a file is "placed in it", it is automatically shared. We need to get detached from hierarchical thinking to see the possibilities, which is difficult as it is all present.
- rleisti 17y agoMaybe some sort of namespacing on tags would fix that; ie. so that your 'conf' tag for a software project doesn't conflict with the system 'conf' tag, which may have a different set of permissions.
- silentbicycle 17y agoIn practice, you would probably have different filesystem tables, so that system:conf+share/filename would be distinct from projects:conf+share/filename. The meaning of the same tag may be different in different contexts.