Hi,
This is the same as last series, except that I dropped a couple of conflicting
patches, and added one test.
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.
Bazaar branches are very simplistic, and our support for them is the same; we
need to create one remote per branch. This works nicely if you work on small
projects with few branches, but doesn't scale.
Big projects like emacs take a lot of space, and creating a remote per branch
is unrealistic, because each remote will have the whole Bazaar repository
copied, wasting space, and time each time a remote (for a bzr branch) is set
up.
Moreoever, a developer needs to constantly reset the master branch to the
commit he/she wants to push before pushing, since the transport-helper
infraestructure doesn't support pushing with refspecs (xwidget:master).
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.
1) First of all, there are several improvements for pushing. Before, we failed
when trying to push a merge, now, even tricky merges work.
2) Secondly, bzr branches are tied to a transport, so they time out if not
used for a period of time, and importing/exporting huge chunks of a
repository do take some time. So now they are only opened when they are
about to be used.
3) Then the big one; now bzr repositories are supported. They are very simple:
basically an object store with no notion of branches, so to find the
branches we need to traverse a directory (sometimes) remote, to find them.
This is how Bazaar does it, ableit very slowly. Naturally, a lot of code
had to be changed to support more than one branch.
4) In addition, now remotes share all the objects, so adding a new remote
doesn't imply fetchng a bunch of duplicated objects. They are just re-used
automagically.
5) Since the bzr objects are shared now, it only makes sense to share the
remote-bzr marks, so we don't have to fast-import them again.
6) The code was also reorganized to keep referenced as few objects as
possible, since Bazaar seems to be need *a ton* of memory for them.
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.
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. I'll
ask the emacs developers to give them a try, and let's see how it goes.
Felipe Contreras (18):
remote-bzr: cleanup CustomTree
remote-bzr: delay blob fetching until the very end
remote-bzr: fix order of locking in CustomTree
remote-bzr: always try to update the worktree
remote-bzr: add support to push merges
remote-bzr: fixes for branch diverge
remote-bzr: fix partially pushed merge
remote-bzr: use branch variable when appropriate
remote-bzr: add support for bzr repos
remote-bzr: fix branch names
remote-bzr: add support for shared repo
remote-bzr: improve author sanitazion
remote-bzr: add custom method to find branches
remote-bzr: add option to specify branches
remote-bzr: improve progress reporting
remote-bzr: iterate revisions properly
remote-bzr: delay peer branch usage
remote-bzr: access branches only when needed
contrib/remote-helpers/git-remote-bzr | 305 ++++++++++++++++++++++++----------
contrib/remote-helpers/test-bzr.sh | 72 ++++++++
2 files changed, 293 insertions(+), 84 deletions(-)
--
1.8.3.rc0.399.gc96a135
--
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