Discussions
Categories
Groups
Community Home
Categories
INTERNAL ENABLEMENT
POPULAR
PUBLIC CLOUD
PRIVATE CLOUD
Quick Links
MY LINKS
HELPFUL TIPS
Back to website
Home
Web CMS (TeamSite)
How to force OpenDeploy to ignore datetimestamp
dazza1
When doing a directory comparison, is it possible to force OpenDeploy to ignore the file datetime stamp when comparing files.
i.e. the files are identical on the source and target but the datetime stamps are different so OpenDeploy tries to deploy the file.
I'm using OD 5.6.
Find more posts tagged with
Comments
Michael
In the OD 5.6 admin guide on page 159 it describes the dateDifferent attribute. I believe this will do what you describe.
Hope this helps.
Cheers, Michael
InvoicePlanNameIssue.jpg
nipper
I think he is trying to avoid datedifferent & have OD use diff/checksum to determine if a file should be replaced.
From his question, if I use touch to update the modified time, it is then datedifferent & the same file will be overwritten.
I do not think this is possible since the line by line compare would be a fairly expensive (resource) pocedure, it would be much faster to just replace the file.
Remember this would be done on your prod web server (since that has the source) and the file would need to be transported to do a compare anyway.
one could, in theory, do a check sum in TS and on the web server and push if they are different. OD DOES NOT do that, and I am not too certain it is worth while.
Andy
dazza1
Yes, I have content on a web server with the datetime stamp of the files up to year old. I now have new content that I want to deploy to the server but although the content of some of the files is exactly the same (only difference is the modified date), OpenDeploy wants to deploy all the content (as it sees the source files as being newer than the target files).
DateDifferent was my first thought but all it allows is for you to deploy older files rather than jst newer files. I don't care if the files are older or newer, I only want to deploy if the files are different.
Michael
Unless I am confused -- and I have just tested it out to make sure -- I believe dateDifferent="no" does what you describe.
Your source content has more recent timestamps than your target content. You wish to deploy from source to target but you don't want it to compare timestamps when determining what files to deploy.
Specifying dateDifferent="no" in your target such as
<target useReplicationFarm="PortalFarm">
<comparisonRules dateDifferent="no" />
<targetFilesystem area="/opt/product/iw-home/opendeploy/OpenDeployNG/tmp"/>
</target>
shoudl give you the result you are after.
This tells OpenDeploy not to compare timestamps, it will however continue to compare files based upon the criteria on page 158 (Comparison Rules).
A small point I have about the doco which might be causing some confusion is highlighted below:
dateDifferent — indicate whether (yes) or not (no) a file should be deployed if there is any difference in file date (older or newer) between the source and target versions. This differs from the OpenDeploy default date-based comparison setting, where a file is deployed only if the source file is newer than the target file. A value of yes indicates that the file should be deployed.
Default value is no.
The dateDifferent attribute is mutually exclusive with the revert attribute.
I don't think there is a default value for dateDifferent. Putting dateDifferent="no" in your comparisonRules produces a different result to not having it in at all. It does state that about two sentences previous but it confused me all the same -- perhaps that is just me though
I hope this helps.
Cheers, Michael
dazza1
Thanks Michael. I have been playing around with all of the comparison rules settings - even explicitly stating 'dateDifferent="no"' but alas, still the same.
I don't know if this is an issue with OD5.6 or if it is something to do with the fact that my target host is running 5.5 and there is a compatibility issue with the two versions?
I may just have to bite the bullet and just deploy all the files once and then hope that the 'dateDifferent="no"' directive kicks in for subsequent deployments.