Best practice for bzr-svn mirror?

[John Arbash Meinel]

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


...

> 
> Using Bazaar to work with multiple branches of a Subversion repository
> in a shared repository seems to work fine as long as you never use
> rebase between the Bazaar branches.   The same goes for Git -- which
> indicates it is an inherent CVCS/DVCS issue not a Bazaar or Git issue.
> 

For rebasing to leave branches in a workable state, it would need to
rebase all branches based on the first branch. Consider this graph

 A
 |
 B
 |\
 C D
 | |\
 E F G

E == svn trunk
F == branch 1
G == branch 2

At this point, you decided to rebase 'branch 1' back on top of the svn
trunk:

 A
 |
 B
 |\
 C D
 | |\
 E F G
  \
   D'
   |
   F'

Note that D & F don't really go away. They are still in your repository.
Note also that 'branch 2' is still based on D and not D'. This is why
you run into problems. If you now find the common ancestor between
branch 1' and branch 2, it is actually B and not D or D'.

There are 2 ways that a "rebase" operation could get around this.

 A
 |
 B
 |\
 C \
 |  \
 E   D
  \ /|\
   D'F G
   |/
   F'

The first option is that rebase could create these new D' and F'
revisions, but consider them as *merging* the old D and F revisions.
This would likely allow branch 1' and branch 2 to interoperate. However,
if you are using *rebase* you probably don't want this 'rebased as
merges' behavior. At least from what I've seen, people want to pretend
that D & F never existed. Otherwise instead of rebase you could have
just done:

 A
 |
 B
 |'-.
 C   D
 |   |\
 E   F G
  \ /
   H

H is effectively F' from above, but can be done with simply pulling E
and merging F into it. (Perhaps some would be okay with this, but find
it a little clumsy to actually get this behavior. A 'bzr merge
- --switch-parents' would probably handle this if we wanted to implement
it.)

So what is the other option... You have to rebase branch 2 as well. And get:

 A
 |
 B
 |\
 C D
 | |\
 E F G
  \
   D'
   |\
   F'G'


Now, I don't know that the current interface of "rebase" makes this as
easy as it could be. Consider specifically that if you tried to "rebase
branch2" on top of the svn trunk branch, it would actually create
something like:

 A
 |
 B
 |\
 C D
 | |\
 E F G
  \--.
   D' D*
   |   \
   F'   G*

Simply because if you look at "what is different in Branch2 from trunk"
D is included there.

What *could* be done is to have a "rebase-multiple-branches" sort of
command. That would rebase both branch1 and branch2 at the same time.
(And thus they would both share D').

Note that it doesn't help if it is someone *else's* branch that also
needs to be rebased (since it wasn't run at the same time).

Yet another possibility would be to have rebase store the D => D'
information somewhere, so that you could do "apply-rebase-to", and
rebase yet-another branch with the same information.


>> Could I be doing something differently to make rebasing easier?
> 
> I suspect not.  Jelmer is probably the expert on all this though, he
> might have something more constructive to contribute.
> 

Ultimately, there are things that could be done to make things easier. I
think many of us think that rebasing is a tool that you should only be
using infrequently anyway, and so we haven't really spent any time
polishing the user experience.

If you are using > 1 branch anyway, do you *really* need to be rebasing?
Why not just merge and commit like everyone else in DVCS land?

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

iEYEARECAAYFAkmitEQACgkQJdeBCYSNAAMlQwCgk4KLazujSHER1kUrWytjitFy
A60AmQErKmZnxCIOD3Hnwod3/xZ8YpKe
=raAe
-----END PGP SIGNATURE-----