On Wednesday 20 February 2008 05:22:08 pm Manoj Srivastava wrote: > > Yes, just like I want to have feature branches instead of one gigantic > > debian branch. > > I use my CSM to provide me the changeset: > baz diff <branch A> <upstream> > > Indeed, I can get diffs between branch A and branch B -- how do > you do that using quilt? Get diffs between arbitrary branches? Trivial > using my scheme. we discussed this on irc, but for posterity i'll say it here too: the you could think of each individual quilt patch as a "feature diff", thus the quilt equivalent of a "feature branch" would be the (ideally) pristine source plus the diff in question. so you have explicitly the comparison between the feature branch and the source by opening the quilt patch in a pager. to compare the "feature branches" with each other, you could just do something like "interdiff patch1 patch2". > Not every need needs be satisfied in the source package. If I > ship the metadata for arch in the source package, and there is the arch > grab file that is in the control file, someone who wants to see the > history, or how feature branch A stacks up to feature branch C, can do > so using the SCM stuff. i think this discussion is in part to propose a system that can serve as a layer of abstraction between $developer's $scm implementation and some common format/methodology, so that when $otherdeveloper comes along and needs to muck with the package (say, for a security NMU), they don't need to have such knowledge, apart from "fakeroot debian/rules patch", or possibly even just "dpkg-source --patch -x $dscfile" if a common source format could be established for build-time patching tools. > It is not like quilt provides easy means to compare different > feature branches -- let alone how the current feature branch C > compares to the second from last revisions of feature branch F. i think that would be: $vcs get 2nd from last rev of quilt_patch_F > tmpfile interdiff quilt_patch_C tmpfile sean
Description: This is a digitally signed message part.