threads / patch / 33814

patchremote-bzr: update old organization

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

## tl;dr

17 messages between May 14, 2013 and May 17, 2013. Diffs are folded; open one to read it.

replies: 16people: 2as markdown or json

Felipe Contreras· May 14, 2013, 04:20 UTC · lore

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(+)
Show changes to contrib/remote-helpers/git-remote-bzr +7 −0
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
Junio C Hamano· May 14, 2013, 17:30 UTC · re: Felipe Contreras · lore

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

Felipe Contreras <felipe.contreras@gmail.com> writes:
Show 6 quoted lines
> 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.
Show 21 quoted lines
>  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()
Felipe Contreras· May 14, 2013, 20:06 UTC · re: Junio C Hamano · lore

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

On Tue, May 14, 2013 at 12:30 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 11 quoted lines
> 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.

Show 6 quoted lines
> 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
Junio C Hamano· May 14, 2013, 20:36 UTC · re: Felipe Contreras · lore

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

Felipe Contreras <felipe.contreras@gmail.com> writes:
Show 26 quoted lines
> 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?

Felipe Contreras· May 14, 2013, 20:50 UTC · re: Junio C Hamano · lore

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

On Tue, May 14, 2013 at 3:36 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 34 quoted lines
> 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
Felipe Contreras· May 14, 2013, 20:57 UTC · re: Felipe Contreras · lore

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

On Tue, May 14, 2013 at 3:50 PM, Felipe Contreras <felipe.contreras@gmail.com> wrote:

Show 96 quoted lines
> 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
Junio C Hamano· May 14, 2013, 21:18 UTC · re: Felipe Contreras · lore

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

Felipe Contreras <felipe.contreras@gmail.com> writes:
Show 15 quoted lines
> 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.

Felipe Contreras· May 14, 2013, 21:38 UTC · re: Junio C Hamano · lore

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

On Tue, May 14, 2013 at 4:18 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 21 quoted lines
> 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
Junio C Hamano· May 14, 2013, 22:05 UTC · re: Felipe Contreras · lore

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

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).

Junio C Hamano· May 14, 2013, 22:14 UTC · re: Junio C Hamano · lore

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

Junio C Hamano <gitster@pobox.com> writes:
Show 8 quoted lines
> 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.
Felipe Contreras· May 14, 2013, 22:17 UTC · re: Junio C Hamano · lore

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

On Tue, May 14, 2013 at 5:14 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 19 quoted lines
> 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
Junio C Hamano· May 14, 2013, 22:33 UTC · re: Felipe Contreras · lore

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

Felipe Contreras <felipe.contreras@gmail.com> writes:
Show 24 quoted lines
> 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.
Felipe Contreras· May 14, 2013, 22:43 UTC · re: Junio C Hamano · lore

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

On Tue, May 14, 2013 at 5:33 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 30 quoted lines
> 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
Felipe Contreras· May 17, 2013, 10:33 UTC · lore

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

On Fri, May 17, 2013 at 5:02 AM, Sandor Bodo-Merle <sbodomerle@gmail.com> wrote:
Show 21 quoted lines
> 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
Junio C Hamano· May 17, 2013, 17:09 UTC · re: Felipe Contreras · lore

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

Felipe Contreras <felipe.contreras@gmail.com> writes:
Show 26 quoted lines
> 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.
Felipe Contreras· May 17, 2013, 17:12 UTC · re: Junio C Hamano · lore

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

On Fri, May 17, 2013 at 12:09 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 33 quoted lines
> 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
Junio C Hamano· May 17, 2013, 17:58 UTC · re: Felipe Contreras · lore

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

Felipe Contreras <felipe.contreras@gmail.com> writes:
Show 36 quoted lines
> 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.

← back to recent threads