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.
