[PATCH 00/20] remote-bzr: massive changes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

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.

Cheers.

Felipe Contreras (20):
  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: split marks file
  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
  remote-bzr: export HEAD

 contrib/remote-helpers/git-remote-bzr | 365 +++++++++++++++++++++++++---------
 contrib/remote-helpers/test-bzr.sh    |  36 ++++
 2 files changed, 302 insertions(+), 99 deletions(-)

-- 
1.8.2.1.884.g3532a8d

--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]