Resolving diverged branches in Subversion repository

[Ben Finney]

Jelmer Vernooij <jelmer at samba.org> writes:

> Am Sonntag, den 22.06.2008, 08:27 +1000 schrieb Ben Finney:
> > The use case here already has me merging from Bazaar branches into
> > a local Bazaar checkout of the Subversion repository. (This was
> > done to avoid file-property changes on *every* file in the
> > repository. Now it seems we "only" have file-property changes on
> > files that are meaningless to Subversion users.)
> > 
> > Couldn't that be exploited somehow, to avoid file-property changes
> > altogether in the Subversion repository?

> Sorry, I'm not quite following what you mean here.

I'll try describing it again.

The existing Subversion repository is used by a team that mostly uses
the Subversion client (one, I think, uses Git).

I've been using Bazaar with 'bzr-svn' to interact with this
repository. Initially this was done as described in Message-ID:
<873aoiveog.fsf at benfinney.id.au>, but now I'm maintaining the
following structure:

    Central Subversion repository:
        foo (central Subversion repository)
        +-- trunk (central Subversion repository branch)

    My local work environment:
        foo.trunk/      (Bazaar checkout of Subversion foo trunk)
        foo.feature-A/  (Bazaar branch from foo.trunk/)
        foo.feature-B/  (Bazaar branch from foo.trunk/)
        foo.feature-C/  (Bazaar branch from foo.trunk/)

When changes occur in the central Subversion repository, I do this:

    cd foo.trunk/
    update
    cd ../foo.feature-A/
    merge ../foo.trunk/
    make test
    commit

When I want changes to make their way back to the Subversion trunk of
foo, I do this:

    cd foo.trunk/
    merge ../foo.feature-A/
    make test
    commit

This has the desired effect of easy branching and merging, of keeping
merges where they actually occur in history, and of knowing that none
of the trees get into an untested state merely by changesets moving
around. (I have had the "rebase" behaviour described to me, and I
object to it causing this information to be lost.)

It also improves on the earlier workflow in that changes from my local
feature branches do not cause *every* file in the tree to undergo a
property change. I'm told that this is as a result of me switching to
a workflow where changes are merged into a Bazaar checkout of the
Subversion trunk.


The undesirable behaviour still occurring is that every change that I
commit to the trunk checkout carries an ever-growing set of "property"
changes, which neither I nor the other developers on the project care
to be notified of and are thus noise in the changeset.

These changes don't cause me any problems directly (ppresumably
because they're handled by 'bzr-svn'), but they show up in every one
of my commits to the Subversion repository, making my commits much
more obnoxious that those made by other developers.

How can I avoid this with the tools I have?

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?

-- 
 \           “A free society is one where it is safe to be unpopular.” |
  `\                                            —Adlai Ewing Stevenson |
_o__)                                                                  |
Ben Finney