"Martin Letenay" <mle@whitestein.com> wrote on 09/27/2005 09:37:17 AM:
> > When I try this I do not get the problem. I also do not see
> > us add the -N option (which is probably why I do not see the
> > problem). Looking at the code, we only add the -N option
> > where the commit includes a folder with property changes. My
> > initial thought was that when the folder was deleted, it must
> > be returning true for prop changes. However, testing has
> > shown that not to be the case.
> >
> > If the commit really does include a folder with prop changes,
> > then I do not think we can drop the -N.
>
> It's a shoot from the hip, but few days ago I've noticed that when you
> refactor/rename
> some java package and that package folder also containt some non-java
files
> (e.g. resources),
> these files are naturally not (re)moved by the eclipse.
>
> Couldn't it be that we're trying to remove non-empty dir ?
I do not think that could be it, at least in this case. Ian was right.
The reason the reported got this message is that we specified -N on the
commit. If you look at his commit output it includes a parent folder of
the packages that he refactored. The only way that a folder gets into the
commit is if it contains a prop change. If we commit a prop change on a
folder, we always add -N to the commit.
In terms of your scenario, I do not see how it could happen (depending of
course on what Eclipse tells us to do. If Eclipse says to rename a
folder, we are going to issue an svn move, and Subversion itself would
handle moving the non-Java resources.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
Received on Tue Sep 27 23:41:25 2005