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
http://wiki.netbeans.org/RefactoringFSandVCS

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.

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.

Do note w.r.t. package rename refactoring that if you have

src/
src/p1/
src/p1/C1.java
src/p1/C2.java
src/p1/sub/
src/p1/sub/C3.java

and rename p1 to p1a, the expected outcome is

src/
src/p1a/
src/p1a/C1.java
src/p1a/C2.java
src/p1/
src/p1/sub/
src/p1/sub/C3.java

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/C1.java src/p1a/C1.java; hg mv src/p1/C2.java src/p1a/C2.java'.

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(...);
newFo.getOutputStream().write(txt.getBytes());

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.

(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.

filed #189921 to cover copy handling

Obsolete, I guess.