Ever since bzr-svn started supporting “true push”, people have been complaining about the extra file properties it sets.
The key thing about “true” push is that it preserves the exact revisions that were present in Subversion. This lets bzr behave on Subversion branches transparently using the same UI you also use for “native” Bazaar branches.
In other words, if I push to a Subversion branch from my machine, then that branch in Subversion contains enough information for somebody else to reconstruct the exact bzr branch I had.
Since some Bazaar metadata can not be represented in Subversion, it is stored in Bazaar-specific Subversion properties. Unfortunately, these file properties show up in email commit notifications and trac and so they tend to annoy people.
There are two ways around this:
Revision properties
Bazaar-specific metadata can be stored in in custom Subversion revision properties (these don’t show up in commit notifications). Unfortunately, this requires Subversion 1.5 or newer to run on the server.
I hope to start setting revision properties instead of file properties when possible as of the next bzr-svn release.
less strict push
It’s also possible to throw away any data that can not be represented in Subversion. Since this means that the remote branch won’t end up an exact same copy of the local revisions, this isn’t true push. The two branches will have diverged (no matter how slightly) after such a push so it is necessary to rebase on the remote branch after pushing.
This is similar to the way git-svn pushes data into Subversion - it calls it “dcommit”.
Since this uses rebase it has the usual disadvantages of rebases, which I won’t get into right now.
As of a couple of days ago, bzr-svn now also supports this mode of pushing using the “dpush” command, by popular demand.
Currently Playing: Brandi Carlile - The Story