# [PATCH] remote-bzr: update old organization 17 messages from 2013-05-14 to 2013-05-17. Participants: Felipe Contreras, Junio C Hamano. Thread: https://gitlist.dev/t/33814 ## Felipe Contreras, 2013-05-14 04:20 Subject: [PATCH] remote-bzr: update old organization Message-ID: <1368505227-16661-1-git-send-email-felipe.contreras@gmail.com> URL: https://gitlist.dev/e/1368505227-16661-1-git-send-email-felipe.contreras%40gmail.com ``` 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 --- 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 ``` ## Junio C Hamano, 2013-05-14 17:30 Subject: Re: [PATCH] remote-bzr: update old organization Message-ID: <7v1u99lb8w.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7v1u99lb8w.fsf%40alter.siamese.dyndns.org In-Reply-To: <1368505227-16661-1-git-send-email-felipe.contreras@gmail.com> ``` Felipe Contreras 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 > --- 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() ``` ## Felipe Contreras, 2013-05-14 20:06 Subject: Re: [PATCH] remote-bzr: update old organization Message-ID: URL: https://gitlist.dev/e/CAMP44s1rZmo3cQecGmYVMZ7KSq%3Dz3_mfVnAK%2Bso4QL_JfEe_uw%40mail.gmail.com In-Reply-To: <7v1u99lb8w.fsf@alter.siamese.dyndns.org> ``` On Tue, May 14, 2013 at 12:30 PM, Junio C Hamano wrote: > Felipe Contreras 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 >> --- > > 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 ``` ## Junio C Hamano, 2013-05-14 20:36 Subject: Re: [PATCH] remote-bzr: update old organization Message-ID: <7v8v3hi9ix.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7v8v3hi9ix.fsf%40alter.siamese.dyndns.org In-Reply-To: ``` Felipe Contreras writes: > On Tue, May 14, 2013 at 12:30 PM, Junio C Hamano wrote: >> Felipe Contreras 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 >>> --- >> >> 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, 2013-05-14 20:50 Subject: Re: [PATCH] remote-bzr: update old organization Message-ID: URL: https://gitlist.dev/e/CAMP44s2B3bFWXZe0aL_GMXe_56MbhSZXf-65rT364nY3shYwUA%40mail.gmail.com In-Reply-To: <7v8v3hi9ix.fsf@alter.siamese.dyndns.org> ``` On Tue, May 14, 2013 at 3:36 PM, Junio C Hamano wrote: > Felipe Contreras writes: > >> On Tue, May 14, 2013 at 12:30 PM, Junio C Hamano wrote: >>> Felipe Contreras 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 >>>> --- >>> >>> 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, 2013-05-14 20:57 Subject: Re: [PATCH] remote-bzr: update old organization Message-ID: URL: https://gitlist.dev/e/CAMP44s16VD%2BRm5J%3DTXxQB%2BpKhpzHqoxBXSSwDvi0CVW2u2J%3D5g%40mail.gmail.com In-Reply-To: ``` On Tue, May 14, 2013 at 3:50 PM, Felipe Contreras wrote: > On Tue, May 14, 2013 at 3:36 PM, Junio C Hamano wrote: >> Felipe Contreras writes: >> >>> On Tue, May 14, 2013 at 12:30 PM, Junio C Hamano wrote: >>>> Felipe Contreras 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 >>>>> --- >>>> >>>> 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, 2013-05-14 21:18 Subject: Re: [PATCH] remote-bzr: update old organization Message-ID: <7v4ne5i7lf.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7v4ne5i7lf.fsf%40alter.siamese.dyndns.org In-Reply-To: ``` Felipe Contreras 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. ``` ## Felipe Contreras, 2013-05-14 21:38 Subject: Re: [PATCH] remote-bzr: update old organization Message-ID: URL: https://gitlist.dev/e/CAMP44s0CgYs9s1ac1EEqhP8XusScj39zY6CcQyMxSnh6i-V6SA%40mail.gmail.com In-Reply-To: <7v4ne5i7lf.fsf@alter.siamese.dyndns.org> ``` On Tue, May 14, 2013 at 4:18 PM, Junio C Hamano wrote: > Felipe Contreras 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, 2013-05-14 22:05 Subject: Re: [PATCH] remote-bzr: update old organization Message-ID: <7vvc6lfc98.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vvc6lfc98.fsf%40alter.siamese.dyndns.org In-Reply-To: ``` Felipe Contreras 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, 2013-05-14 22:14 Subject: Re: [PATCH] remote-bzr: update old organization Message-ID: <7vk3n1fbus.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vk3n1fbus.fsf%40alter.siamese.dyndns.org In-Reply-To: <7vvc6lfc98.fsf@alter.siamese.dyndns.org> ``` Junio C Hamano writes: > Felipe Contreras 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, 2013-05-14 22:17 Subject: Re: [PATCH] remote-bzr: update old organization Message-ID: URL: https://gitlist.dev/e/CAMP44s2L9CsLu%2Bhr4McVzUnb7x%2BuipEs5nHKLg%2B69BicMaJjpA%40mail.gmail.com In-Reply-To: <7vk3n1fbus.fsf@alter.siamese.dyndns.org> ``` On Tue, May 14, 2013 at 5:14 PM, Junio C Hamano wrote: > Junio C Hamano writes: > >> Felipe Contreras 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, 2013-05-14 22:33 Subject: Re: [PATCH] remote-bzr: update old organization Message-ID: <7v7gj1fayr.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7v7gj1fayr.fsf%40alter.siamese.dyndns.org In-Reply-To: ``` Felipe Contreras writes: > On Tue, May 14, 2013 at 5:14 PM, Junio C Hamano wrote: >> Junio C Hamano writes: >> >>> Felipe Contreras 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, 2013-05-14 22:43 Subject: Re: [PATCH] remote-bzr: update old organization Message-ID: URL: https://gitlist.dev/e/CAMP44s0%2BnFHB56tdpCCbjurKhmaNfk39UaWEQBF4V2fb-hcwOQ%40mail.gmail.com In-Reply-To: <7v7gj1fayr.fsf@alter.siamese.dyndns.org> ``` On Tue, May 14, 2013 at 5:33 PM, Junio C Hamano wrote: > Felipe Contreras writes: > >> On Tue, May 14, 2013 at 5:14 PM, Junio C Hamano wrote: >>> Junio C Hamano writes: >>> >>>> Felipe Contreras 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, 2013-05-17 10:33 Subject: Re: [PATCH] remote-bzr: update old organization Message-ID: URL: https://gitlist.dev/e/CAMP44s3zXLwHu0OhLKsoerHaoBGMf66hNJ%3DhvOiUVAe4%2B%3DhDiA%40mail.gmail.com In-Reply-To: ``` On Fri, May 17, 2013 at 5:02 AM, Sandor Bodo-Merle 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 > 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, 2013-05-17 17:09 Subject: Re: [PATCH] remote-bzr: update old organization Message-ID: <7vzjvtzg61.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vzjvtzg61.fsf%40alter.siamese.dyndns.org In-Reply-To: ``` Felipe Contreras writes: > On Fri, May 17, 2013 at 5:02 AM, Sandor Bodo-Merle 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 >> 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, 2013-05-17 17:12 Subject: Re: [PATCH] remote-bzr: update old organization Message-ID: URL: https://gitlist.dev/e/CAMP44s2DogT71%2BcQJK8Yu0xcAbuYB-6T3TwMKyuh12wCR%2BsK8g%40mail.gmail.com In-Reply-To: <7vzjvtzg61.fsf@alter.siamese.dyndns.org> ``` On Fri, May 17, 2013 at 12:09 PM, Junio C Hamano wrote: > Felipe Contreras writes: > >> On Fri, May 17, 2013 at 5:02 AM, Sandor Bodo-Merle 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 >>> 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, 2013-05-17 17:58 Subject: Re: [PATCH] remote-bzr: update old organization Message-ID: <7vbo89zdwr.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vbo89zdwr.fsf%40alter.siamese.dyndns.org In-Reply-To: ``` Felipe Contreras writes: > On Fri, May 17, 2013 at 12:09 PM, Junio C Hamano wrote: >> Felipe Contreras writes: >> >>> On Fri, May 17, 2013 at 5:02 AM, Sandor Bodo-Merle 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 >>>> 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. ```