also sprach Russ Allbery <[EMAIL PROTECTED]> [2008.11.22.1953 +0100]: > It's also not an issue if you resolve conflicts between branches > by making one branch depend on another, which in reading between > the lines I think is the approach you're taking (although I could > be wrong).
You got it, that's the beauty of TopGit. And I guess it's where Manoj and I diverge. If we have two independent topic branches, which modify two adjacent lines (and thus conflict with each other), you have to resolve the conflict at some point: (a) Manoj keeps the branches independent and resolves on integration, which has to be done once, and once more for everytime that the context of either of the two patches changes. (b) I am experimenting by making the branches dependent on one another, thus resolving the conflict there once, and once more every time the context changes. Manoj's branches are pristine in that they can be folded and submitted upstream independently. This is not trivially possible with my approach, and it's arguably a shortcoming. However, the dependency is needed if you want to export a quilt series. Manoj takes his approach further into debian/topics, which are patches that are just like the branches independent of each other. As such, they can be used independently and applied independently, but you cannot use them to patch the upstream source without resolving conflicts then. However, debian/topics is only a reference and never used in the source package, because the Debian diff.gz provides the complete patch across all topics, after Manoj did the conflict resolution. In the end, I don't think either approach requires more conflict resolution than the other. The difference between them is that (a) Manoj provides you with the patched source and each topic patch nicely independent of each other, which serves two purposes: first, the patches document the features/fixes added to upstream, but they do not document how exactly the topics were combined to create the source. Second, the set of patches are against pristine upstream and can thus be independently used, which is convenient to those who want to pull single topics, but gets less convenient (but not less flexible) with increasing number of topics someone want to pull. (b) I provide the pristine source and a quilt series in debian/patches, which applies, and thus gives very specific information about how the upstream source gets altered before building the Debian package. The downside of this approach is that upstream (or another distribution) cannot trivially extract patches. If the feature branches are independent, then it's as easy as with Manoj's approach, since each patch in the quilt series can be applied by itself. If the features functionally depend on each other, e.g. B needed the infrastructure put in place by A, then it wouldn't make sense to obtain B independently anyway. But if A and B are functionally independent but simply overlap, then to obtain B, one has to subtract A, so it's less trivial to obtain B independently. I think (b) is the compromise that serves me best. If I ever had an A/B pair that are functionally independent, but which overlap, then I could try to create a patch C, which makes trivial changes (like adding a comment) so that A/B can depend on it and no longer overlap as a result. Obviously, this is still not always possible. -- .''`. martin f. krafft <[EMAIL PROTECTED]> : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems "solange man nicht die moral des christentums als kapitalverbrechen am leben empfindet, haben dessen verteidiger gutes spiel." - friedrich nietzsche
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