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_at_cloudsoftcorp.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.tigris.org/ds/viewMessage.do?dsForumId=1043&dsMessageId=26113
> 02
>
> To unsubscribe from this discussion, e-mail:
> [dev-unsubscribe_at_subclipse.tigris.org].
------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1043&dsMessageId=2611882
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_subclipse.tigris.org].
This is a multi-part message in MIME format.
------------=_4BFD081B.C58B87AD
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Spam detection software, running on the system "giant.haxx.se", has
identified this incoming email as possible spam. The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: get_the elegant Rolex replica also more... http://highcostcertainl.ru
[...]
Content analysis details: (27.9 points, 3.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
3.8 BAYES_99 BODY: Bayes spam probability is 99 to 100%
[score: 1.0000]
3.7 HELO_DYNAMIC_IPADDR2 Relay HELO'd using suspicious hostname (IP addr
2)
2.8 FH_HELO_EQ_D_D_D_D Helo is d-d-d-d
0.0 TVD_RCVD_IP TVD_RCVD_IP
6.0 DS_SUBJECT_DESIGNBRANDS Subject mentions designer brand
6.0 DS_BODY_DESIGNBRANDS BODY: mentions designer brand(s)
1.7 RDNS_DYNAMIC Delivered to internal network by host with
dynamic-looking rDNS
1.3 INVALID_MSGID Message-Id is not valid, according to RFC 2822
0.0 TO_NO_BRKTS_DYNIP To: misformatted and dynamic rDNS
2.6 TO_NO_BRKTS_DIRECT To: misformatted and direct-to-MX
------------=_4BFD081B.C58B87AD
Content-Type: message/rfc822; x-spam-type=original
Content-Description: original message before SpamAssassin
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Return-Path: <sergio.lopez_at_daemon.co.uk>
Received: from 207-118-223-85.dyn.centurytel.net (207-118-223-85.dyn.centurytel.net [207.118.223.85])
by giant.haxx.se (8.14.3/8.14.3/Debian-9.1) with SMTP id o4QBc0VE001957
for <daniel_at_haxx.se>; Wed, 26 May 2010 13:38:01 +0200
Date: Wed, 26 May 2010 06:38:39 -0700
From: "johnr" <sergio.lopez_at_daemon.co.uk>
MIME-Version: 1.0
To: daniel_at_haxx.se
Subject: Rolex, Beitling, Bvlgari, Cartier, Chanel, Tag Heuer, and lots more.
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Message-ID: <4BFD245F.8060200@>
X-Greylist: Delayed for 00:10:06 by milter-greylist-4.3.5 (giant.haxx.se [80.67.6.50]); Wed, 26 May 2010 13:38:02 +0200 (CEST)
X-Friend: Not my friend
get_the elegant Rolex replica also more... http://highcostcertainl.ru
------------=_4BFD081B.C58B87AD--
Received on 2010-05-21 22:43:32 CEST