svn or arch

[Colin Walters]

On Mon, 2004-12-20 at 18:24 -0500, Dimitrie O. Paun wrote:
> On Mon, Dec 20, 2004 at 03:51:21PM -0500, Colin Walters wrote:
> > > 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.
> 
> Yes, but this does not mean that SRPM is a convenient way to develop
> patches. It's a good way to package and distribute them, not to develop.
> I think that such a system should allow for easy _development_ of said
> patches too, not just packaging. Once developed, the packaging should
> happen automatically.

Ok, I generally agree; however, let's dissect the process here.  I
assert that merging the patch-branches at build time is in most cases
better than merging at import time, and no worse in general.

Let's say you have a package, with two simple patches to it.  You want
to import a new minor upstream version.

You do e.g.:

make importpkg PKG=foo-1.2.tar.gz
$RCS commit -s 'new upstream version'

This goes off and unpacks foo-1.2.tar.gz, imports it into the upstream
branch (there should be no conflicts), adds it to the lookaside cache,
etc.  You explicitly do *not* modify the spec file here.  

Then later when you do a "make build", if your patches apply cleanly
(and you expect them to, this is just a new minor stable release), then
there's no further interaction.  You didn't need to babysit a merge
which went cleanly.

Now, let's say that you maintain a package with several major patches
(e.g. kernel).  In this case, you do:

make importpkg PKG=linux-2.6.22.tar.gz
$RCS commit -s 'new upstream version'

The same as above, so far.  But now you know that you have to merge in
your branch-patches.  So you do:

make merge

This goes off and for each Branch: in the spec file, tries a 3-way
merge, and if it conflicts (or perhaps is just too fuzzy), you get
dropped into a directory with the normal .rej files, etc.  You resolve
these conflicts:

$EDITOR mm/mmap.c.rej
...
$RCS commit -m 'fix exec-shield conflict'

Note this commit goes into the exec-shield patch-branch as a merge from
the new upstream version.

You repeatedly type 'make merge' until all conflicts are resolved.

Finally, you do:

make local-build

You install the resulting RPM, dogfood it on your laptop a bit, then do:

make build

That goes off and pushes it to the real build system just like the
previous simple case; it goes through test suites, etc.

So essentially what I'm saying is that in the simple case, you shouldn't
need to do an explicit 'merge patches' step.  In the complex case, you
generally *know* you need to merge anyways.

I'm sure there are packages which fall in between here - e.g. their
patches only conflict on new major upstream versions.  But even there,
is it so bad for you to try the test build and get a result back in 20
seconds that it failed?  Surely that's a small part of the time one
would spend actually resolving the conflict and testing the new upstream
major version.

> > 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.
> 
> But that can be scriped, no? And a script should be able to figure this
> stuff out from continuations, right?

It could be scripted, sure.  I just like making important things like
this very explicit.