emacs-devel
[Top][All Lists]
Advanced

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

Re: Emacs Bazaar repository


From: Thien-Thi Nguyen
Subject: Re: Emacs Bazaar repository
Date: Thu, 13 Mar 2008 10:04:54 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

() dhruva <address@hidden>
() Thu, 13 Mar 2008 13:34:56 +0530

   IMHO, the performance aspects must be considered seriously.

If performance can't be engineered into the entire system, the
usual (serious) way to do it is to use hierarchy to partially
separate the slow parts from the fast parts.

 CPU <-> L[1...n]-CACHE <-> MEMORY <-> DISK <-> NETWORK

Here, CPU can spin as fast as it wants.  It is not limited by
speeds between other elements of the hierarchy, apart from
L1-CACHE, and yet can (if All Goes Well :--) conduct useful
dialogue w/ NETWORK anyway.

I think a similar arrangement is best for my case:

 ttn <-> git <-> bzr <-> address@hidden

Since i cannot make bzr faster, i do my local spinning w/ Git.
Presently, i'm still (half-heartedly) searching for the git/bzr
gateway, hoping someone will post a url...  btw, i see there is
already some thought on the problem for Git and Mercurial:
<http://thunk.org/tytso/blog/2007/03/24/git-and-hg/>.

For the email-only crowd, on that webpage, Theodore T'so sez:

| So basically git does have short-comings, yes, but people will
| come out in different places about which tools is best for them,
| and that’s OK. Actually, I think the ultimate solution for this
| problem is to build a bidrectoinal hg/git gateway. There are
| tools that will export from hg to git, and vice versa, and they
| are actually pretty sophisticated. I don’t think it should be
| that painful to create a tool that does incremental exports in
| both directions, maintaining state so that the right thing
| happens when a commit gets made on the git side, and gets
| exported into hg, or vice versa. Ultimately I think that’s the
| best solution, since that way people can use whatever tool they
| want, and still contribute and development as first class
| citizens. This is the main reason why I’ve held off on
| converting e2fsprogs to git (although I have made some private
| test repositories which I’ll use to take advantage of git’s
| superior annotation and query/log utilities); I don’t want to
| make a git repository of e2fsprogs public until I’m sure that a
| bidrectional gateway tool won’t require me to make any changes
| that affect the commit-id’s, since that would invalidate any
| work that people have done that was based on a clone of the
| coverted git repository.
|
| I have a rough design for how to do the bidirectional gateway,
| but the issue is finding time to implement it. Anyone with free
| time looking for a project? If so, contact me. I probably should
| have written this up as a potential Google Summer of Code
| project, but it’s too late for this year. Oh, well.

IMHO, it's just a matter of time until some Righteous Hacker
stitches it all together.  It's a nice problem.

thi




reply via email to

[Prev in Thread] Current Thread [Next in Thread]