Login | Register
My pages Projects Community openCollabNet

Discussions > dev > [Subclipse-dev] package refactor issues

subclipse
Discussion topic

There will be a brief maintenance window every Friday at 17:00 Pacific.
For further details, see CollabNet's maintenance and upgrade policy.

Hide all messages in topic

All messages in topic

Re: [Subclipse-dev] package refactor issues

Author selsemore
Full name Stephen Elsemore
Date 2010-05-21 13:43:34 PDT
Message I don't see exactly the behavior that you're describing. If I use Eclipse
to refactor and rename the package, I am able to to then commit the
deleted/added packages and classes without any problem. I am not told that
the file is out of date (unless it actually is out of date for some
unrelated reason).

I do notice that when renaming a package causes the package's parent folder
to end up empty, then I end up with an empty parent folder (because only the
package itself is flagged for deletion, not its parent folder).

For example, if I have:

com.mycompany.mypackage

...and I rename it to:

com.myRenamedcompany.myPackage

...and com.mycompany did not contain any other classes or packages besides
myPackage, then I end up with an empty com.mycompany package.

When I delete this package and try to commit, then I am told that I am out
of date, and when I update I do get a tree conflict (local delete, incoming
edit upon update). Unfortunately, I think this might make sense from a
strictly Subversion point of view, as the previous commit caused the
com.mypackage properties to be updated in the repository. ?

I agree that mass resolution of tree conflicts would be useful. Maybe, when
Mark Resolved is selected for multiple tree conflicts, I dialog should
prompt you to either simply mark all the selected conflicts resolved, or
deal with them one by one?


On 5/20/10 5:17 AM, "Dan Lo Bianco" <dan.lobianco@clo​udsoftcorp.com> wrote:

> I've spent a fair amount of time googling about this issue, but I've yet to
> find a definitive answer or solution. For the past few months I've been
> struggling with subclipse when it comes to renaming java packages. I've
> finally been able to come up with a working procedure, but it all seems rather
> unwieldy for what should be a simple action.
>
> Currently, my method for renaming packages starts off with the most logical
> step- using eclipse to refactor and rename the package. Initially, this seems
> to work fine- the old packages + classes are marked for deletion, while the
> new renamed versions come up as new files (but with history, so the history is
> preserved). However, at this point things start to go wrong- any attempt to
> synchronise or commit and SVN seems to choke and will indicate the file is out
> of date. Synchronising seems to then flag the old package as having a
> 'conflicting deletion'.
>
> Fixing that is a bit of a headache. First, running the update command seems to
> convert the 'conflicting deletion' into a 'tree conflict'. Once you have the
> tree conflict, you can view them in the SVN Tree Conflicts view, but for each
> offending package you must manually select the resolve dialog, untick a
> checkbox (so you force the deletion through rather than reverting back to the
> old version on SVN), before confirming the resolution. With 5 - 15 packages
> per project and at least 20 projects, this is a very repetitive task.
>
> Is there a reason tree conflicts can't be resolved en-masse (certainly in the
> case of pushing the local changes through as authentic, i.e. equivalents to
> 'override and update' and 'mark as merged' for files)? Also, am I doing
> something wrong when it comes to renaming packages, or does everyone have to
> go through all these hoops?
>
> --------------------​--------------------​--------------
> http://subclipse.tig​ris.org/ds/viewMessa​ge.do?dsForumId=1043​&dsMessageId=261​13
> 02
>
> To unsubscribe from this discussion, e-mail:
> [dev-unsubscribe@sub​clipse.tigris.org].

[Subclipse-dev] package refactor issues

Author danikov
Full name Dan Lo Bianco
Date 2010-05-20 05:17:22 PDT
Message I've spent a fair amount of time googling about this issue, but I've yet to find a definitive answer or solution. For the past few months I've been struggling with subclipse when it comes to renaming java packages. I've finally been able to come up with a working procedure, but it all seems rather unwieldy for what should be a simple action.

Currently, my method for renaming packages starts off with the most logical step- using eclipse to refactor and rename the package. Initially, this seems to work fine- the old packages + classes are marked for deletion, while the new renamed versions come up as new files (but with history, so the history is preserved). However, at this point things start to go wrong- any attempt to synchronise or commit and SVN seems to choke and will indicate the file is out of date. Synchronising seems to then flag the old package as having a 'conflicting deletion'.

Fixing that is a bit of a headache. First, running the update command seems to convert the 'conflicting deletion' into a 'tree conflict'. Once you have the tree conflict, you can view them in the SVN Tree Conflicts view, but for each offending package you must manually select the resolve dialog, untick a checkbox (so you force the deletion through rather than reverting back to the old version on SVN), before confirming the resolution. With 5 - 15 packages per project and at least 20 projects, this is a very repetitive task.

Is there a reason tree conflicts can't be resolved en-masse (certainly in the case of pushing the local changes through as authentic, i.e. equivalents to 'override and update' and 'mark as merged' for files)? Also, am I doing something wrong when it comes to renaming packages, or does everyone have to go through all these hoops?
Messages per page: