ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject AW: Comparing Files on Two Servers
Date Wed, 15 Dec 2004 07:06:22 GMT
Hhmmm - do you know the modified selector?


> -----Urspr√ľngliche Nachricht-----
> Von: Brent Bain []
> Gesendet am: Dienstag, 14. Dezember 2004 22:08
> An: ''
> Betreff: Comparing Files on Two Servers
> Hello:
> I'm hoping to save some time during deployments by comparing 
> a local zip
> file against a remote server's zip file.  My first thought 
> was to use the
> checksum task, but the timestamps are deffinately going to be 
> different.
> The basic idea is this:
> Perform a local build and zip up the files.
> Compare the local zip file against a remote zip file
>     If it's different then push the new zip file and extract 
> on the remote
> machine.
>     If it's not different, don't do anything.
> I tried this with the checksum task originally.  I would 
> generate a file
> that gets pushed to the remote machine at the same time I 
> push the zip file
> if things were different.  Then I can just grab the checksum 
> file from the
> remote machine and compare it against whats newly built/zipped.
> In theory the byte size could be the same (a boolean gets 
> changed from 0 to
> 1 in a prop file for example).
> So is this hopeless?  I'm looking at saving 2-3hrs over the 
> course of a day
> if I can somehow detect that there were indeed changes.
> My other thought was to parse the VSS history to see if there 
> are any files
> that have changed -- but again -- that seems slower then just 
> a compare of
> the files.
> Needless to say, simply comparing the date (OutOfDate task or 
> UpToDate task)
> won't work since the zip file will be newly made and the same 
> file on the
> remote machine might be several days/weeks old.  My other 
> challenge is that
> I only have SSH and FTP access to the remote machine...
> If someone else has run into this or if anyone else has some 
> tips that I'm
> just overlooking I would greatly appreciate it!!
> In advance, many thanks!!!
> Brent

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message