[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [platform-vcm-dev] Team + Refactoring.... It's Back
|
Joseph, your code is correct in checking out the file in the
IFileModificationValidator hook. There are two cases:
1. The file in the workspace (prior to checkout) is exactly the same as the
one being checked out from the server. The workspace state should not
change as a result of this operation.
2. The file from the server is newer than the one in the workspace.
Checking out will not only lock the file in the server but will overwrite
the workspace file with the newer content (changing timestamp).
In case #1, you shouldn't be modifying the file's timestamp since its the
same file. In case #2 this *should* result in a file with a different
timestamp.
For case #1 when preserving the timestamp, all should proceed as you
expect. If you 'needlessly' change the timestamp it will look to JDT like
case #2.
The problem for case #2 is that JDT does an initial analysis phase to
determine all the classes/methods that will be affected by a refactoring.
This analysis occurs prior to the validation hook being fired (and you
getting to checkout the file).
The catch is that modifying the file contents due to checkout invalidates
the refactoring analysis (for example, you could change who the superclass
is and thus invalidate the destination class for moving a method up the
hierarchy).
It is my understanding that in case #2 your checkout will succeed but the
entire refactoring will fail. In this case the user can attempt the same
refactoring, which will have a now correct analysis. Chances are that all
the files to be affected are now checked out due to the previous round, and
all should work ok. Because the files have new content, the refactoring
may actually touch a larger set of files with additional checkouts
required. This is why JDT doesn't just redo the analysis and proceed with
the refactoring automatically, because the process could in theory require
several iterations.
Kevin
Matt_Conway@xxxxxx
Sent by: To: platform-vcm-dev@xxxxxxxxxxx
platform-vcm-dev-admin@ cc:
eclipse.org Subject: RE: [platform-vcm-dev] Team + Refactoring.... It's
Back
08/26/2002 10:49 AM
Please respond to
platform-vcm-dev
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
_______________________________________________
platform-vcm-dev mailing list
platform-vcm-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-vcm-dev
