Would be nice to have an easier way to upgrade a customized branch to a newer branch

[Max Kanat-Alexander]

http://groups.google.com/group/mozilla.dev.apps.bugzilla/browse_thread/thread/358ed7399bf0a1f3 suggests this process

"""
Let's say that you have a customized Bugzilla 3.4 in a local bzr
branch, and you want to upgrade to Bugzilla 3.6. Here's how to do it:

        cd custom-bugzilla-3.4
        bzr bundle bzr://bzr.mozilla.org/bugzilla/3.4 > ../customizations.diff
        cd ..
        bzr co bzr://bzr.mozilla.org/bugzilla/3.6 new-custom-3.6
        cd new-custom-3.6
        bzr merge ../customizations.diff

        And then resolve any conflicts, and then commit.

        You can't just merge 3.6 into 3.4. Unfortunately that doesn't work,
because we frequently added patches to both 3.4 and 3.6 that are
slightly different, and thus there are conflicts. (This would work
better if we had a slightly different development methodology, but
that's something I'm still thinking about, and for now, the above
instructions work very well and are really easy to do.)
"""

It would be nice if this were easier.

[Andrew Bennetts (spiv)]

It's not clear to me that these are spurious. "bzr missing" says that 3.4 has 227 revisions not in 3.6, and 3.6 has 548 not in 3.4. With that amount of divergence I'm not surprised to see some conflicts. FWIW, with --lca I only get 58 conflicts.

Looking at the conflicts, some conflicts are due to one branch adding files to extensions/example/code/, while the other branch wants to delete that directory. That seems like a legitimate conflict to me. My CVS expertise is very rusty, but are you sure that "cvs up -dP -rXXX" really does a comparable merge? I would have thought that it would be more like "bzr pull --overwrite".

I tested with 3.4 r6758 and 3.6 r7079.

[Andrew Bennetts (spiv)]

Also, you say you're:

> trying to "upgrade" from one branch of Bugzilla to a newer branch

What do you mean by "upgrade"? Do you want to integrate the changes from both branches into a single branch, or just switch to using the new branch? i.e. perhaps you want "bzr switch" rather than "bzr merge"?

[Max Kanat-Alexander (mkanat)]

I had a chat with lifeless about this on #bzr, and actually, yes, you're right, from bzr's perspective, those are valid conflicts.

So really, what I want is simply a better way to do what I'm trying to do. There actually isn't anything in bzr that does the same as "cvs up" would do--partly because CVS customizations are usually uncommitted, and bzr customizations are committed. Here's what I've told people to do for now:

  http://groups.google.com/group/mozilla.dev.apps.bugzilla/browse_thread/thread/358ed7399bf0a1f3

[Alexander Belchenko (bialix)]

What do you mean by "CVS customizations are usually uncommitted"?

Bugzilla team may want to think about using DaggyFixes workflow to reduce the amount of conflicts, IMO.

[John A Meinel (jameinel)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Max Kanat-Alexander wrote:
> I had a chat with lifeless about this on #bzr, and actually, yes, you're
> right, from bzr's perspective, those are valid conflicts.
>
> So really, what I want is simply a better way to do what I'm trying to
> do. There actually isn't anything in bzr that does the same as "cvs up"
> would do--partly because CVS customizations are usually uncommitted, and
> bzr customizations are committed. Here's what I've told people to do for
> now:
>
> http://groups.google.com/group/mozilla.dev.apps.bugzilla/browse_thread/thread/358ed7399bf0a1f3
>

Switch seems like it would be pretty close. (Change my underlying
revisions to match this other revision, but preserve my uncommitted
changes.)

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAku/T3EACgkQJdeBCYSNAAO4DwCgs3WcBMJZUJby9DnUJecINSCK
eL0An3sNiUBQEdhnOYBDSJkko+KeivV9
=AfeG
-----END PGP SIGNATURE-----

[Martin Pool (mbp)]

This seems a bit related to the common wish for a way to hold
persistent uncommitted changes, either to particular files or on top
of other files.