gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] How to avoid conflict when backporting/cherypicking


From: Milan Cvetkovic
Subject: Re: [Gnu-arch-users] How to avoid conflict when backporting/cherypicking
Date: Tue, 17 Aug 2004 13:03:13 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425

Matthew Dempsky wrote:

Thanks for responding.

In an ideal world, the bugfix-to-be-backported would have been handled
in a seperate branch which when completed the newer version merges
into their tree and, likewise, the old version maintainers could
merge.

Sometimes you discover a bug that has already been fixed in one of the newer releases, and customer wants only "patch" or "service pack," and customer is always right, right :-)


However, this isn't always an ideal world and rarely do people use
arch that way (hopefully this will change soon).  So...


Suppose we have two branches:

proj--main--2.0              proj--bugfix--1.0
base-0                 ----- base-0
patch-1               /      patch-1
patch-2---( tag -> ) -   --- patch-2
patch-3                 /    patch-3
patch-4---( replay-> )--
patch-5


Assuming this diagram is actually accurate (and later tla output seems
to support it as such), I'd just like to point out typically you'd
expect to have proj--bugfix--1.0 be a tag off of proj--main--1.0
rather than proj--main--2.0.

There are some missing parts here, but the part shown is actually prety close to reality, where both proj-bugfix--1.0 and proj-main--2.0 are tags of proj--main--1.0--version-0

... snipped


    tla replay --skip-present proj--bugfix--1.0
    tla tree-sync proj--bugfix--1.0--patch-3

Using tree-sync tells arch that you consider that patch (and all
patches it includes) to have been properly merged into your tree.

Thanks, I think this should do it, will try next time.

tree-sync is one of those commands which is not yet clear to me...

In the future, you might either try commiting bugfixes that you'll
want in your 1.0 tree directly into your 1.0 tree and simply have the
2.0 branch star-merge or replay, or try using a seperate branch for
the bug if it's large enough.  (Of course you're free to do whatever
you want, or maybe someone else has better recommendations.)

Well, this is if you know about the bug before you fix it, which is in the ideal world. The reality is that we have to do backports, and I suspect that this is not so uncommon.

Thanks again,
Milan





reply via email to

[Prev in Thread] Current Thread [Next in Thread]