|
| Re: CVS and timestamps [message #289589 is a reply to message #289526] |
Mon, 08 August 2005 14:41   |
Eclipse User |
|
|
|
Originally posted by: Michael_Valenta.oti.com
To my knowledge the CVS clommand line client uses the timestamp from the
server when files are checked out or updated. Thus Eclipse behaves in this
same manner. If Tomcat doesn't behave properly when timestamps are changed
to be earlier, then this would seem to me to be a bug in Tomcat. The Eclipse
Java compiler works fine in this situation.
Michael
"Niklas Lindholm" <niklas@nilin.se> wrote in message
news:0981d5adc75e16d4ea596fed6ff7c1eb$1@www.eclipse.org...
> Hi!
>
> I have only recently started to use Eclipse so I may have missed
> something. It seems though as the timestamp handling with CVS controlled
> files is not correct, or at least not the same as with the normal command
> line client.
>
> When I fetch a local copy of a file from the repository it gets the
> timestamp of the checkin time to the repository. The command line client
> sets the timestamp to the current time.
>
> The same goes when abandoning some changes and getting the latest version
> from the repository. When I edit a file and save it will get the current
> time as timestamp. Then when go back to the repository version (either by
> deleting the local file and doing "cvs update" or by doing "cvs
> update -C") the timestamp of the file goes back to the old time. When
> doing the same with the command line client it gets the current time.
> I.e., time always move forward.
>
> This behaviour of Eclipse gives me problems with JSP files (in Eclipse
> WTP). JSP files are not compiled by Eclipse but by (in my case) Tomcat.
> And Tomcat keeps its own cached copies of the generated .java and .class
> files. When the timestamp of a file moves back in time like this Tomcat
> doesn't realize that it needs to recompile, and my changes don't take
> effect. I have to locate the cached files and delete them for things to
> work again. (And they are not easy to find.. :-)
>
> Is this a problem in Eclipse or have I missed something?
>
> /Niklas
>
|
|
|
|
| Re: CVS and timestamps [message #289730 is a reply to message #289671] |
Wed, 10 August 2005 13:07 |
| Eclipse User |
|
|
|
Originally posted by: Michael_Valenta.oti.com
Yes, I've tried it as well and you are right. You should log a bug against
Platform CVS.
Michael
"Niklas Lindholm" <niklas@nilin.se> wrote in message
news:323c0671d16bb78247449e5993719858$1@www.eclipse.org...
> As far as I can see that is not the behaviour of the command line client.
>
> Here is an example with cvs 1.12.11 using Linux.
>
> niklas@disco:~/bt> ll build.xml
> -rw-r--r-- 1 niklas users 16332 2005-08-07 20:29 build.xml
> niklas@disco:~/bt> rm build.xml
> niklas@disco:~/bt> cvs update build.xml
> U build.xml
> niklas@disco:~/bt> ll build.xml
> -rw-r--r-- 1 niklas users 16332 2005-08-09 20:12 build.xml
> niklas@disco:~/bt> date
> Tue Aug 9 20:12:44 CEST 2005
>
> The timestamp in the repository is July 31st.
>
> Using the repository timestamp would break things like ant/make that use
> the timestamp of the .java/.class (or .c/.o or whatever) to decide what
> needs to be rebuilt.
>
> /Niklas
>
> Michael Valenta wrote:
>
>> To my knowledge the CVS clommand line client uses the timestamp from the
>> server when files are checked out or updated. Thus Eclipse behaves in
>> this same manner. If Tomcat doesn't behave properly when timestamps are
>> changed to be earlier, then this would seem to me to be a bug in Tomcat.
>> The Eclipse Java compiler works fine in this situation.
>
>> Michael
>
>> "Niklas Lindholm" <niklas@nilin.se> wrote in message
>> news:0981d5adc75e16d4ea596fed6ff7c1eb$1@www.eclipse.org...
>>> Hi!
>>>
>>> I have only recently started to use Eclipse so I may have missed
>>> something. It seems though as the timestamp handling with CVS controlled
>>> files is not correct, or at least not the same as with the normal
>>> command line client.
>>>
>>> When I fetch a local copy of a file from the repository it gets the
>>> timestamp of the checkin time to the repository. The command line client
>>> sets the timestamp to the current time.
>>>
>>> The same goes when abandoning some changes and getting the latest
>>> version from the repository. When I edit a file and save it will get the
>>> current time as timestamp. Then when go back to the repository version
>>> (either by deleting the local file and doing "cvs update" or by doing
>>> "cvs update -C") the timestamp of the file goes back to the old time.
>>> When doing the same with the command line client it gets the current
>>> time. I.e., time always move forward.
>>>
>>> This behaviour of Eclipse gives me problems with JSP files (in Eclipse
>>> WTP). JSP files are not compiled by Eclipse but by (in my case) Tomcat.
>>> And Tomcat keeps its own cached copies of the generated .java and .class
>>> files. When the timestamp of a file moves back in time like this Tomcat
>>> doesn't realize that it needs to recompile, and my changes don't take
>>> effect. I have to locate the cached files and delete them for things to
>>> work again. (And they are not easy to find.. :-)
>>>
>>> Is this a problem in Eclipse or have I missed something?
>>>
>>> /Niklas
>>>
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.02805 seconds
] 
Search
Help
Register
Login
Home
