Re: [PATCH 12/20] remote-bzr: split marks file
Junio C Hamano gits...@pobox.com writes: Felipe Contreras felipe.contre...@gmail.com writes: And in case anybody is thinking that remote-bzr is really a too fast moving target; even if this managed to land in 'master', it's likely that people were not able to push at all, and in fact, many were not even able to clone in 1.8.2. So, hardly could be considered a regression. Nevertheless, I caught it in time. You didn't. I am already way too deep into today's 1.8.3-rc0 integration cycle and I won't waste a couple of hours work just to revert this. Oh, I was lucky ;-) I mistook this with the other 9-patch bzr clean-up series that I applied to 'master' for -rc0. Pushing out a tagged-tip takes a lot longer than the normal tip because a lot more than what people see have to happen on my end. Reverting a single patch is simple, but we do not want to do that on top of Git 1.8.3-rc0 commit and move the unpublished tag to point at the revert. Which means pretty much everything needs to be redone (one example among many is that the tagname will propagate to the htmldocs and manpages repositories, so their unpublished histories need to be rewound). But I didn't have to do that in the end ;-) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/20] remote-bzr: split marks file
On Sun, Apr 28, 2013 at 1:47 PM, Junio C Hamano gits...@pobox.com wrote: Junio C Hamano gits...@pobox.com writes: Felipe Contreras felipe.contre...@gmail.com writes: And in case anybody is thinking that remote-bzr is really a too fast moving target; even if this managed to land in 'master', it's likely that people were not able to push at all, and in fact, many were not even able to clone in 1.8.2. So, hardly could be considered a regression. Nevertheless, I caught it in time. You didn't. I am already way too deep into today's 1.8.3-rc0 integration cycle and I won't waste a couple of hours work just to revert this. Oh, I was lucky ;-) I mistook this with the other 9-patch bzr clean-up series that I applied to 'master' for -rc0. Pushing out a tagged-tip takes a lot longer than the normal tip because a lot more than what people see have to happen on my end. Reverting a single patch is simple, but we do not want to do that on top of Git 1.8.3-rc0 commit and move the unpublished tag to point at the revert. Which means pretty much everything needs to be redone (one example among many is that the tagname will propagate to the htmldocs and manpages repositories, so their unpublished histories need to be rewound). But I didn't have to do that in the end ;-) Yeah, I realized you were talking about that one later on. I haven't heard anything bad from this new branch from emacs developers, so I think it's OK to merge it. Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/20] remote-bzr: split marks file
On Thu, Apr 25, 2013 at 8:08 PM, Felipe Contreras felipe.contre...@gmail.com wrote: This way all the remotes can share the same git objects, and the same marks. The information we want to store per remote is very small. The code transparently converts from one organization of marks, to the other. It's rather smooth and there shouldn't be any issues. Please drop this patch. While testing essentially the same functionality in remote-hg I noticed that it doesn't work when dealing with more than one remote. It's not clear if the marks can be shared at all, and if possible, it would be very tricky. Better drop it for now. I've tested that dropping this patch doesn't cause an conflicts for the rest of the series. And in case anybody is thinking that remote-bzr is really a too fast moving target; even if this managed to land in 'master', it's likely that people were not able to push at all, and in fact, many were not even able to clone in 1.8.2. So, hardly could be considered a regression. Nevertheless, I caught it in time. Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/20] remote-bzr: split marks file
Felipe Contreras felipe.contre...@gmail.com writes: And in case anybody is thinking that remote-bzr is really a too fast moving target; even if this managed to land in 'master', it's likely that people were not able to push at all, and in fact, many were not even able to clone in 1.8.2. So, hardly could be considered a regression. Nevertheless, I caught it in time. You didn't. I am already way too deep into today's 1.8.3-rc0 integration cycle and I won't waste a couple of hours work just to revert this. But from your description it sounds like with or without the patch the helper is equally broken and it does not make that much of a difference. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/20] remote-bzr: split marks file
On Fri, Apr 26, 2013 at 7:17 PM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: And in case anybody is thinking that remote-bzr is really a too fast moving target; even if this managed to land in 'master', it's likely that people were not able to push at all, and in fact, many were not even able to clone in 1.8.2. So, hardly could be considered a regression. Nevertheless, I caught it in time. You didn't. I am already way too deep into today's 1.8.3-rc0 integration cycle and I won't waste a couple of hours work just to revert this. All right, if you already merged this patch series, you could do what I did in my public branch: revert it, it's a single command, doesn't take hours. But I don't see this series in origin/master, am I missing something? But from your description it sounds like with or without the patch the helper is equally broken and it does not make that much of a difference. Indeed. Many people would need this patch series to push, and this patch breaks the push for more than one remote. So if you merged the whole thing quite likely their situation would improve; they could at least push to one remote, instead of zero. Of course, if you remove this patch, they would be able to push to many. But I don't see it merged. Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/20] remote-bzr: split marks file
This way all the remotes can share the same git objects, and the same marks. The information we want to store per remote is very small. The code transparently converts from one organization of marks, to the other. It's rather smooth and there shouldn't be any issues. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- contrib/remote-helpers/git-remote-bzr | 58 ++- 1 file changed, 43 insertions(+), 15 deletions(-) diff --git a/contrib/remote-helpers/git-remote-bzr b/contrib/remote-helpers/git-remote-bzr index 9fe830e..fcd8e41 100755 --- a/contrib/remote-helpers/git-remote-bzr +++ b/contrib/remote-helpers/git-remote-bzr @@ -52,22 +52,42 @@ def gittz(tz): class Marks: -def __init__(self, path): -self.path = path +def __init__(self, gitdir, dirname): +self.marks_path = os.path.join(gitdir, 'bzr', '.marks-bzr') +self.remote_path = os.path.join(dirname, '.marks-bzr') +old_path = os.path.join(dirname, 'marks-int') + self.tips = {} self.marks = {} self.rev_marks = {} self.last_mark = 0 -self.load() + +if not os.path.exists(old_path): +self.load() +else: +self.old_load(old_path) +os.remove(old_path) def load(self): -if not os.path.exists(self.path): -return -tmp = json.load(open(self.path)) +if os.path.exists(self.marks_path): +tmp = json.load(open(self.marks_path)) +self.marks = tmp['marks'] +self.last_mark = tmp['last-mark'] + +for rev, mark in self.marks.iteritems(): +self.rev_marks[mark] = rev + +if os.path.exists(self.remote_path): +tmp = json.load(open(self.remote_path)) +self.tips = tmp['tips'] + +def old_load(self, path): + +tmp = json.load(open(path)) self.tips = tmp['tips'] -self.marks = tmp['marks'] -self.last_mark = tmp['last-mark'] +self.marks = tmp['marks'] # TODO remove +self.last_mark = tmp['last-mark'] # TODO remove for rev, mark in self.marks.iteritems(): self.rev_marks[mark] = rev @@ -76,7 +96,10 @@ class Marks: return { 'tips': self.tips, 'marks': self.marks, 'last-mark' : self.last_mark } def store(self): -json.dump(self.dict(), open(self.path, 'w')) +d = { 'marks': self.marks, 'last-mark' : self.last_mark } +json.dump(d, open(self.marks_path, 'w')) +d = { 'tips': self.tips } +json.dump(d, open(self.remote_path, 'w')) def __str__(self): return str(self.dict()) @@ -348,10 +371,10 @@ def export_tag(repo, name): print def do_import(parser): -global dirname +global gitdir repo = parser.repo -path = os.path.join(dirname, 'marks-git') +path = os.path.join(gitdir, 'bzr', '.marks-git') print feature done if os.path.exists(path): @@ -678,14 +701,14 @@ def do_export(parser): print def do_capabilities(parser): -global dirname +global gitdir print import print export print refspec refs/heads/*:%s/heads/* % prefix print refspec refs/tags/*:%s/tags/* % prefix -path = os.path.join(dirname, 'marks-git') +path = os.path.join(gitdir, 'bzr', '.marks-git') if os.path.exists(path): print *import-marks %s % path @@ -848,8 +871,13 @@ def main(args): repo = get_repo(url, alias) -marks_path = os.path.join(dirname, 'marks-int') -marks = Marks(marks_path) +marks = Marks(gitdir, dirname) + +# move old marks +old_gitmarks = os.path.join(dirname, 'marks-git') +new_gitmarks = os.path.join(gitdir, 'bzr', '.marks-git') +if os.path.exists(old_gitmarks): +os.rename(old_gitmarks, new_gitmarks) parser = Parser(repo) for line in parser: -- 1.8.2.1.884.g3532a8d -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html