Hi Stephen,<br>Thank you for the comments as well.<br><br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I think you vastly underestimate the strength of the git architecture.<br>
</blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Why would you expect them to? CVS checkouts don't behave like<br>
branches, SVN checkouts don't behave like branches, and git and<br>
Mercurial checkouts don't even bother to exist, let alone behave like<br>
branches. The whole philosophy of checkouts is that they are *not*<br>
branches. Is this just a reference to your request for "lightweight<br>
branches"?<br></blockquote><div><br>Yes :)<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">
</div>This is a noop. A commit that succeeds in one repository will succeed<br>
in *all* related repositories once it gets there ("related" meaning<br>
that the parent commit(s) is (are) available in all repositories).<br></blockquote><div><br>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.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
*Distributed* read/write is what DVCS is all about. You are asking<br>
for system-wide guarantees of *synchronous* read/write meaning all the<br>
repositories are sync'ed. I agree that current DVCSes are not able to<br>
handle this; I question your implicit assumption that your *development<br>
management* systems are capable of doing their part given an advanced<br>
DVCS that can do what you specify. OTOH, I think that current DVCSes,<br>
properly used, probably can keep up with the development process you<br>
actually use.<br></blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Assuming by "proxy bound to master" you mean "bzr bind", I believe<br>
you're misunderstanding. True, currently I don't think you can<br>
recursively bind to (or checkout from) a branch which is bound to yet<br>
another branch. However, if you clone the proxy, AIUI a local commit<br>
in the clone does not update the proxy or the master, but a push to<br>
the proxy will update not only the proxy but also the bound master.<br></blockquote><div><br>Ah maybe a push would work - I didn't try. But why would you want to propagate a push and not a commit?<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">
</div></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">It had better be; that's what DVCS means. Unless I don't understand<br>
what you mean by "blocking" here.<br></blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">
</div>Well, your whole set of requirements is incompatible with DVCS<br>
philosophy (but Bazaar intends to be more than "just DVCS", so that in<br>
itself is no problem). However, given those requirements, update on<br>
reconnection seems like the obvious solution. Coherency check on<br>
checkout/branch is insufficient, you'd really need a coherency check<br>
on every update, so I don't think that idea will work.<br></blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">
</div>Mercurial may still require this (its support for "named branches" was<br>
way inadequate as of v1.1, but they're up to 1.4 now so that may have<br>
changed). But both git and Bazaar allow many branches to share<br>
repositories; cloning a large repository only needs to happen once per<br>
project per developer (at most).<br></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Of course you still may want to avoid that, but I think you are way<br>
overestimating the costs.<br></blockquote><div>In this day and age of terabyte disks, I don't understand why a<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
one-time cost of 80GB, or even 800GB, sets you back that way.<br></blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
However, it might be an interesting idea to convert content, not to<br>
fastimport format, but to git object (compressed) format or even git<br>
packs.<br>
<br>
</blockquote></div><br>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?).<br>