Re: How to cope with patches sanely
On Wed, 20 Feb 2008 11:17:29 +0100, martin f krafft <madduck@debian.org> said:
>> You hack in the sloppy branch. You merge change sets from the sloppy
>> branch into the feature branches. You merge the delta from the
>> feature branch into the integration branch. In my experience, there
>> is usually no new mess -- since you are only merging the delta in the
>> integration branch; the step you took earlier to deal with the mess
>> usually still apply.
> So what about dependencies between feature branches? Aren't you just
> taking extra care to do it right manually, when in fact the system
> should take care of it for you?
I have to take care of it manually once. That is the first time
I setup the integration branch that merges in changes from the
overlapping feature branches. This is not a big deal, because the
human has to spend some time disambiguating the overlap.
It is critical to me that I never have to spend that time
again -- and in my case, I never do, since future non overlapping
changes (like, say, a new upstream release) produce deltas that apply
to the feature and integration branches seamlessly. I never have to
rethink or redo any patches.
cd upstream-working-dir
tla_load_dir ../new-upstream-branch
cd ..
arch_upgrade
and then update the changelog, build, test, piu-parts tests, other
tests, upload, etc.
>> > But I may want to see the differences from upstream nicely
>> > separated into patches, rather than whole chunks?
>>
>> You mean you do not want to see the differences between a feature
>> branch and upstream as one chunk, but nicely segregated in smaller
>> pieces?
> 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.
>> Not really, unless your feature branches are poorly chosen. Each
>> feature branch, in my packages, represent onlogical feature that
>> belongs in the same patch (series).
> Right, but given five feature branches, once you create the diff.gz,
> there are no more patch*es* or series anymore, there's just one huge
> file with everything. Why should we lose the logical separation
> between features you have in the VCS when creating the source package.
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.
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 find comparing feature branches to each other as useful as
comparing them to upstream, personally.
manoj
--
Welcome to the Zoo!
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: