ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Widmer <tom.wid...@gmail.com>
Subject Re: Timestamps
Date Wed, 28 Oct 2009 12:30:38 GMT
Andreas Axelsson wrote:
> When I run ivy:retrieve, all dependencies that are copied to my lib folder maintains
the date of the file in the cache. That means when I change my dependency to a version which
has an older date, even if the revision is newer, the file won't be copied to the lib folder,
as the retrieve code looks more or less like this:
> 
> foreach file in moduleFilesInCache {
>    if shouldCopy(file, target) copy(file, target);
> }
> 
> bool shouldCopy(file, target) {
>    if !exists(targetFile) return true;
>    return target.date < file.date;
> }
> 
> Basically, ivy:retrieve will never copy a file with an older date over a later one, even
if that's what you ask it to do.
> 
> The problem is only in the retrieve step, resolve actually resolves the correct version
and copies it to the cache.
> 
> However, when Ivy populates the cache, it keeps the timestamp of the original file it
downloads, at least for the FileSystemResolver. (We only use Ivy to manage our internal modules
at the moment.) I'm not sure if it's the publish date or if it's the date when the file was
originally built, but that makes little difference in this case. The end result is that the
only way to get an older version copied to my lib folder is to clean it first.
>  
> IMHO, the behavior is kind of violating the principle of least surprise, when you're
used to how most build tools and version control systems timestamp files on update. Compare
it with your normal build rule of "build output if older than input" or when checking out
an earlier version of a source repository.
> 
> Also, while going to a lower revision might be a situation that you can handle manually,
by cleaning, say that I'm upgrading to a higher revision that's been built earlier than the
current. It wouldn't be completely unlikely that the patch revision (e.g. 1.0.2) of a module
has been published later than the next point release (e.g. 1.2.0).

<caches checkUpToDate="false"/> prevents the uptodate check during retrieve.

Tom


Mime
View raw message