[PATCH] remote-bzr: update old organization

[PATCH] remote-bzr: update old organization

[Felipe Contreras]

If a clone exists with the old organization (v1.8.2) it will prevent the
new shared repository organization from working, so let's remove this
repository, which is not used any more.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 contrib/remote-helpers/git-remote-bzr | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/contrib/remote-helpers/git-remote-bzr b/contrib/remote-helpers/git-remote-bzr
index 3e452af..b295dd4 100755
--- a/contrib/remote-helpers/git-remote-bzr
+++ b/contrib/remote-helpers/git-remote-bzr
@@ -830,6 +830,13 @@ def get_repo(url, alias):
         clone_path = os.path.join(dirname, 'clone')
         if not os.path.exists(clone_path):
             os.mkdir(clone_path)
+        else:
+            # check and remove old organization
+            try:
+                bdir = bzrlib.bzrdir.BzrDir.open(clone_path)
+                bdir.destroy_repository()
+            except bzrlib.errors.NotBranchError:
+                pass
 
     try:
         repo = origin.open_repository()
-- 
1.8.3.rc1.579.g184e698

Re: [PATCH] remote-bzr: update old organization

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> If a clone exists with the old organization (v1.8.2) it will prevent the
> new shared repository organization from working, so let's remove this
> repository, which is not used any more.
>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---

What happens with and without this patch to an existing user from
1.8.2 days, when she does what?

A sample answer (to show the level of descriptiveness, not the
content, I am epecting) might go something like "Because the
organization is different, it will barf whenever she tries to
incrementally update from the other side. By removing the old one
1.8.3 contrib/ does not understand, at least we can unstuck her; she
ends up reimporting the whole history, though."

Trying to see if this is a 1.8.3 "fast-track" material.

>  contrib/remote-helpers/git-remote-bzr | 7 +++++++
>  1 file changed, 7 insertions(+)
>
> diff --git a/contrib/remote-helpers/git-remote-bzr b/contrib/remote-helpers/git-remote-bzr
> index 3e452af..b295dd4 100755
> --- a/contrib/remote-helpers/git-remote-bzr
> +++ b/contrib/remote-helpers/git-remote-bzr
> @@ -830,6 +830,13 @@ def get_repo(url, alias):
>          clone_path = os.path.join(dirname, 'clone')
>          if not os.path.exists(clone_path):
>              os.mkdir(clone_path)
> +        else:
> +            # check and remove old organization
> +            try:
> +                bdir = bzrlib.bzrdir.BzrDir.open(clone_path)
> +                bdir.destroy_repository()
> +            except bzrlib.errors.NotBranchError:
> +                pass
>  
>      try:
>          repo = origin.open_repository()

Re: [PATCH] remote-bzr: update old organization

[Felipe Contreras]

On Tue, May 14, 2013 at 12:30 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> If a clone exists with the old organization (v1.8.2) it will prevent the
>> new shared repository organization from working, so let's remove this
>> repository, which is not used any more.
>>
>> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
>> ---
>
> What happens with and without this patch to an existing user from
> 1.8.2 days, when she does what?

I already explained it would prevent the new shared repository
organization from working, so the old organization would be used; the
repositories won't be shared.

> A sample answer (to show the level of descriptiveness, not the
> content, I am epecting) might go something like "Because the
> organization is different, it will barf whenever she tries to
> incrementally update from the other side. By removing the old one
> 1.8.3 contrib/ does not understand, at least we can unstuck her; she
> ends up reimporting the whole history, though."

Bazaar won't barf, the repositories will be duplicated, so the shared
feature won't work.

-- 
Felipe Contreras

Re: [PATCH] remote-bzr: update old organization

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> On Tue, May 14, 2013 at 12:30 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>>> If a clone exists with the old organization (v1.8.2) it will prevent the
>>> new shared repository organization from working, so let's remove this
>>> repository, which is not used any more.
>>>
>>> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
>>> ---
>>
>> What happens with and without this patch to an existing user from
>> 1.8.2 days, when she does what?
>
> I already explained it would prevent the new shared repository
> organization from working, so the old organization would be used; the
> repositories won't be shared.
>
>> A sample answer (to show the level of descriptiveness, not the
>> content, I am epecting) might go something like "Because the
>> organization is different, it will barf whenever she tries to
>> incrementally update from the other side. By removing the old one
>> 1.8.3 contrib/ does not understand, at least we can unstuck her; she
>> ends up reimporting the whole history, though."
>
> Bazaar won't barf, the repositories will be duplicated, so the shared
> feature won't work.

But by removing the old incarnation, you are getting rid of the copy
for which the shared feature will not work, so with patch, "won't
work" is no longer an issue.  Is the user making a trade-off by
using Git with this patch?  What is she losing by removal, if
anything?

Re: [PATCH] remote-bzr: update old organization

[Felipe Contreras]

On Tue, May 14, 2013 at 3:36 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> On Tue, May 14, 2013 at 12:30 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>>
>>>> If a clone exists with the old organization (v1.8.2) it will prevent the
>>>> new shared repository organization from working, so let's remove this
>>>> repository, which is not used any more.
>>>>
>>>> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
>>>> ---
>>>
>>> What happens with and without this patch to an existing user from
>>> 1.8.2 days, when she does what?
>>
>> I already explained it would prevent the new shared repository
>> organization from working, so the old organization would be used; the
>> repositories won't be shared.
>>
>>> A sample answer (to show the level of descriptiveness, not the
>>> content, I am epecting) might go something like "Because the
>>> organization is different, it will barf whenever she tries to
>>> incrementally update from the other side. By removing the old one
>>> 1.8.3 contrib/ does not understand, at least we can unstuck her; she
>>> ends up reimporting the whole history, though."
>>
>> Bazaar won't barf, the repositories will be duplicated, so the shared
>> feature won't work.
>
> But by removing the old incarnation, you are getting rid of the copy
> for which the shared feature will not work, so with patch, "won't
> work" is no longer an issue.  Is the user making a trade-off by
> using Git with this patch?  What is she losing by removal, if
> anything?

No. The way repositories work in bazaar is tricky:

Suppose you have a directory like this:

+* first/second/foo
+* first/second/bar

Both the branch and the repository are on the same directory (hence
+*). We have two branches, and two independent repositories.

And then you have a shared repo:

+ first/
* first/second/foo
* first/second/bar

Now we have a single repository shared between two branches.

But:

+ first/
+* first/second
+* first/second/foo
+* first/second/bar

If there's another repository in-between, neither 'foo' nor 'bar' can
reach 'first', so they are stuck with the repository in 'second',
which is not a shared repository, so they must create their own
repositories, but even if they could use 'second', there still would
be a problem:

+ first/
+* first/second
+* first/second/foo
+* first/second/bar
+* first/third
+* first/third/foo
+* first/third/bar

We want 'second' and 'third' to share to object tree, but we can't.

This patch would remove the old repository ('second' and 'third') so
we have exactly what we want:

+ first/
* first/second/foo
* first/second/bar
* first/third/foo
* first/third/bar

A single bzr repository shared by all the branches and all the repos.

In reality it probably wouldn't be a big deal, because in v1.8.2 users
couldn't clone true bzr repos, but there are some bazaar repos with a
single branch they could clone, and there would be a single duplicated
repo, like this:

+ first/
+* first/second/foo
+* first/third/foo

-- 
Felipe Contreras

Re: [PATCH] remote-bzr: update old organization

[Felipe Contreras]

On Tue, May 14, 2013 at 3:50 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Tue, May 14, 2013 at 3:36 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>>> On Tue, May 14, 2013 at 12:30 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>>>
>>>>> If a clone exists with the old organization (v1.8.2) it will prevent the
>>>>> new shared repository organization from working, so let's remove this
>>>>> repository, which is not used any more.
>>>>>
>>>>> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
>>>>> ---
>>>>
>>>> What happens with and without this patch to an existing user from
>>>> 1.8.2 days, when she does what?
>>>
>>> I already explained it would prevent the new shared repository
>>> organization from working, so the old organization would be used; the
>>> repositories won't be shared.
>>>
>>>> A sample answer (to show the level of descriptiveness, not the
>>>> content, I am epecting) might go something like "Because the
>>>> organization is different, it will barf whenever she tries to
>>>> incrementally update from the other side. By removing the old one
>>>> 1.8.3 contrib/ does not understand, at least we can unstuck her; she
>>>> ends up reimporting the whole history, though."
>>>
>>> Bazaar won't barf, the repositories will be duplicated, so the shared
>>> feature won't work.
>>
>> But by removing the old incarnation, you are getting rid of the copy
>> for which the shared feature will not work, so with patch, "won't
>> work" is no longer an issue.  Is the user making a trade-off by
>> using Git with this patch?  What is she losing by removal, if
>> anything?
>
> No. The way repositories work in bazaar is tricky:
>
> Suppose you have a directory like this:
>
> +* first/second/foo
> +* first/second/bar
>
> Both the branch and the repository are on the same directory (hence
> +*). We have two branches, and two independent repositories.
>
> And then you have a shared repo:
>
> + first/
> * first/second/foo
> * first/second/bar
>
> Now we have a single repository shared between two branches.
>
> But:
>
> + first/
> +* first/second
> +* first/second/foo
> +* first/second/bar
>
> If there's another repository in-between, neither 'foo' nor 'bar' can
> reach 'first', so they are stuck with the repository in 'second',
> which is not a shared repository, so they must create their own
> repositories, but even if they could use 'second', there still would
> be a problem:
>
> + first/
> +* first/second
> +* first/second/foo
> +* first/second/bar
> +* first/third
> +* first/third/foo
> +* first/third/bar
>
> We want 'second' and 'third' to share to object tree, but we can't.
>
> This patch would remove the old repository ('second' and 'third') so
> we have exactly what we want:
>
> + first/
> * first/second/foo
> * first/second/bar
> * first/third/foo
> * first/third/bar
>
> A single bzr repository shared by all the branches and all the repos.
>
> In reality it probably wouldn't be a big deal, because in v1.8.2 users
> couldn't clone true bzr repos, but there are some bazaar repos with a
> single branch they could clone, and there would be a single duplicated
> repo, like this:
>
> + first/
> +* first/second/foo
> +* first/third/foo

I forgot to mention the main objective of the shared repo feature:

+ first/
* first/second/foo
* first/third/foo
* first/fourth/foo
* first/fifth/foo
* first/sixth/foo

Since in bazaar branches are repositories, we want to make it possible
for remote-bzr users to create a single remote per branch as easily as
possible (without having to duplicate huge clones).

But as I said, without this patch, they wouldn't be able to use that
feature if they cloned with v1.8.2.

-- 
Felipe Contreras

Re: [PATCH] remote-bzr: update old organization

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> I forgot to mention the main objective of the shared repo feature:
>
> + first/
> * first/second/foo
> * first/third/foo
> * first/fourth/foo
> * first/fifth/foo
> * first/sixth/foo
>
> Since in bazaar branches are repositories, we want to make it possible
> for remote-bzr users to create a single remote per branch as easily as
> possible (without having to duplicate huge clones).
>
> But as I said, without this patch, they wouldn't be able to use that
> feature if they cloned with v1.8.2.

So we nuke that and have them clone from scratch?  I am not saying
that is bad.  I just want us to be honest about the implications
when including it in the ReleaseNotes.

Re: [PATCH] remote-bzr: update old organization

[Felipe Contreras]

On Tue, May 14, 2013 at 4:18 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> I forgot to mention the main objective of the shared repo feature:
>>
>> + first/
>> * first/second/foo
>> * first/third/foo
>> * first/fourth/foo
>> * first/fifth/foo
>> * first/sixth/foo
>>
>> Since in bazaar branches are repositories, we want to make it possible
>> for remote-bzr users to create a single remote per branch as easily as
>> possible (without having to duplicate huge clones).
>>
>> But as I said, without this patch, they wouldn't be able to use that
>> feature if they cloned with v1.8.2.
>
> So we nuke that and have them clone from scratch?  I am not saying
> that is bad.  I just want us to be honest about the implications
> when including it in the ReleaseNotes.

The user won't have to do a thing, it happens behind the curtain.

And the clone would happen either way, with or without this patch,
because 'hg/origin/master' doesn't exist, the only purpose 'hg/origin'
serves is to block the new feature.

-- 
Felipe Contreras

Re: [PATCH] remote-bzr: update old organization

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> And the clone would happen either way, with or without this patch,
> because 'hg/origin/master' doesn't exist, the only purpose 'hg/origin'
> serves is to block the new feature.

That is the answer I was trying to extract out of you (I take the hg
is a typo for bzr in the above, though).

Re: [PATCH] remote-bzr: update old organization

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> And the clone would happen either way, with or without this patch,
>> because 'hg/origin/master' doesn't exist, the only purpose 'hg/origin'
>> serves is to block the new feature.
>
> That is the answer I was trying to extract out of you (I take the hg
> is a typo for bzr in the above, though).

Just to double check, I understand that the justification for
removal is this:

     If a clone exists with the old organization (v1.8.2) it will prevent the
     new shared repository organization from working, so let's remove this
    -repository, which is not used any more.
    +repository. It is not used by 1.8.3, and did not host any useful
    +information in the code in 1.8.2.

Re: [PATCH] remote-bzr: update old organization

[Felipe Contreras]

On Tue, May 14, 2013 at 5:14 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>>> And the clone would happen either way, with or without this patch,
>>> because 'hg/origin/master' doesn't exist, the only purpose 'hg/origin'
>>> serves is to block the new feature.
>>
>> That is the answer I was trying to extract out of you (I take the hg
>> is a typo for bzr in the above, though).
>
> Just to double check, I understand that the justification for
> removal is this:
>
>      If a clone exists with the old organization (v1.8.2) it will prevent the
>      new shared repository organization from working, so let's remove this
>     -repository, which is not used any more.
>     +repository. It is not used by 1.8.3, and did not host any useful
>     +information in the code in 1.8.2.

That is not true. It did host useful information in 1.8.2, if we apply
this and the user tries to pull with remote-bzr from 1.8.2, it would
need to be cloned again.

-- 
Felipe Contreras

Re: [PATCH] remote-bzr: update old organization

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> On Tue, May 14, 2013 at 5:14 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>>
>>>> And the clone would happen either way, with or without this patch,
>>>> because 'hg/origin/master' doesn't exist, the only purpose 'hg/origin'
>>>> serves is to block the new feature.
>>>
>>> That is the answer I was trying to extract out of you (I take the hg
>>> is a typo for bzr in the above, though).
>>
>> Just to double check, I understand that the justification for
>> removal is this:
>>
>>      If a clone exists with the old organization (v1.8.2) it will prevent the
>>      new shared repository organization from working, so let's remove this
>>     -repository, which is not used any more.
>>     +repository. It is not used by 1.8.3, and did not host any useful
>>     +information in the code in 1.8.2.
>
> That is not true. It did host useful information in 1.8.2, if we apply
> this and the user tries to pull with remote-bzr from 1.8.2, it would
> need to be cloned again.

So the answer to my original question:

    So we nuke that and have them clone from scratch?

is now "Yes, unfortunately, but it happens automatically inside
remote-bzr and the users won't have to do anything extra"?

That is the kind of honest description I wanted to see.

Re: [PATCH] remote-bzr: update old organization

[Felipe Contreras]

On Tue, May 14, 2013 at 5:33 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> On Tue, May 14, 2013 at 5:14 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Junio C Hamano <gitster@pobox.com> writes:
>>>
>>>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>>>
>>>>> And the clone would happen either way, with or without this patch,
>>>>> because 'hg/origin/master' doesn't exist, the only purpose 'hg/origin'
>>>>> serves is to block the new feature.
>>>>
>>>> That is the answer I was trying to extract out of you (I take the hg
>>>> is a typo for bzr in the above, though).
>>>
>>> Just to double check, I understand that the justification for
>>> removal is this:
>>>
>>>      If a clone exists with the old organization (v1.8.2) it will prevent the
>>>      new shared repository organization from working, so let's remove this
>>>     -repository, which is not used any more.
>>>     +repository. It is not used by 1.8.3, and did not host any useful
>>>     +information in the code in 1.8.2.
>>
>> That is not true. It did host useful information in 1.8.2, if we apply
>> this and the user tries to pull with remote-bzr from 1.8.2, it would
>> need to be cloned again.
>
> So the answer to my original question:
>
>     So we nuke that and have them clone from scratch?

No, as I already explained the "cloning from scratch" is already
happening with or without this patch.

All this change does is remove a repository that is not used any more
in order to allow a feature that was already introduced, and that's
exactly what the commit message says. It doesn't cause any other
change.

-- 
Felipe Contreras

Re: [PATCH] remote-bzr: update old organization

[Felipe Contreras]

On Fri, May 17, 2013 at 5:02 AM, Sandor Bodo-Merle <sbodomerle@gmail.com> wrote:

> apparently this breaks my existing clone of the bugzilla repository, where i
> have branches cloned with versions of remote-bzr prior 1.8.2 and after. The
> erro iget is:
>
> Fetching origin
> Traceback (most recent call last):
>   File "/home/bms/bin/git-remote-bzr", line 956, in <module>
>     sys.exit(main(sys.argv))
>   File "/home/bms/bin/git-remote-bzr", line 928, in main
>     repo = get_repo(url, alias)
>   File "/home/bms/bin/git-remote-bzr", line 844, in get_repo
>     bdir.destroy_repository()
>   File "/usr/lib/python2.7/dist-packages/bzrlib/bzrdir.py", line 900, in
> destroy_repository
>     raise errors.NoRepositoryPresent(self)
> bzrlib.errors.NoRepositoryPresent: No repository present:
> "file:///home/bms/workspace/bugzilla/.git/bzr/origin/clone/"
> error: Could not fetch origin
>
>
> The following small patch seems to fix my regression:

The patch is fine by me, in fact, I already had that patch, but
somehow could not trigger the exception, so I removed it.

-- 
Felipe Contreras

Re: [PATCH] remote-bzr: update old organization

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> On Fri, May 17, 2013 at 5:02 AM, Sandor Bodo-Merle <sbodomerle@gmail.com> wrote:
>
>> apparently this breaks my existing clone of the bugzilla repository, where i
>> have branches cloned with versions of remote-bzr prior 1.8.2 and after. The
>> erro iget is:
>>
>> Fetching origin
>> Traceback (most recent call last):
>>   File "/home/bms/bin/git-remote-bzr", line 956, in <module>
>>     sys.exit(main(sys.argv))
>>   File "/home/bms/bin/git-remote-bzr", line 928, in main
>>     repo = get_repo(url, alias)
>>   File "/home/bms/bin/git-remote-bzr", line 844, in get_repo
>>     bdir.destroy_repository()
>>   File "/usr/lib/python2.7/dist-packages/bzrlib/bzrdir.py", line 900, in
>> destroy_repository
>>     raise errors.NoRepositoryPresent(self)
>> bzrlib.errors.NoRepositoryPresent: No repository present:
>> "file:///home/bms/workspace/bugzilla/.git/bzr/origin/clone/"
>> error: Could not fetch origin
>>
>>
>> The following small patch seems to fix my regression:
>
> The patch is fine by me, in fact, I already had that patch, but
> somehow could not trigger the exception, so I removed it.

Is it merely "fine", or needed for 1.8.3?  I am guessing it is the
latter but making a final double-check, as I'll be stopping to pick
up patches from the list in order to start today's integration run
(that includes tagging 1.8.3-rc3).

Thanks.

Re: [PATCH] remote-bzr: update old organization

[Felipe Contreras]

On Fri, May 17, 2013 at 12:09 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> On Fri, May 17, 2013 at 5:02 AM, Sandor Bodo-Merle <sbodomerle@gmail.com> wrote:
>>
>>> apparently this breaks my existing clone of the bugzilla repository, where i
>>> have branches cloned with versions of remote-bzr prior 1.8.2 and after. The
>>> erro iget is:
>>>
>>> Fetching origin
>>> Traceback (most recent call last):
>>>   File "/home/bms/bin/git-remote-bzr", line 956, in <module>
>>>     sys.exit(main(sys.argv))
>>>   File "/home/bms/bin/git-remote-bzr", line 928, in main
>>>     repo = get_repo(url, alias)
>>>   File "/home/bms/bin/git-remote-bzr", line 844, in get_repo
>>>     bdir.destroy_repository()
>>>   File "/usr/lib/python2.7/dist-packages/bzrlib/bzrdir.py", line 900, in
>>> destroy_repository
>>>     raise errors.NoRepositoryPresent(self)
>>> bzrlib.errors.NoRepositoryPresent: No repository present:
>>> "file:///home/bms/workspace/bugzilla/.git/bzr/origin/clone/"
>>> error: Could not fetch origin
>>>
>>>
>>> The following small patch seems to fix my regression:
>>
>> The patch is fine by me, in fact, I already had that patch, but
>> somehow could not trigger the exception, so I removed it.
>
> Is it merely "fine", or needed for 1.8.3?  I am guessing it is the
> latter but making a final double-check, as I'll be stopping to pick
> up patches from the list in order to start today's integration run
> (that includes tagging 1.8.3-rc3).

Yes, for v1.8.3.

-- 
Felipe Contreras

Re: [PATCH] remote-bzr: update old organization

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> On Fri, May 17, 2013 at 12:09 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>>> On Fri, May 17, 2013 at 5:02 AM, Sandor Bodo-Merle <sbodomerle@gmail.com> wrote:
>>>
>>>> apparently this breaks my existing clone of the bugzilla repository, where i
>>>> have branches cloned with versions of remote-bzr prior 1.8.2 and after. The
>>>> erro iget is:
>>>>
>>>> Fetching origin
>>>> Traceback (most recent call last):
>>>>   File "/home/bms/bin/git-remote-bzr", line 956, in <module>
>>>>     sys.exit(main(sys.argv))
>>>>   File "/home/bms/bin/git-remote-bzr", line 928, in main
>>>>     repo = get_repo(url, alias)
>>>>   File "/home/bms/bin/git-remote-bzr", line 844, in get_repo
>>>>     bdir.destroy_repository()
>>>>   File "/usr/lib/python2.7/dist-packages/bzrlib/bzrdir.py", line 900, in
>>>> destroy_repository
>>>>     raise errors.NoRepositoryPresent(self)
>>>> bzrlib.errors.NoRepositoryPresent: No repository present:
>>>> "file:///home/bms/workspace/bugzilla/.git/bzr/origin/clone/"
>>>> error: Could not fetch origin
>>>>
>>>>
>>>> The following small patch seems to fix my regression:
>>>
>>> The patch is fine by me, in fact, I already had that patch, but
>>> somehow could not trigger the exception, so I removed it.
>>
>> Is it merely "fine", or needed for 1.8.3?  I am guessing it is the
>> latter but making a final double-check, as I'll be stopping to pick
>> up patches from the list in order to start today's integration run
>> (that includes tagging 1.8.3-rc3).
>
> Yes, for v1.8.3.

Thanks.