Thanks for the suggestion, but the resolve step actually does everything correctly so the problem is not related to resolving the correct revision. In fact I'm specifying a specific revision, latest strategies would only be used if I entered some kind of dynamic revision. The problem is that retrieve only looks at the file date when it determines if the files in the lib folder needs updating or not. And when I revert back to an older version, it will usually have an older date (on the server and in the cache after resolve) and won't be copied.
/axl -----Original Message----- From: Glidden, Douglass A [mailto:[email protected]] Sent: den 27 oktober 2009 18:07 To: [email protected] Subject: RE: Retrieve fails to revert to earlier version > Also, if for some reason the 1.0 version has a later date than the 2.0 > version, say it's a late bug fix, 2.0 wouldn't overwrite 1.0 in step 5. I can't address the bulk of your question, but I did want to mention that this slightly parenthetical issue sounds like a problem with your latest-strategy setting--it sounds like it's using the latest-time strategy instead of the latest-revision strategy. Doug Glidden Software Engineer The Boeing Company [email protected] -----Original Message----- From: Andreas Axelsson [mailto:[email protected]] Sent: Monday, October 26, 2009 11:43 To: [email protected] Subject: Retrieve fails to revert to earlier version Is it intended behavior that reverting to an older version of a dependency requires a clean-lib before retrieve? The RetrieveEngine seem to only check the dates of files when it determines what to copy to the lib dir after a resolve. Example: 1. Make ivy.xml depend on some module 1.0. 2. Clean the lib dir. 3. Running retrieve populates the lib dir with the correct files. 4. Update the ivy.xml to depend on version 2.0. 5. Running retrieve populates the lib dir with the correct files. 6. Revert ivy.xml back to depend on version 1.0. 7. Run retrieve and see Ivy say that no files are required. The lib dir still contains the 2.0 files. Resolve will correctly log that it resolves against the specified version and the resolve log and cache are updated with the correct versions at all times. Also, if for some reason the 1.0 version has a later date than the 2.0 version, say it's a late bug fix, 2.0 wouldn't overwrite 1.0 in step 5. My solution at the moment is to have my ant script run a clean-lib if the ivy.xml is newer than the lib folder, but it feels like a kludge. /axl
