RE: [platform-vcm-dev] Team + Refactoring.... It's Back

[Matt_Conway@xxxxxx]

java.io.File.setLastModified() for setting it.

I think as long as the time stamp is different from the last time eclipse 
looked at that file, then eclipse knows that file has changed.  If my view 
of the repository is out of date, when I do the checkout preserving 
timestamps, it give the file the timestamp of the newer file, and thus 
eclipse knows the file has changed.  Of course, if for some reason the out 
of date file actually has a newer timestamp in the repository, it may 
break the refactor - but that scenario is unlikely unless you change the 
configuration for that view, and if you do that, it would be silly _not_ 
to tell eclipse to refresh.

Matt






"Zulli, Joseph" <Joseph.Zulli@xxxxxx>
Sent by: platform-vcm-dev-admin@xxxxxxxxxxx
08/23/02 01:06 PM
Please respond to platform-vcm-dev

 
        To:     <platform-vcm-dev@xxxxxxxxxxx>
        cc: 
        Subject:        RE: [platform-vcm-dev] Team + Refactoring.... It's Back


Thanks for the help.

Ahhh, so the timestamp is throwing it off..... I don't think my provider
can preserve the file modification time on checkout. You said that it's
possible to add code around the checkout to do this, but how? I see how
you can get the timestamp but not set it. 

Also, is this safe? What if you have a version 1 imported on your local
system, but the latest version in the repository is 2? Then when you
checkout during the refactor, version 2 will get checked out and the
contents of your file may change significantly. This would throw off the
refactor calculation, wouldn't it.

Thanks again,
Joe 

-----Original Message-----
From: Matt_Conway@xxxxxx [mailto:Matt_Conway@xxxxxx] 
Sent: Friday, August 23, 2002 8:54 AM
To: platform-vcm-dev@xxxxxxxxxxx
Subject: Re: [platform-vcm-dev] Team + Refactoring.... It's Back


I had the same problem doing exactly what you did - fortunately I was
able 
to force clearcase to preserver file modification time on checkout, 
thereby sidestepping the issue =)  Maybe your provider can do a similar 
thing?  If not, you could add code around your checkout that does it for

you.

Matt





"Zulli, Joseph" <Joseph.Zulli@xxxxxx>
Sent by: platform-vcm-dev-admin@xxxxxxxxxxx
08/22/02 02:28 PM
Please respond to platform-vcm-dev

 
        To:     <platform-vcm-dev@xxxxxxxxxxx>
        cc: 
        Subject:        [platform-vcm-dev] Team + Refactoring.... It's
Back



Hi everyone, 
I am implementing a pessimistic model Team provider and I can't seem to 
get Java refactoring to work for the life of me. I know that there was a

super long thread on refactoring but I'm still lost and I was hoping
that 
someone could help.
I implemented rename by implementing the IMoveDeleteHook interface. It 
works perfectly if you click on "Rename" from the navigator view. The 
problem occurs in the Java refactor operation. 
When I try to perform a Java refactor on a file it only works if the
file 
is checked out first. If the file has not been checked  out first, it
will 
get checked out automatically because I implemented 
IFileModificationValidator to check out files automatically when a user 
attempts to edit a file. Once the file is checked out, however, the 
refactor process fails and says that it cannot proceed because the file 
has been "modified since the beginning of this operation." 
Has anyone seen this before? This is a major problem, we can't let the 
user rename or modify a file in any way without it being checked out 
first. Do you know of any way to address this? Am I wrong  in putting my

check out code in the IFileModificationValidator class? I don't know of 
any better way to do it. There was mention in the newsgroup that maybe 
instead of putting the check out action in the
IFileModificationVaildator 
class it should be put in a resource delta mechanism of some sort. I
don't 
know how this would help though. 
Thanks in advance, 
Joe 



_______________________________________________
platform-vcm-dev mailing list
platform-vcm-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-vcm-dev
_______________________________________________
platform-vcm-dev mailing list
platform-vcm-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-vcm-dev