Feedback from evaluation in a corporate environment

[Uri Moszkowicz]

Hi Stephen,
Thank you for the comments as well.

I think you vastly underestimate the strength of the git architecture.
>

I considered that possibility and ran some benchmarks to determine if that
was the case. Sadly, it is not. At least, not with Bazaar, which as I
understand is comparable in performance to Mercurial and GIT now. While I
was writing the last email, I finally clocked in my last branch at 47min and
that's still optimistic for the real deployment.


> Why would you expect them to?  CVS checkouts don't behave like
> branches, SVN checkouts don't behave like branches, and git and
> Mercurial checkouts don't even bother to exist, let alone behave like
> branches.  The whole philosophy of checkouts is that they are *not*
> branches.  Is this just a reference to your request for "lightweight
> branches"?
>

Yes :)


>  This is a noop.  A commit that succeeds in one repository will succeed
> in *all* related repositories once it gets there ("related" meaning
> that the parent commit(s) is (are) available in all repositories).
>

Not if multiple people are committing at the same time. The up-to-date check
may pass on the first few repositories and then fail at some point in the
middle because someone else was committing to them all at the same time but
visited them in a different order. That person will then run into the same
problem hitting the repositories that you've already hit.


*Distributed* read/write is what DVCS is all about.  You are asking
> for system-wide guarantees of *synchronous* read/write meaning all the
> repositories are sync'ed.  I agree that current DVCSes are not able to
> handle this; I question your implicit assumption that your *development
> management* systems are capable of doing their part given an advanced
> DVCS that can do what you specify.  OTOH, I think that current DVCSes,
> properly used, probably can keep up with the development process you
> actually use.
>

That is correct. I'm not sure how a DVCS can keep up with our development
process. It seems to me that staffing changes would need to be made as well
as work on the software in the repository itself. Not an easy task for a
team as described in my last email and not clear that it would be worth the
investment. As I said earlier, I thought Bazaar's strength was that is could
support a variety of workflows so I'm somewhat surprised at the resistance
to supporting a previously unknown workflow, one that I suspect is fairly
common in corporate environments.


> Assuming by "proxy bound to master" you mean "bzr bind", I believe
> you're misunderstanding.  True, currently I don't think you can
> recursively bind to (or checkout from) a branch which is bound to yet
> another branch.  However, if you clone the proxy, AIUI a local commit
> in the clone does not update the proxy or the master, but a push to
> the proxy will update not only the proxy but also the bound master.
>

Ah maybe a push would work - I didn't try. But why would you want to
propagate a push and not a commit?


>  It had better be; that's what DVCS means.  Unless I don't understand
> what you mean by "blocking" here.
>

I meant that the only time that your prompt is blocked is the time that it
takes to transfer your local changes to your local server. The propagation
around the network of repositories would happen independently among the
machines involved in hosting those repositories.


>  Well, your whole set of requirements is incompatible with DVCS
> philosophy (but Bazaar intends to be more than "just DVCS", so that in
> itself is no problem).  However, given those requirements, update on
> reconnection seems like the obvious solution.  Coherency check on
> checkout/branch is insufficient, you'd really need a coherency check
> on every update, so I don't think that idea will work.
>

True, sort of. You could delay the coherency check until a push/commit since
it won't matter until then, though you might want to discover it earlier.
It's not expected to happen often so minimizing opportunities to pay the
cost is a good tradeoff. The trouble with update on reconnection is there no
way to pass the message to the repository that it needs to update as it may
not know that it was disconnected. Only the agent that tried to send the
message knows that it's long gone. Either you need a persistent agent (like
a daemon) or a way to discover a messenger who dropped the ball and clean up
after it.


>  Mercurial may still require this (its support for "named branches" was
> way inadequate as of v1.1, but they're up to 1.4 now so that may have
> changed).  But both git and Bazaar allow many branches to share
> repositories; cloning a large repository only needs to happen once per
> project per developer (at most).
>

> Of course you still may want to avoid that, but I think you are way
> overestimating the costs.
>
In this day and age of terabyte disks, I don't understand why a

> one-time cost of 80GB, or even 800GB, sets you back that way.
>

Storage space is only cheap on desktops - not on network appliances, which
are commonly found in the corporate environment. Then there's the cost of
administering that data, backing it up / minimizing restore time, network
bandwidth to support the extra traffic, etc. We're already using several TB
and that's with 1GB sandboxes. And that's still ignoring the time that it
takes to actually create the repositories. These are problems that you have
to deal with in companies with 1000s of employees. Perforce has won a lot of
business because the OS DVCS tools haven't addressed the needs that I'm
describing.


>
> However, it might be an interesting idea to convert content, not to
> fastimport format, but to git object (compressed) format or even git
> packs.
>
>
Yes I think something like this is necessary. I could also use a pipe but I
was hoping to keep it around. I expect that the conversion would still take
a really long time though (maybe 1 week at the rate it was going?).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20100107/fc491ce6/attachment.htm