Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Bo Berglund wrote: >> The repository should be at the supplyer site, as the do a lot of ci/co. >> > And why do you think this is necessary at all? I don't know about the OP's case, but one reason why I might think about a mirrored repository at some time is that a local repository can speed up diffs quite a bit. This may be one reason for distributed teams to have mirrored read-only servers. (It's actually the only one I can think of, but it could be enough of a reason.) Generally, it seems that it's not so much the ci/co/up traffic that determines where to best place the server, it's the diff traffic. The way I work, I can always run the co/up traffic in the background and do something useful while it completes, so the time it takes is not that relevant. Similarly, ci traffic is usually limited by the time it takes me to write commit comments -- before I finish the next commit comment, the previous commit has gone a few times around the globe :) And if it's a big batch commit, the same applies as to co/up traffic: I can do something useful while it completes. But diffs are a lot more time-critical. They usually happen when investigating some problem, during debugging and troubleshooting, and interactively, with me anxiously waiting for the diff to show up, sometimes doing a few in a row. So for me, that's what I want to have /quick/. It is easily imaginable that a number of developers want this quick, and this is where mirrored read-only repositories could come handy. Gerhard