bzr-svn 1.0 ?

Russel Winder russel.winder at concertant.com
Sun Jun 7 08:56:35 BST 2009


Jelmer,

On Sun, 2009-06-07 at 02:38 +0200, Jelmer Vernooij wrote:
> I think bzr-svn is getting close to a 1.0 release. I'd like to make
> sure there's at least a bzr-svn 1.x by the time Bazaar 2.x is
> released.

I have been a happy customer of bzr-svn for quite a while now.  There
have been no major problems with it for a while and I consider it ready
for production use, so planning a 1.0 release seems very right.

> The only thing I'd personally think should be fixed before 1.0 is changing the
> default of append_revisions_only to True for Subversion branches,
> since not having as default has caused grief for some users. 
> 
> Are there any problems or missing functionality that you consider
> blockers for bzr-svn 1.0?

My use of bzr-svn is for using Bazaar as DVCS where the public mainline
is a Subversion repository.  I have fallen into the mode of use as
having a share repository with a checkout of the Subversion branch as a
mirror and then development branches off that.  Pushing to the mirror
then does everything necessary to get updates to the Subversion
repository.  It all seems to work correctly, my (minor) irritants are
that:

(working from memory of activity)

--  it seems to take a relatively long time to do things.  Access to the
Subversion store is much, much faster than it used to be (and that is
great) but it still seems to be slow compared to Git -- this is likely
much more to do with perception than fact, but perceptions are important
here, this is HCI.  I appreciate bzr-dev has a lot more functionality
than Git interfacing to Subversion and that there is a cost, also that
the bzr-svn and git-svn enabled workflows are different.

--  every time there is a Subversion access, bzr-svn seems to do lots of
checking of the Subversion repository.  This may be essential, and there
is feedback to say that things are happening, but it still irritates and
is almost certainly the cause of the perceived slowness noted above.

--  there are periods where there is no feedback and this leads to the
tensest moments is doing updates.  Whilst there is a feedback bar
operating, it is clear Bazaa/bzr-svn is operating and functioning.  Then
that is all removed and it is just a period awaiting either successful
completion or an exception stack trace.  I think that it would be wise
for there always to be some form of feedback bar or never a feedback
bar, and the former is significantly better.  Can I propose that the
phase that currently operates with no feedback be made to give some,
even if this means the overall operation taking a few seconds longer.
Adding some seconds of operation time where there is continuous feedback
is less stressful than suddenly seeing the feedback disappearing and
having to wait.  (I know this contradicts the first point, but I feel as
though I am in a quantum state and can hold multiple conflicting views
concurrently :-)

NB  I am using your fork of bzr.dev, not bzr.dev. 

All in all I think bzr-svn makes Bazaar a great way of doing development
where a Subversion store must be a peer not a master.   Actually I think
it is the only way :-)

Thanks for all your efforts on bzr-svn -- and dealing with all my
emails, public and private.
-- 
Russel.
=============================================================================
Dr Russel Winder      Partner
                                            xmpp: russel at russel.org.uk
Concertant LLP        t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,   f: +44 8700 516 084   voip: sip:russel.winder at ekiga.net
London SW11 1EN, UK   m: +44 7770 465 077   skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090607/799b80b3/attachment.pgp 


More information about the bazaar mailing list