Resolving diverged branches in Subversion repository

[John Arbash Meinel]

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

Ben Finney wrote:
| Jelmer Vernooij <jelmer at samba.org> writes:
|
|> Am Sonntag, den 22.06.2008, 14:12 +1000 schrieb Ben Finney:
|>> How can I avoid this with the tools I have?
|
|> Until either dpush ("push+rebase") or the revision properties branch
|> are merged, there's no way to avoid file properties being set when
|> using bzr-svn.
|>
|> Alternatively, you can change your commit notification script to
|> hide these properties (like a lot of people also do for svk file
|> properties).
|
| I don't know what this would involve, as I have no direct knowledge of
| how the Subversion repository is managed. (I'm including one of the
| Subversion-using developers in case he has some input on this point.)
|
| Far preferable would be a solution I can implement myself, while still
| working with the branches containing my work.
|
|> In other words, if you'd like to avoid these file properties being
|> set, don't use bzr-svn for now.
|
| Okay. How, then, can I use the tools I have (Bazaar client, Subversion
| client) to continue working with the Bazaar branches made from the
| Subversion repository, without annoying the Subversion-using
| developers with file property noise?
|
| Or, to repeat part of the pervious message:
|
| I would even be willing, if it were possible, to use the Subversion
| client to work only on merging feature branch changes into the trunk,
| and continue to use Bazaar on the feature branches and merging trunk
| changes into them. Is this workable?
|

So, if you weren't using bzr-svn, you could "co-locate" a bzr branch and
a Subversion checkout. I've used that method before with CVS, and other
systems. Basically, on the bzr side, you tell it to ignore all ".svn"
directories, and you do a "bzr init" in the same directory you did "svn co".

In this case, you already have a branch that you probably want to start
with. So you could do something like:

bzr branch my_current_checkout other_location
cd my_current_checkout
mv ../other_location/.bzr .

At this point, you probably need to uninstall 'bzr-svn'. From here on,
you will basically manually sync your "trunk" copy and your svn copy. So
you would do stuff like:


cd trunk
svn up
bzr commit -m "sync from svn"
cd ../feature_A
bzr merge ../trunk
make test
bzr commit -m 'merging in changes from svn'

And then to publish your changes back, I would probably do:

cd trunk
bzr merge ../feature_A
svn commit -m "feature_A, and all that stuff"
bzr commit -m "merging feature_A"

What you lose:

1) SVN commit logs, etc in your Bazaar branches. Because now you are
syncing manually. You could manually do a "svn up -r XXX" and then match
that with "bzr commit -m 'log from svn'". I don't know many humans that
would. Possibly scriptable

2) Other people using bzr-svn won't interoperate with your Bazaar
branches. The way you *have* been doing it, you could send someone one
of your feature_A branches, and they could work with it and svn without
much further communication from you. (It already would track where it
had been merged, etc.)


Another possibility comes to mind. You could continue to use bzr-svn as
you are, except when it comes time to integrate your feature changes
back into trunk.

cd trunk
bzr merge ../feature_A
bzr revert --forget-merges
svn commit -m "feature A"
bzr up

I'm not 100% sure how the svn/bzr stuff works in an SVN checkout. I'm
told it *does* work.

You'll lose the merge points from feature_A => trunk, which can cause
problems in the future if you merge again, or if you merge the other way.

What I've never really understood is why the list of revision ids has to
grow each time. (You could store just the tip each time.) I guess it has
something to do with how long it takes to query the history of an object.

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

iEYEARECAAYFAkhebusACgkQJdeBCYSNAAOLHwCgtIoDYtE+IkztGEMoZ6JM1dia
TaYAoNUr1JcuoafgfLNAEciq48iI8ylM
=VOwS
-----END PGP SIGNATURE-----