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.
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.
Correct.
So you generally wouldn't have conflicts
merging a new version into your upstream branch. The conflicts would
really be in your patch-branch.
Right. And here you'd to a regular merge and commit, which is something
that's more or less familiar to people.
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.
Heh, assuming such projects are indeed maintained in arch, of course :)
> 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.
But that can be scriped, no? And a script should be able to figure this
stuff out from continuations, right?
--
Dimi.