Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 187485 - Versioning problems with refactoring
Versioning problems with refactoring
Product: versioncontrol
Classification: Unclassified
Component: Code
: P2 (vote)
Assigned To: Ondrej Vrabec
Depends on: 189921
  Show dependency treegraph
Reported: 2010-06-11 14:13 UTC by Tomas Stupka
Modified: 2014-11-05 12:02 UTC (History)
4 users (show)

See Also:
Issue Type: TASK


Note You need to log in before you can comment on or make changes to this bug.
Description Tomas Stupka 2010-06-11 14:13:05 UTC
Comment 1 Jaroslav Tulach 2010-08-06 08:46:58 UTC
When celebrating Tomáš's birthday, I foolishly promised to move this issue forward by end of this week.

OK, I've extended the wiki page with some options we have. I want to bring this to wider attention and as such I am initiating dicussion via API reviews. If you care about filesystems or refactorings, please have a look at

As far as I can say. I'd like to primarily solve the copy problem and address Nr.1 and Nr.2 for folders. To do so, I think it is enough to do a bit of "Enhancing" as outlined in the wiki.
Comment 2 Jesse Glick 2010-08-11 15:01:47 UTC
Not sure I understand what is actually being proposed by way of API.

This perplexes me:

FileObject folder = ...;
FileObject originalFile = ...;
boolean deleteOriginal = ...;
FileObject res = folder.createCopy(originalFile, outputStream, deleteOriginal);

1. What is deleteOriginal for? If you wanted to delete the original file, why would you not just call FileObject.move(...)?

2. We already have FileObject.copy(...). Why not just make it work properly without messing with the API (other than perhaps some semiprivate SPI from masterfs)?

Agreed with -1 on making VCS infer a logical operation, and -1 on transactions (a lot of work to get that right). Probably -1 on FileSystem.Plan though I don't think I see what the proposal there is.
Comment 3 Jesse Glick 2010-08-11 15:05:22 UTC
Do note w.r.t. package rename refactoring that if you have


and rename p1 to p1a, the expected outcome is


In this case the current behavior of the IDE is probably correct; e.g. 'hg mv src/p1 src/p1a' would not work, you would want 'hg mv src/p1/C[12].java src/p1a' or 'hg mv src/p1/ src/p1a/; hg mv src/p1/ src/p1a/'.
Comment 4 Jaroslav Tulach 2010-08-17 15:36:54 UTC
The problem with move and copy is that often one does not want to transfer the same content. With current API one could do:

newFo = fo.move(...);
String txt = newFo.asString().replace(...);

The same applies to copy. I don't find this very comfortable. That is why I suggested some new method that would tell the VCS what command to call and still have control over the written down content.

But OK, we can try to stick with existing API and see what happens.
Comment 5 Jesse Glick 2010-08-17 16:56:12 UTC
(In reply to comment #4)
> With current API one could do:
> newFo = fo.move(...);
> String txt = newFo.asString().replace(...);
> newFo.getOutputStream().write(txt.getBytes());
> I don't find this very comfortable.

Other than being slightly inefficient, what is the problem here? Seems intuitive enough - you are moving a file, then you are editing it - and should be handled correctly by any VCS.
Comment 6 Tomas Stupka 2010-08-27 09:35:13 UTC
filed #189921 to cover copy handling
Comment 7 Jaroslav Tulach 2014-11-05 12:02:44 UTC
Obsolete, I guess.

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo