| |||||||||||||
For the build farm...For the build farm...Posted Oct 12, 2010 20:16 UTC (Tue) by ejr (subscriber, #51652)Parent article: Lessons from PostgreSQL's Git transition
A URL that retrieves a specific head as a tar.gz should suffice. No need for any client other than an HTTP fetcher. The git web interfaces I know already include the facility.
(Log in to post comments)
For the build farm... Posted Oct 12, 2010 21:04 UTC (Tue) by gevaerts (subscriber, #21521) [Link]
That's a huge difference in bandwidth used
For the build farm... Posted Oct 12, 2010 23:03 UTC (Tue) by ewen (subscriber, #4772) [Link]
The work around that comes to mind is rsync and a wrapper that logs into a system that can run git and updates to the right version before the rsync. rsync will take an argument (-e) to log into the remote system and spawn rsync in daemon mode, and it's possible to use this to invoke a wrapper that logs into the remote system, does some prep, then spawns rsync in daemon mode. (--rsync-path is another means of inserting such a wrapper.) It'll be slightly fiddly to work out the right details, but once it's done it should be look after itself (assuming enough space on the proxy system to pull the whole git tree and keep it up to date). (And of course rsync should be at least as bandwidth efficient as CVS.)
Ewen
For the build farm... Posted Oct 15, 2010 17:03 UTC (Fri) by chad.netzer (✭ supporter ✭, #4257) [Link]
For that to work well, remember to use the '--rsyncable' option when creating the .tar.gz file, or simply don't compress the tarfile at all.
|
|||||||||||||