Resolving diverged branches in Subversion repository

[Jelmer Vernooij]

Am Sonntag, den 22.06.2008, 14:12 +1000 schrieb 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.
bzr-svn will only ever add magic file properties to the directory you're
branching from. What sort of file property changes was it making to
those other files?

> 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?
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).

In other words, if you'd like to avoid these file properties being set,
don't use bzr-svn for now.

Cheers,

Jelmer
-- 
Jelmer Vernooij <jelmer at samba.org> - http://samba.org/~jelmer/
Jabber: jelmer at jabber.fsfe.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 315 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080622/0f741cfb/attachment-0001.pgp