Ken Smith wrote: > On Sat, Jan 10, 2004 at 11:06:58AM -0600, Kirk Strauser wrote: >> Out of curiosity, why would multiple syncs be better than just one? >> Wouldn't the final sync be the same whether you'd done several before it >> or not? > > It all depends on where you're sync-ing from. Keep in mind the > cvsup mirror sites are exactly that - mirrors. There is one > central CVS repository. If a developer is doing an update of the > main CVS repository as several commits there can be several minutes' > worth of time that what's in the CVS repository is "inconsistent" > because what s/he committed first contains things that depend on > things that s/he commits a little bit later (composing log messages > can take time, etc.). > > cvsup-master itself mirrors from the main CVS repository roughly > every 10 minutes I think. So if it takes a snapshot between the > developer's first and second commit and if you're using cvsup-master > as where you sync from then doing two sync's 10 to 20 minutes apart > can help with this sort of problem if you watch what gets updated > to watch for stuff that "seems related". > > Virtually every other public cvsup mirror site will be mirroring > from cvsup-master, but typically with about an hour between syncs. > > There are things that can make things a little bit more complicated > than this. For example last night's 5.2-RELEASE tag touches a huge > number of files. cvsup-master's load was around 50 for a while, and > it took one machine I was watching over an hour to do the first sync > after the tagging. A mirror site won't make changes 'visible' to > its downstream sites until it completes its own sync. The second cvsup could get you the first portion of another developer's update. Likewise for the third, fourth, etc. I think the most efficient way is to cvsup once and build. If the build fails, you can quite quickly check the commit logs (http://www.freshsource.org/commits.php is a great resource for this) and re-cvsup if necessary. If seems to me that multiple cvsups back-to-back are a drain on bandwidth and server load with dubious benefits. Jon NoackReceived on Sat Jan 10 2004 - 10:15:15 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:37 UTC