On 12/10/06, Torgil Svensson <torgil.svensson@xxxxxxxxx> wrote:
What if we use linus "module" file concept and allow the link objects to track subtrees? An object may look like this: commit: <SHA1> link: <SHA1> /path/to/remote/tree/or/blob
Special customer release for a specific HW platform --------------------------------------------------- "Lib1/lib1.h" -> "<lib1-commit>/headers/lib1.h" "Lib1/lib1.so" -> "<build-environment-commit>/i386/Lib1/lib1.so" "App1_binary" -> "<build-environment-commit>/i386/App1/App1_binary"
This example is somewhat complex since the build for lib1.so and the header-file might not has gone through the same commit on the lib1 subproject. Consider this example: lib1 - library project (source tracking) ------------------------------------------ Blob: /src/lib1.h app1 - application project (source tracking) ----------------------------------------- Link: /headers/lib1.h -> <lib1-commit1>/src/lib1.h build1 - Build project (binary build tracking) ------------------------------------ Link: /src/lib1 -> <lib1-commit2>/ Link: /src/app1 -> <app1-commit>/ Blob: /i386/lib1/lib1.so Blob: /i386/app1/app1 Release Project (file compilation tracking) ----------------------------------- Link: /headers/lib1.h -> <lib1-commit3>/src/lib1.h Link: /bin/lib1.so -> <build1-commit>/i386/lib1/lib1.so Link: /bin/app1 -> <build1-commit>/i386/app1/app1 <lib1-commit1>, <lib1-commit2> and <lib1-commit3> should be the same, dictated by the app1 project. Can we enforce this in the modules file or should the different supermodules fix this somehow using scripts/hooks? How do the super-projects in this case get access to the blobs pointed by the links - transparent or explicit in the build-process? //Torgil - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html