Re: [PATCH 12/20] remote-bzr: split marks file

2013-04-28 Thread Junio C Hamano
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

2013-04-28 Thread Felipe Contreras
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

2013-04-26 Thread Felipe Contreras
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

2013-04-26 Thread Junio C Hamano
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

2013-04-26 Thread Felipe Contreras
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

2013-04-25 Thread Felipe Contreras
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