Felipe Contreras <felipe.contre...@gmail.com> 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.
> Since the purpose of remote-bzr is to actually be usable for the
> poor souls stucks in DSCMs that are not git, these changes are a
> must. I propose they be merged for the next major version of git
> (v1.8.3) if no issues are found. They changes pass all the tests,
> and work on various repositories I've tried.
Nice.
> 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").
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.
Thanks.
--
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
