On Sat, Apr 18, 2009 at 2:59 PM, John A Meinel <email address hidden>wrote:
> The fix I have broke some other bits.
> Basically, we still need to track down all the cases where we are holding a
> basis_tree longer than the containing working_tree's lock.
>
> I thought there would be some easier/quicker workarounds, but it doesn't
> seem like it works.
>
> ** Changed in: bzr
> Milestone: 1.12 => None
>
Thank you for your reply. KNowing is better than wondering. As you can
tell, I hoped to use 'push' to achieve efficient backups. (Imagine that
only 25 of 25,000 files in a project might change on a given day, but some
days 250 files might change.) Until 'push' is fixed on Windows, I will
probably back up the who branch with 'branch'.
But I am tempted (I know I should not be!) to use 'push' anyway, because it
seems like updates are fine (so far!) and that the problem is only with the
initial push...
On Sat, Apr 18, 2009 at 2:59 PM, John A Meinel <email address hidden>wrote:
> The fix I have broke some other bits.
> Basically, we still need to track down all the cases where we are holding a
> basis_tree longer than the containing working_tree's lock.
>
> I thought there would be some easier/quicker workarounds, but it doesn't
> seem like it works.
>
> ** Changed in: bzr
> Milestone: 1.12 => None
>
Thank you for your reply. KNowing is better than wondering. As you can
tell, I hoped to use 'push' to achieve efficient backups. (Imagine that
only 25 of 25,000 files in a project might change on a given day, but some
days 250 files might change.) Until 'push' is fixed on Windows, I will
probably back up the who branch with 'branch'.
But I am tempted (I know I should not be!) to use 'push' anyway, because it
seems like updates are fine (so far!) and that the problem is only with the
initial push...
Thanks
-M