BZR 2.1.2 + SVN 1.7.7 + etckeeper on Debian Squeeze

[JP Vossen]

On 11/06/2012 10:40 PM, Brian de Alwis wrote:
> On 6-Nov-2012, at 4:18 PM, JP Vossen wrote:
>> All of that said, simply removing 'bzr-svn' "solves" my problem and I can keep the co-located .bzr and .svn and it works.  That's what I'll do for the short-term, as I have a lot of other things to re-org and tweak once I get out of CVS.  But for the long term, I need to fix my work-flow…
>
>
> You can selectively disable bzr-svn by using the BZR_DISABLE_PLUGINS environment variable.

Awesome!  I've read the docs but I missed or forgot that one, thanks!

> I was recently in a similar boat where I maintained a parallel bzr branch inline with a Subversion checkout.  The repository had some enormous files committed to it, and I didn't have the time/bandwidth to use bzr-svn.
>
> I've attached a little script I used to automate pulling down from svn and committing to a local bzr branch.  It works well enough, though you have to be careful that you don't hit new changes coming down when pulling in local commits to be pushed up.

That'll work for me, I've got some similar helper/wrapper scripts to 
make CVS bearable (almost :), so this is no different.

> The better solution would be to teach bzr-svn how to support stacked branches (or some kind of horizon) to avoid downloading the full history.  But I haven't been brave or desperate enough to try.

At present that is overkill for me...

Thanks for the idea and script!
JP
----------------------------|:::======|-------------------------------
JP Vossen, CISSP            |:::======|      http://bashcookbook.com/
My Account, My Opinions     |=========|      http://www.jpsdomain.org/
----------------------------|=========|-------------------------------
"Microsoft Tax" = the additional hardware & yearly fees for the add-on
software required to protect Windows from its own poorly designed and
implemented self, while the overhead incidentally flattens Moore's Law.