Mark Phippard schreef:
> news <news@sea.gmane.org> wrote on 10/07/2005 03:14:17 PM:
>
>
>>1 have a versioned Java project.
>>2 right-click on a package and do Refactor -> Rename, rename it.
>>=> Subclipse marks for deletion all the old files and for addition a
>>copy of them, under the new directory.
>>(This only seems to work with a top-level package, renaming a sublevel
>>package (i.e. one which does not contain classes, only other packages)
>>just makes a new one with the new name, the old package stays there with
>
>
>>all its classes -> Eclipse bug?)
>
>
> When a folder is "deleted" it stays on your system until it is committed.
Yes, but it gets a red cross through it. That wasn't even there. It
was as if only a copy _of the directory without its contents_ with
another name was made.
>>3 (This seems to be the step which causes the problem:) Edit one of the
>>moved files, even if it is only a minor deleting of a word.
>>4 Try a commit.
>>5 Get the error:
>>Transaction is out of date
>>svn: Commit failed (details follow):
>>svn: Out of date: '/trunk/MSO/de/unituebingen/sfb/macke/formulas' in
>>transaction '37-1'
>
>
> I do not think #5 has anything to do with #3. That error message is
> common. When you delete/move/rename a folder (or change its properties)
> the folder can only be committed if it is at the HEAD revision. So you
> should right-click on the project and do Team -> Update. Depending on
> what you receive, then do Team -> Commit.
Before I started all this, I was at a fresh working copy, with no
changes at all, at HEAD. So I don't understand what you mean. I am the
only one using the repository (yet), so there is no way that there could
have been changes.
>>If I don't edit after the renaming, i.e. leave out step three, then it
>>seems to work fine. Trying cleanup and another commit gives me the
>
> error:
>
>> Filesystem is corrupt
>>svn: Commit failed (details follow):
>>svn: Invalid change ordering: new node revision ID without delete
>>
>>And this one keeps coming.
>
>
> This might have something to do with where you do commit. When doing
> refactoring, I would suggest always doing Team -> Commit from the project
> level so that all aspects of the refactoring can be committed in the same
> transaction.
I did that.
(Added other post)
>>Reverting didn't work either, with the same (?) error message.
>>
>>The problem got solved by doing Ctrl-z in the file which I edited
>>manually until nothing was there anymore, and doing a commit then.
>>Strange thing is, Eclipse changes the files also during the renaming
>>process (all package declarations get changed!), but Subclipse does not
>>complain about that.
>
>
> I just tried and do not get a problem. Leading me to believe it is
still
> a matter of doing an update.
As mentioned above, it is impossible that I was not at HEAD.
> I refactored a package named x.y.z to x.a.z, then edited the class in
the
> new package and committed all of it.
>
> Let me know if the test had to be something like refactor package x to y.
I renamed a package called de.unituebingen.sfb.macke.formulas to
de.uni_tuebingen.sfb.macke.formulas, then edited the file And.java which
is in there.
(Added another post)
> One thing I just noticed is that the refactoring of a package works
> differently if you are doing a package which has sub-packages. For some
> reason, Eclipse only does the package you selected, and not the sub
> packages. Consequently, we cannot just do an svn move to do the
> refactoring. Instead, we do svn add to create the new folder, and do
svn
> move on all of the files to move them to the new folder. That explains
> the other UI differences.
Indeed, but this _is_ an Eclipse bug right? It should refactor all its
subpackages as well. Except when one wanted to rename a package with
all its included _classes_ but without the subpackages. Which seems a
bit strange to me.
At the time of my previous cry for help though, I refactored a package
which has subpackages and no files in them. That time it went
completely wrong. This last time, I only refactored a top-level
package, which lead to the problems described above.
> Since the original folder is not deleted, but no longer has any classes,
> it just disappears from the view.
No, the original folder is still there, with all its contents. Only a
new folder with the new name is created.
> As opposed to the other case where it
> remains in the view as a delete.
>
> That being said, all of the above worked and Subclipse behaved
> surprisingly pefectly. I just had to be at the HEAD revision.
Hm. I really don't want to loose any more time with this, I'm sorry.
Next time, the safest solution is: commit before you do a package
refactoring, and commit immediately after.
H.
--
Hendrik Maryns
==================
www.lieverleven.be
http://aouw.org
Received on Sat Oct 8 06:11:34 2005