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.
