svn or arch

[Colin Walters]

On Mon, 2004-12-20 at 14:52 -0500, Dimitrie O. Paun wrote:
> On Mon, Dec 20, 2004 at 11:15:36AM -0500, Colin Walters wrote:
> > On Sun, 2004-12-19 at 23:49 -0500, Dimitrie O. Paun wrote:
> > 
> > > That's an idea that I've been playing with myself. 
> > 
> > You also have a build system?
> 
> Nothing that works, no. But I'm planning on setting one up, based
> on arch. Thinking about it, I've reached the same conclusions you
> had, which is what got me into this thread in the first place :)

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?

> Goes without saying. But before we can write one, I have to have at
> least a clue how it's going to work out.

Right; well I think in this case both would generally work.  In your
scenario, the other branches essentially just become an implementation
detail of the first branch.

> But speaking of the branches, this is what will make or break such system.
> Explicitly defining them in the .spec file is one way. More work, but:
>   1. you get more control
>   2. it's easy to add/delete/reorder things.

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.

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

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

> It seems to me the only way you are guranteed things will work is only
> if you have the RCS system handle the order in which you do the patches
> as well.

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?