also sprach martin f krafft <madd...@debian.org> [2010.03.27.0801 +0100]: > I would love to hear more about what you propose. Have you > considered writing this up as a paper or website with graphs to > help us get a better idea of who you'd implement this, and how > users are supposed to use this solution?
Thomas, I have now had a bit of time to read through the entire thread and the document you wrote up at http://www.koch.ro/blog/index.php?/archives/138-Design-document-for-a-patch-management-system-on-a-DVCS.html Before I forget: if you have not yet done so, could you please create a vcs-pkg tag on your blog and aggregate it on http://vcs-pkg.org/planet/? Thanks! Now to the solution you propose: I have multiple, mixed reactions to it: 1. I am excited that you are tossing about a new idea. I am looking forward to playing with it. 2. I have always disliked .topdeps, which feels like it's doing something that should and could be better done by Git itself. As a result, .topdeps feels brittle to me. Your proposal to use merge commits may be usable to replace .topdeps, but I'll need to explore it a bit more. A reference implementation would be really useful. 2b. How would your implementation represent a tree with three feature branches, where B and C both depend on A, e.g. B / upstream — A \ C 3. It seems to me that you are proposing to store meta information in plain files in meta branches (cf. .topdeps). If at all possible, I'd say we should avoid touching the worktree altogether, but to design a protocol by which all the information we need is kept in the Git DAG and its objects. 4. Rather than a meta branch, if we had a means to store and update information for each branch, we could solve the problem and store .topmsg, as well as the top-bases/* pointer in there. A rudimentary implementation might be using Git notes, e.g.: walk up the ancestry until you find a specially-formatted Git note, and use that as branch meta data store. If the data change, then write a new note to the top-most commit. 5. It occurs to me that what we want to implement somehow should get rid of .top* files and top-bases/*, and instead allow us to track "commits" at a much higher level. E.g. a branch creation is a commit, updating feature branches is a commit (I see no reason to allow updating of single feature branches independently, but would say either all or none), integrating feature branches is a commit. The way to represent that might be using a meta hierarchy with the merge commits you suggest, but which also keep ancestry. 6. One of the main issues I have with TopGit is that it's not really possible to consistently tag a release with all its branches. E.g. you need to tag all branches, and all top-bases at the time of the TopGit tag, which appears brittle itself. If indeed we can find a method where a single commit represents the entire state of a tree+feature branches at a time, and one could generate all kinds of patch formats from it, and even fork the tree with all feature branches from this point, then that would be splendid. -- .''`. martin f. krafft <madd...@d.o> Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduck http://vcs-pkg.org `- Debian - when you have better things to do than fixing systems "no work of art ever puts forward views. views belong to people who are not artists." -- oscar wilde
Description: Digital signature (see http://martin-krafft.net/gpg/)
_______________________________________________ vcs-pkg-discuss mailing list firstname.lastname@example.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss