Tom,
Thanks much for the "eternal" reference. That is a good thing to note
and I will give it a try.
With that said, I had thought we had set our behavior such that we have
a 12 hour TTL for the "remote" caches. Despite that, it still seems to
take a *very* long time to resolve and appears to be going back out the
SVN resolvers. I will take a look at the Ant debug output once again to
see what is going on, but I'm wondering if there is something else I
might be missing that is causing this behavior?
Thanks,
Craig
On 10/27/09 6:17 AM, Tom Widmer wrote:
Craig Setera wrote:
Hello,
We are still getting our heads around all that Ivy offers and trying
to apply it to our build infrastructure along with Hudson. In
general, things are working pretty well for us, but while on a flight
last week, I found that despite having a fully primed resolution
cache, that resolution still wanted to call out and check the cache,
causing build failures while disconnected. It was my understanding
that the caching should have been able to take care of this, but
obviously we aren't doing something correctly. I'm hoping someone
can shed some light on what we might be doing wrong. Our Ivy
settings file is embedded below.
Thanks for any insights,
Craig
When running disconnected, you could set:
ivy.cache.ttl.default
to "eternal". This means that cached dynamic revisions should not be
re-checked at all. You can also do this explicitly using a cache element:
<cache name="remote-cache" useOrigin="false" blah>
<ttl duration="${remote.ttl.duration}"/>
</cache>
(use this cache for your svn resolvers)
Now your ant script can somehow arrange to set remote.ttl.duration to
"eternal" if you are offline, or to 0ms (or similar) if you are online.
Tom
