This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | Provide support for VCS lite | ||
---|---|---|---|
Product: | platform | Reporter: | Maros Sandor <msandor> |
Component: | Filesystems | Assignee: | Jiri Skrivanek <jskrivanek> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | jtulach |
Priority: | P1 | ||
Version: | 4.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Bug Depends on: | 59737, 65717, 55639, 57016, 57776, 57900, 58149, 58489, 58530, 58738 | ||
Bug Blocks: | |||
Attachments: | Proposed implementation |
Description
Maros Sandor
2005-01-28 11:04:31 UTC
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. |