Bazaar as interface to Subversion repositories

[Russel Winder]

On Sat, 2008-11-01 at 14:58 +1100, Ben Finney wrote:
[ . . . ]
> I've been chased away from projects because the existing hackers take
> the (quite reasonable) position that if I won't use a tool that
> operates well with the repository, I shouldn't use the repository at
> all. That makes it rather difficult to discover and report specific
> issues with ‘bzr-svn’, of course, but there's no good reason to submit
> others unwillingly to be guinea pigs in bug hunting the VCS tool
> chain. The only option I'm left with, then, is to not use ‘bzr-svn’
> for that purpose at all.

There are many issues here which I think I can can summarize thus:

bzr-svn was originally for storing Bazaar branches in a Subversion
repository.  Personally I don't see this as an important use case.
Actually I am not sure I would ever want to do this.  However I assume
there are sub-organizations using Bazaar where it is mandated by the
super-organization that they store things in a Subversion repository.

Some but not all Subversion stores quote in full all changes to
properties as well as changes to files.  Where the Subversion store
simply notes a change to a property but does not quote it, you cannot
really tell that Bazaar metadata is being stored.  Where the Subversion
store does quote property changes in full, you get ever increasing and
huge change notifications and this very quickly gets completely
unacceptable.  So unless the Subversion email hook can be changed that
is an end to using Bazaar as Subversion client.

I (metaphorically) jumped up and down and threw my toys out of the pram
(as it were) and in response Jelmer created dpush as a direct analogue
of git svn dcommit -- serious praise to Jelmer for doing this.  This now
means that Bazaar can behave in the same way Git (via git-svn) does:
Only file changes are committed from the Bazaar branch to the Subversion
repository, the Bazaar metadata is not stored in the Subversion
repository -- hence no problems with email notifications, like Git they
look jsut like Subversion commits.  This for me makes Bazaar a viable
Subversion client.  The workflow and strategies are the same for Bazaar
as they are for Git.

bzr-svn still has various caching and performance issues though using
the rebase/dpush workflow compared to Git with the svn rebase/svn
dcommit workflow.   I think that bzr-svn is having to do a lot more
interaction with the Subversion repository for handling tags, branches,
logs, etc.  I believe this is all to do with having to be able to push
or dpush to a Subversion repository.  In any event, I'm afraid it
currently means Git and not Bazaar is my preferred Subversion client.

I should note that it is not just bzr-svn that is a factor in the last
statement, gitk keeping apparent track of remote as well as local
branches is a real boon.  bzr qlog might try adding this for shared
repositories, and bzr viz needs to catch up with bzr qlog and be able to
work with multiple branches in a shared repository.

PS  Actually I am keeping both Git repositories (on GitHub) and Bazaar
branches (on Launchpad) of all the Subversion stores I am involved with
(all from Codehaus).  I get more Bazaar bundles as change requests than
Git patches!  It seems then that despite the Git hype and hullabaloo,
Bazaar is often the tool of choice!

-- 
Russel.
====================================================
Dr Russel Winder                 Partner

Concertant LLP                   t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,              f: +44 8700 516 084
London SW11 1EN, UK.             m: +44 7770 465 077
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20081101/778b5881/attachment-0001.pgp