Concerning annotation updates:

addFileStatusListener(FileStatusListener) should be a part of
org.openide.filesystems.FileSystem.FileStatus (instead of the
FileSystem itself)

Created attachment 20160 [details]
Proposed implementation

Marosi, please evaluate the attached solution and if ok, reassign to
Radek to polish and integrate it.

Patch seems to work well, emulates current VCS behavior. I have 2
questions: 

1. How well will new and old VCS supports coexist?
2. I suppose that other logical views (ie. not based on Dataobjects),
if they'd work with the filesystem as DOs do, will be annotable as
well, right?

I expected that the support for current VCS would be removed before
this patch is integrated. It need not be, but it would be simpler if
it was. If not, everyone is queried. The provider and the underlaying
filesystems.

If logical views use DataNode, they will get annotated behaviour. If
not, they can always use 

fo.getFileSystem().getStatus().annotateName(fo.getName(),
Collections.singleton(fo));

to talk to VCS support without using data systems at all.

We will not be able to replace current VCS support that fast because
of number of versioning systems currently supported. We will deliver
new support progressively one by one (CVS first). That's why we ask
for compatibility, i.e. *presence* of one module won't break the
other. If one mounts/manages the same directory in both systems at the
same time the behavior can be undefined.

I see. In such case the current patch is fine as it keeps
functionality of both. You can try it if you want.

I am returning the issue to Radek to continue with integration.

Complete patch is applied to openide/masterfs in vcslite branch.

Can we have it intergrated into 4.1 codebase? The reason is that we'd like to
release a CVSlite beta version on autoupdate which works with 4.1. In current
state we would also have to bundle mfs with it.

I prefer you to bundle mfs with it for 4.1.

There are initial patches under javacvs/cvsmodule/patches covering
 - Editor tab coloring (issue #57900)
 - Actions on J2SE project node (issue #57776)
 - Progress API integration

/cvs/openide/masterfs/src/org/netbeans/modules/masterfs/MasterFileObject.java,v
 new revision: 1.38.2.1; previous revision: 1.38

/cvs/openide/masterfs/src/org/netbeans/modules/masterfs/MasterFileSystem.java,v
 new revision: 1.18.2.3; previous revision: 1.18.2.2

/cvs/openide/masterfs/src/org/netbeans/modules/masterfs/providers/Attic/AnnotationProvider.java,v
 new revision: 1.1.2.2; previous revision: 1.1.2.1

/cvs/openide/masterfs/src/org/netbeans/modules/masterfs/providers/Attic/InterceptionListener.java,v

 new revision: 1.1.2.1; previous revision: 1.1

I looket at InterceptionListener. 
1) I am not quite sure how to use it as an interception facility. Can I delete
the FileObject myself in beforeDelete()? If so, how do I indicate that I failed?
2) If I do not wish to provide annotations, can I still be an interceptor? I ask
because getInterceptionListener() is in AnnotationProvider which surprised me.

Recent simple (possibly wrong) idea how to address folder delete problem in CVS.

Store deleted folder names into their parent folder CVS/folders.removed which
can be achieved using existing FileChangeListener.fileDeleted(). It means that
CVS support would not cache any metadata. Instead it would recreate them on fly
(here directly from repository instead of from intercepted&cached metadata) by
contacting repository if CVS/folders.removed detected. DRAWBACK: it can not
detect conflicts (file to be removed was in meantime changed in repository).

Interesting idea. This approach would also delete all files that were originally
NOT in user workdir and were added by some other user. In other words, we would
not be able to detect, what files were actually deleted. It would also be a lot
slower.

org.netbeans.modules.masterfs.providers is just a friend contract (no public
API). Moreover all changes are in branch. So, we can easily play with it. Maybe
you won't need any interception att all (seems to me according to P.Kuzel's
comment).  I provided something according our last discussion and wait for your
feedback. 

Even if its not public API  we should  polish this API including javadoc, naming
of its classes and methods before merging into trunk. 

If you won't need for example those two methods: deleteSucces, deleteFailure
because FileChangeListener.fileDeleted is enough for you because you listen on
FileObject anyway - then I delete them or you can easily do it yourself.    

Can I delete the FileObject myself in beforeDelete()? - NO. 
If I do not wish to provide annotations, can I still be an interceptor? - if its
your use case then I'll do it as you want. I don't care about it - its up to
you. As I said - no public API. For me is important - ensure backward compatible
behaviour & performance.

Missing project API blocks integrating checkout wizard with projects (issue #58489).

/cvs/openide/masterfs/src/org/netbeans/modules/masterfs/MasterFileObject.java,v
 new revision: 1.44; previous revision: 1.43

/cvs/openide/masterfs/src/org/netbeans/modules/masterfs/MasterFileSystem.java,v
 new revision: 1.19; previous revision: 1.18

/cvs/openide/masterfs/src/org/netbeans/modules/masterfs/providers/AnnotationProvider.java,v
 new revision: 1.2; previous revision: 1.1

/cvs/openide/masterfs/src/org/netbeans/modules/masterfs/providers/InterceptionListener.java,v
 new revision: 1.2; previous revision: 1.1

Merged into trunk as it was - should be polished that's why I let this issue
still  open.

Reassigning to new module owner jskrivanek.

Closing. Anyone welcome to file a separate issue with additional request for enhancement.