On Wed, May 1, 2013 at 12:44 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: > >> After being contacted by the emacs developers and others who are stuck with >> Bazaar, which at this point seems to be utterly abandoned, I realized the >> current implementation is too crude. >> ... >> That is of course, if pushing actually worked (which in many cases doesn't). >> >> In short, our support for real-world projects suck. >> >> These patches fix all the issues I encountrered. >> ... >> Finally, after all these changes I was finally able to clone the whole emacs >> repository, all 130685 commits, and 56 branches without running out of memory >> in my modest laptop. > > Yay ;-) > > I assume that the trees at a handful of key points (e.g. releases) > were verified to be identical with the original history and the > conversion result. Not really. I don't think the users are that interested in the history being identical at this point, merely that they can use it as a proxy to interact with bazaar repositories. People have found discrepancies, so I assume they have compared at least the tip of the branches, and found them. This probably means that the history is correct, since bazaar deals with changesets (git is one of the few DSCMs that don't). Also, there's further news on this, pushes seem to work correctly to the emacs' repo[1]. >> I'll ask the emacs developers to give them a try, and let's see >> how it goes. > > Yeah, that's the least we can do for both existing and future users. > > Generally speaking, post -rc0 is too late for "if no issues are > found", simply because no existing user has enough time to find > corner case regressions in her work using the new software (I do > not expect a trivial bug that can be uncovered in a few weeks of use > would remain in a version that has successfully converted the Emacs > history; but real world users always have different needs than what > we anticipate). > > I however am finding myself moderately receptive to this series. > That is primarily because this series touches only two files that > are totally isolated from the rest of the system. Even if they did > not work at all, there is no risk for the remainder of Git. Nobody > other than existing users of remote-bzr will even notice if we > merged this by the final. > > For existing users of remote-bzr that we shipped in 1.8.2, the story > is a bit different, though. If this series makes things worse in a > way your tests did not reveal, and if such a regression is not > reported and/or cannot be fixed by 1.8.3 final, that will mean a > real regression in the released version for them. > > If that ever happens, that would be the time for us to regret the > hasty decision to merge remote-bzr in 1.8.2, justifying that with a > "There wasn't anything working for interoperating with bzr, and here > is one to do so; anything is better than nothing", and learn from > that mistake (it is not an option to say "the 1.8.2 users chose to > use contrib/ material that are clearly marked as sub-par quality > with their own risk". If we did not ship it in 1.8.2, they did not > have to get burned with any regression and could have kept working > with bzr a bit longer. "Anything" is not necessarily better than > "nothing"). Fortunately there seem to be at least some users that find what is in 1.8.2 working to some extent, not in all the repositories, and not all the features, but at least something, which is much better than the alternatives, even the best one has been blocked for years, even when a solution is known[2]. > Hopefully, such a regression will not have to happen (for one thing, > I would expect that the existing 1.8.2 remote-bzr user base would be > very small). Also I somehow have a feeling that it is very unlikely > to happen, especially given your report: > > (1) the series converts Emacs history without barfing; and > > (2) you have some confidence in the conversion result after > inspecting at least a handful of key release points and trees > and metainformation match between the original and the > converted history. > > So let's go ahead and apply these directly on top of 'master', once > we hear from Emacs folks and they are happy with it. I'll queue it > on 'pu' so that I do not have to go back to the list archive when it > happens. I already heard that everything seems to be working correctly, except one feature, the biggest change, which I screwed up with a one-liner commit. That's why I added a test. Anyway, I've fixed it in my github branch and in this patch series, and I've told them to try the fix. Let's see. Cheers. [1] http://bzr.savannah.gnu.org/lh/emacs/xwidget/revision/101292 [2] https://bugs.launchpad.net/bzr/+bug/541626 -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html