Bugzilla – Full Text Bug Listing
| Summary: | Bookmarks Delete Themselves | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Jeremy Walker <eclipsebugs.machineghost> |
| Component: | Resources | Assignee: | Platform-Resources-Inbox <platform-resources-inbox> |
| Status: | CLOSED DUPLICATE | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | pwebster, remy.suen, Szymon.Brandys |
| Version: | 3.7 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
|
Description
Jeremy Walker
(In reply to comment #0) > 1. Add a bookmark on a file > 2. Get rid of that file (there might be more to this step; not sure what else > Git might be doing on a "git checkout" that could matter ...) > 3. Get that file back > 4. Cry over missing bookmarks that you spent minutes making ;-) I presume the same occurs as if you had deleted the file? > I presume the same occurs as if you had deleted the file?
Correct. I just tested that case, and can now confirm that these (simpler) instructions also reproduce the issue:
1. Add a bookmark on someFile
2. rm someFile
3. cry (ie. go look in Eclipse, and the bookmark should be gone)
Bookmarks are stored with the resources. When they are deleted, the bookmarks are also deleted. (In reply to comment #2) > > I presume the same occurs as if you had deleted the file? > > Correct. I just tested that case, and can now confirm that these (simpler) > instructions also reproduce the issue: > > 1. Add a bookmark on someFile > 2. rm someFile > 3. cry (ie. go look in Eclipse, and the bookmark should be gone) This is by design. Bookmarks are just type of markers which are deleted along with the resource. (In reply to comment #0) > Build Identifier: 20110916-0149 > > My bookmarks keep deleting themselves. I believe it's happening whenever I > change branches in my version control system (Git). I *think* maybe Eclipse is This is an interesting case. It's not just about bookmarks, but also breakpoints and tasks I think. Now with Git, people more often switch between branches. I would expect to keep the list of markers per each branch. So when I switch between two branches (i.e. tasks, bugs) I would get the correct set of markers attached to the branch. I think it should be addressed by EGit. When someone switches branches, EGit should store markers for the branch somewhere and then when you go back to this branch the markers are re-applied. I guess it may require some new API in core.resources, but I would wait for EGit comment. >>I think it should be addressed by EGit. When someone switches branches, EGit
>>should store markers for the branch somewhere
This is probably too much to hope for, but ... well, I don't use EGit. No one I know uses EGit (admittedly, that's a small sample size: I know like six developers who use Eclipse and Git). This is nothing against the great work I'm sure the EGit team has done; we're all just comfortable with using Git at the command line. Plus, there are many things a Git plug-in simply can't do (if you don't believe me, run "git help", then tell me if EGit can do everything on that list ;) ). So even if EGit could meet some of our needs, we'd still wind up at the command line half the time anyway.
So, it would be IDEAL if markers could just be stored in a more general place, so that Git users could benefit from all the wonderful IDE, debugging, syntax coloring, etc. features of Eclipse, without being forced to make Eclipse their new OS (ie. being forced to use a plug-in for everything they want to do).
... but if that's not possible, I guess an EGit fix would help someone (just not me).
Just a thought: is there any way that Eclipse could continue storing markers by file, as it currently does, but then store them in some "magic" place if the file gets deleted (rather than removing them outright)? That way if a file with the same name appears Eclipse could check the "magic" place, and if it finds any markers for the (no longer deleted) file, it could re-attach them? It seems to me that such a solution would benefit users like myself, while not requiring a whole re-architecting of the marker system. (In reply to comment #6) > Just a thought: is there any way that Eclipse could continue storing markers by > file, as it currently does, but then store them in some "magic" place if the > file gets deleted (rather than removing them outright)? That way if a file > with the same name appears Eclipse could check the "magic" place, and if it > finds any markers for the (no longer deleted) file, it could re-attach them? > > It seems to me that such a solution would benefit users like myself, while not > requiring a whole re-architecting of the marker system. You can't choose where to store your markers. The quickest solution would be to export all your markers and then try to re-apply them when you switch your branches, repositories etc. However AFAIK there is no all-markers export/import mechanism. >>You can't choose where to store your markers
Just to clarify, do you mean that *users* can't choose where to store markers, or that the *Eclipse architecture* can't choose? If it's the former, that's ok; my suggestion was to have Eclipse, behind the scenes, store markers that it was about to delete. Essentially it would be like a sort of export, except that it would only export the markers being deleted. Then, when Eclipse detects a "new" file, it would simply check the export to see if it contains markers that reference said file, and if so it would import them.
This "deleted markers storage area" doesn't need to be anything fancy, I'd think. After all, the markers themselves are basically just a set of [name, file name, line number] right? (I realize they're probably a bit more complex than that, but hopefully not much.) If so, a simple properties file, CSV file, YAML file, etc. could hold them, and I wouldn't *imagine* that'd be hard to implement.
But, if you're saying that there's just no way for Eclipse to store deleted markers somewhere, then that pretty much kills my idea. Even in that case though, I still think it'd be nice if Eclipse users who also use Git/Mercurial/any other modern source control system, but who don't use a plug-in, could still use bookmarks (or any other marker-related feature). Maybe that's too much of a niche to be worth anyone's time, but *shrug* it doesn't seem like a small group to me.
In theory you can get the markers using org.eclipse.core.resources.IResource.findMarkers(String, boolean, int) IMarker[] allMarkers = ResourcePlugin .getWorkspace().getRoot() .findMarkers(null, false, IResource.DEPTH_INFINITE); This is probably not performant, especially in a large workspace. The other option is to use org.eclipse.core.resources.IResource.accept(IResourceVisitor) on the workspace root which walks the resource tree in a visitor pattern (and you can ask for all markers for the current resource). If you add a org.eclipse.core.resources.IWorkspace.addResourceChangeListener(IResourceChangeListener) to the workspace you could try and only save markers for IResources that were deleted, and look in your deleted pool when IResources are created (probably the least resource intensive option). PW (In reply to comment #8) > >>You can't choose where to store your markers > Just to clarify, do you mean that *users* can't choose where to store markers, > or that the *Eclipse architecture* can't choose? When you work with resources and markers, markers are always stored in the same place in your workspace. Neither user can't change it nor Eclipse has API to change the location. In comment 7 I thought that maybe Eclipse should have all-markers export/import mechanism. Then end-users could just export their markers to some location, do some Git operations or whatever they want with their projects and then try to import markers back. You can always write a plug-in using the code that Paul suggested and it would work for you. >>You can always write a plug-in using the code that Paul suggested and it
>> would work for you.
Well, I was just hoping that Eclipse, bookmarks, and Git could actually work together. It seems they can't, which is unfortunate, but I unfortunately don't have the time/energy to build a plug-in to fix it.
I don't think the idea of hanging onto the markers of deleted files in case they come back is practical. Maybe the user never switches to that branch again. When do we clean them up? What if they switch back to that branch much later - what are the odds the bookmark positions will line up in the correct place. It also doesn't support cases like sharing bookmarks across multiple workspace or machines. The general problem of maintaining synchronization of metadata and content stored in a separate repository is very hard to get right. I think in practice the only form of marker persistence that will be successful is a system where markers are stored in the workspace content area alongside the files. For example, a system like the TODO comments in java files where the information is embedded in the content. Or, a separate file alongside the content containing the pointers you care about (eg, bookmarks.html). I think this is the only way to support all the sharing scenarios and maintain metadata consistency. I don't see us ever providing general framework support to do this. *** This bug has been marked as a duplicate of bug 26809 *** >> When do we clean them up? I'd argue never. After all, even the most aggressive bookmark user is only going to rack up a few thousand marks (if that), which has got to use less than a meg of space; hardly seems worth worrying about. >>What if they switch back to that branch much later - what are the odds the >> bookmark positions will line up in the correct place. Well, but consider the current situation vs. that scenario. Right now you completely lose your bookmarks. After such a fix, you'd at least have your bookmarks, they might just be off a bit. I think it's safe to say that stale bookmarks > deleted bookmarks. >>It also doesn't support cases like ... True ... but it'd solve this case :) >> For example, a system like the TODO comments in java files where the >> information is embedded in the content. I can't speak for anyone else, but if I could do something like: // MARK: MyClass Definition or: // @mark MyClass Definition and have that show up inside Eclipse's bookmarks, that would be awesome, and would certainly solve my problem. >>I don't see us ever providing general framework support to do this. Dang. (In reply to comment #13) > >> For example, a system like the TODO comments in java files where the > >> information is embedded in the content. > I can't speak for anyone else, but if I could do something like: > > // MARK: MyClass Definition > or: > // @mark MyClass Definition > > and have that show up inside Eclipse's bookmarks, that would be awesome, and > would certainly solve my problem. I don't see the difference between this and the markers that show up in the 'Tasks' view. Unless your aim is 100% flexibility since bookmarks can be inserted at any line number whereas task markers have to be in a comment. >>I don't see the difference between this and the markers that show up in the
>>'Tasks' view.
Imagine you're a non-Eclipse user, looking at code generated by an Eclipse user. If you see:
// TODO: MyClass
...
// TODO: MyClass.doStuff
...
You're going to think "this guy is an idiot who doesn't understand the meaning of the phrase 'to do'". Conversely, if you see:
// MARK: MyClass
...
// MARK: MyClass.doStuff
...
at worst you'll think "this guy over-uses comments".
The two would do essentially the same thing in Eclipse, but outside of Eclipse "TODO" has its own separate meaning. "MARK" (or better yet, something like "// *** MyClass") just looks like a normal code comment.
(In reply to comment #15) > Imagine you're a non-Eclipse user, looking at code generated by an Eclipse > user. If you see: > > // TODO: MyClass > ... > // TODO: MyClass.doStuff > ... > > You're going to think "this guy is an idiot who doesn't understand the meaning > of the phrase 'to do'". Task tags are configurable. There is no requirement for tasks to be prefixed with the string "TODO". However, based on comment 13 I suppose the issue here is that you want these markers to show up in the 'Bookmarks' view instead of the 'Tasks' view. I suggest you open an enhancement request for JDT then. |