On Mon, Dec 20, 2004 at 03:08:57PM -0500, Colin Walters wrote:
Cool. It definitely seems to me there's a lot of interest in a
new
build system; there's mach, beehive, rookery, the fedora.us one, and
probably tons of others. Maybe we should make a new list for this; or
maybe use the RPM list?
Maybe a Wiki? I wasn't even aware there are that many around <g>
Well you need to define them somehow. My idea was that the build
system
would automatically do a 3-way merge *at build time*, based on the
Branch: headers. If that failed, it failed the build and kicked it back
to you, just like it does now for applying a patch.
Yes, but that would be awkard to work with. On a large project, I think
it would be slow, and it would be hard to maintain sane error reports.
> However, it's still not clear how it's going to work.
Without merging
> patches, how do you know they don't conflict?
You'd just build on your local machine for testing, or use a 'scratch'
area in the build system.
Yeah, I can see that it can work, question is if this is the workflow
that you want. If I update the upstream package, I want to handle merge
conflicts at that time, not at build time. But maybe this is just me,
used to a certain way of doing things.
> Even if they don't, they
> may introduce fuzz for the others.
I think you'd want an option to disable fuzzy patch application for
whatever RCS is in use; or maybe you get a build warning if there's a
too-fuzzy patch; e.g. over 5 lines displacement? This is just detail
though.
Eh, devil is in the details though. The trick is to 'just use' the
RCS as much as possible IMO. And I clearly have arch in mind for
this task :)
It's not clear to me that ordering is really all that useful if
we make
it easy to create new branches that merge from two conflicting branches.
When would you want to reorder patches other than to work around
conflicts?
If reordering is not a concern, it seems to me that branch-from-branch
method I'm proposing would be preferable, no?
--
Dimi.