Trent W. Buck wrote: > > "Tom Hawkins" <[EMAIL PROTECTED]> writes: > > Yes, but without committing the push on the remote machine. Consider > > our company's development environment: some of our team is at the > > office connected to a high speed LAN, and others are in the field > > connected via a slow cell modem. If an engineer in the office > records > > a patch, and an engineer in the field pulls the patch 3 hours later, > > he has to wait. However, if the patch information starts propagating > > to the rest of the team at the time of record, when someone does a > > pull it could appear to be instantaneous. > > I don't see why that's not achievable with a cron job -- note that it > doesn't have to pull the patch into the field operative's "real" repo, > it can just be pulled into a temporary one. That would seed > ~/.darcs/cache.
Agreed. Use your operating system's scheduler and an automated darcs pull -a to a temporary repository or local mirror, or even a tool like rsync (Unix) or robocopy (Windows). I was thinking that perhaps a "slow pull" tool might be neat; a simple command line tool that you can set up in DARCS_GET_IDLE and DARCS_MGET_IDLE to allow for the actual download to get shunted off to a low priority/idle bandwidth download tool such as Windows' Background Intelligent Transfer Service (BITS). That way your clients aren't hit with a big IO jump every time your scheduled darcs pull occurs, as it would only use idle bandwidth. The only issue that might still annoy clients would be the CPU jump when all the files finished download and it hits darcs apply... I'm wondering if a --dont-apply advanced flag for darcs pull might be handy in such a situation. It could be confusing if used badly, but might have merit for the case when you are just trying to prime ~/.darcs/cache. -- --Max Battcher-- http://worldmaker.net _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
