[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 ..
 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.

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: