bzr-svn 1.0 ?

[Jelmer Vernooij]

Hi Russel,

Russel Winder wrote:
>> 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.
>   
Are there any particular operations that are slower in bzr-svn than
git-svn ? How significant is the difference? In the case of http I'm
aware that we're doing at least one more TCP/IP connection than is
required, but this should usually not have a significant impact.
> --  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.
>   
Which things in particular is it checking for? There should be some
overhead when first accessing a Subversion repository, but after that,
most information should be stored in the cache. If it's checking more
than that, we might have a bug somewhere.
> --  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 :-)
>   
I agree that always giving progress feedback is the right thing to do,
and we should already be doing this everywhere. If you find there are
places where it looks like bzr is hangin, please hit Ctrl+\ so you are
dropped into pdb and run "bt" to get a backtrace of information about
where bzr-svn is at the moment and file a bug with that backtrace if you
encounter this.
> NB  I am using your fork of bzr.dev, not bzr.dev. 
>   
At this point, the only difference is that the smart server over http is
disabled in bzr.foreign. There will probably be more differences in the
future again.
> 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.
>   
Thanks, glad it's useful. Without your feedback and help debugging
bzr-svn wouldn't be where it is today.

Cheers,

Jelmer