On Tue, 19 Apr 2005 11:25:52 -0400, Mark Phippard wrote:
> First to clarify something, Subclipse does not Delete/Add, that is what
> Subversion does under the covers when you do Move/Rename. Actually it
> does Copy/Delete, but Copy is really just a special kind of Add.
That's what I meant :-)
> The problem is that Subversion does not allow you to do what you are
> trying to do. Neither does TortoiseSVN. Try them both and you will see.
Right, I just checked in the commandline. Unfortunately it seems that
eclipse will happily ignore this restriction, allowing me to do the
second rename (back to the original name). That seems to be the root of
the problem. Unfortunately eclipse makes this renaming business really
easy and it's just too easy to forget about svn when you're in the middle
of a refactoring session.
> You can enter an issue in our issue tracker if you would like. Ideally,
> we could behave the way TortoiseSVN does and not allow the second rename.
> It might be impossible to do this in Eclipse though since we are not the
> ones that are contributing the rename actions to begin with. However,
> presumably we can communicate to the refactoring mechanism that the rename
> cannot proceed.
Do you have any idea if this is a lot of work or complicated to do? Or
would it be better to ask the Subversion team for a "real" rename (which
is mentioned on the roadmap as 'mid-term'). This should make the problem
go away since the second rename would restore the filename to its .svn
state and simply mark it (M)odified if I edited it, just as usual.
I'm not sure there's much of a point spending lots of time with subclipse
workarounds if the root cause is really Subversion's behaviour.
I guess I'll just ask on svn-users and see what the devs think.
Thanks!
Holger
Received on Wed Apr 20 05:57:34 2005