svn or arch

[Dimitrie O. Paun]

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.