svn or arch

[Dimitrie O. Paun]

On Tue, Dec 21, 2004 at 11:32:50AM -0500, Colin Walters wrote:
> 
> 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.

I'm afraid that the more we discuss, the less I like this merging
at build time. Yes, I agree with you that common cases should be
simple, but I see very little reason why what I'm proposing should
be any more complicated. However, you have two big advantages the
way I'm proposing, namely:
  A. You get to *see* the source that's going to be built.
     This is very, very important, not the least being that it's
     the way people are used to. I want to be able to look at what 
     is going to be built, maybe make sure a patch has no semantic 
     conflicts, etc. Besides, what do you do when you
     have a problem? You need to look at the _exact_ stuff that's
     being built, which will not be readily available if you 
     patch at built time. Moreover, one typically tries to catch
     (and fix) problems as early as possible in the process, not
     push them to a big operation that will eventually generate
     a source that I've never seen.
  B. The whole point of this exercise is to try to preserve the
     individual patches in the SRPM as they are now. I think this
     provides value, and it's a worthwhile effort. However, having
     all this mix-in branches that merge two patches that interact
     will result in having only one patch for the two features.
     This is contrary to what we're trying to achive, and I see no
     reason for this limitation.

Now, let's look at the process that you propose, see if it would be
any different if we are to maintain the changes in interdependent
branches:

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

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


Agreed. Now, there is nothing stopping this process from working
*exactly* the same if we are to use the branch-from-branch approach.
Of course, you don't need to read the 'Branch:' from .spec file or
anything like that: the RCS already knows that branch B is derived
from branch A. Less housekeeping.

-- 
Dimi.