Danek Duvall wrote: > On Wed, Sep 17, 2008 at 01:44:50PM -0700, Mike Sullivan wrote: > > >> My concerns are failed builds and now having to coordinate two putbacks >> (and that not involving me having to wake up at 3am to copy someones tar >> file :). >> > > We could always require that the RTI not be approved until the tarballs are > in place. And the tarballs can always be put in place long before the > putback happens, just to be ready. > I don't really like separating the tarballs from the gate and I don't think that forcing tarball integration prior to RTI approval solves all of the problems. If hg is capable of it (and I haven't looked into it enough), we can add hooks to force the upload of missing tarballs at commit (push) time and download of tarballs when a workspace is cloned or pulled. This would mirror the behaviour we get from teamware, without the overhead of keeping the individual tarballs in hg. It does add the extra dependency for push, pull, and clone on a separate upload/download service or mechanism that needs to work connected and disconnected (grandchild of the gate while off the network), but your push, pull, or clone fails if the gate is not "completely" available and you know right away.
> SMA will still have to keep their tarball in the gate, or give up on their > craptastic method of updating the tarball in place. > That has been needing to be fixed for a LONG time now. I am inclined to delete their tarball and replace it with a new "current" version prior to cutover. Once replaced, they can continue to apply patches. > As for potential network outages, we can create a mechanism to pre-download > the tarballs and point the build at a cache directory instead of > downloading on each build. That would also allow multiple copies of the > gate to share the disk space and download time (and cost) associated with > the tarballs, which is likely a huge win, on the balance, for everyone. > See above, but this should happen as part of the workspace clone or update process, possibly via hg hooks.We can definitely do this via a build target, but it would be better if we could do this through hg hooks. That way it would happen as part of the workspace clone or update process. > I think getting that working is probably worth pushing out the target > build, if it can't be done in that time, but that's probably more up to the > tech lead and whatever steam valve you happen to be facing. :) > I am inclined to agree. If we can address this up front, we should. If it means pushing off the migration a build or so, then I will take any flack for it. The long term benefits of resolving this now are well worth postponing the cutover some if we have to.. It's not like there isn't enough other stuff to do here, but we can at least explore it a little further. Are there any mercurial experts here that want to step up to help solve this? provide assistence? , ... -Norm
