svn or arch

[Colin Walters]

On Mon, 2004-12-20 at 15:29 -0500, Dimitrie O. Paun wrote:
> 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>

There are a lot.  They all have different goals; of course we're really
talking about redesigning SRPM, not just a different way to turn 
SRPM->RPM.  But I'm sure all of these projects will have input.

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

Note that this approach is exactly analogous to how SRPM works now with
patches; the patch is applied at build time.

I don't think speed is an issue.  In the initial use I'm imagining,
you'd be just importing largish snapshots of new upstream versions into
the upstream branch, and your patch-branches would probably only have a
few changesets at most. 

As for error reports; I don't see how this would be a regression from
the current SRPM mechanism, anyways.  I think what you really want is an
easy mechanism for doing test builds.  Your patch may seem to apply
cleanly but produce a build error later.

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

Well, I was thinking that you'd have an "upstream" branch that would be
as pristine as possible, just like how we try very hard right now to
have pristine tarballs.  So you generally wouldn't have conflicts
merging a new version into your upstream branch.  The conflicts would
really be in your patch-branch.

One cool thing of course here is that with a distributed RCS like Arch,
you don't even have to maintain the upstream branch yourself; your
package patch-branches just branch from upstream's archive directly.

> Eh, devil is in the details though. The trick is to 'just use' the
> RCS as much as possible IMO. 

Yeah.

> And I clearly have arch in mind for
> this task :)

I'm an Arch fan too; however, I think if we designed this correctly you
could plug in pretty much any RCS that has history-sensitive merging.
At least ideally.

> If reordering is not a concern, it seems to me that branch-from-branch
> method I'm proposing would be preferable, no?

Hmm.  Maybe.  I don't have a very strong opinion on it.  My main concern
is I want to make it easy to find out what the package delta is versus
upstream and manipulate that.  If I have to trace through branches of
branches, that becomes a bit harder.