Community
Participate
Working Groups
From when I updated to 1.7 compatible connectors, both with Subversive 0.7 and 1.0, I am seeing this strange behaviour. Sometimes it happens that ignored files are suddenly marked as outgoing additions. Trying to issue "refresh" at various folder levels does not help. I must restart Eclipse in order to fix the problem. This usually happens right after a commit operation. I couldn't determine any rationale for this in order to provide some steps to repro. Please note that my project physical structure is the one described at Bug 392719. This never happened with 1.6 compatible connectors. I've always used the SVNKit connector, so I don't know if this is a problem of Subversive or of the new SVNKit connector.
*** Bug 393502 has been marked as a duplicate of this bug. ***
*** Bug 320128 has been marked as a duplicate of this bug. ***
Update: the problem seems to happen randomly when I do a "refresh" on a folder containing ignored resources, not necessarily right after commit.
*** Bug 414789 has been marked as a duplicate of this bug. ***
I and others in my organization are regularly observing this exact same issue with Subclipse, including 1.8.22 and SVNKit 1.7.11. (Eclipse 4.3.0 / I20130605-2000.) So unless both team providers happen to have the same bug, it seems that this might either be an issue with SVNKit, or possibly, the parent abstract team provider that Subversive, Subclipse, and others would all inherit from? The one work-around I've found (short of restarting Eclipse) is to right-click on the problem artifacts from the "Synchronize" view, then click "Remove from View". However, even this is only temporary - and minutes or hours later, the problem will reappear.
I already tried to make a search on SVNKit issue tracker for this problem, but couldn't find anything. I haven't use the JavaHL connector enough to determine whether it's a SVNKit or Team Provider API fault. Fact is that this happens frequently. Alexander, do you have any clue/suspect/idea?
(In reply to Mauro Molinari from comment #6) > Alexander, do you have any clue/suspect/idea? I don't think it is related to SVN Kit, more likely it is Subversive's problem. But unfortunately I could not reproduce the problem yet. For now I think it could be related to the project structure (something like with this project structure it happens, but with that - it doesn't).
In my case.. you know what's my project structure! :-D I have a root project and some nested projects. The problem usually occurs on nested projects, but I can't state for sure if it also happens on the root project or not... Regarding the single project structure, I usually have the root of the project containing a folder named "build" which is ignored, but sometimes Subversive wants to commit files in it anyway. Using TortoiseSVN on the same folder structures doesn't ever show this problem.
(In reply to Mauro Molinari from comment #8) > Regarding the single project structure, I usually have the root of the > project containing a folder named "build" which is ignored, but sometimes > Subversive wants to commit files in it anyway. So, it is ignored through svn:ignore, not automatically (like the content of output folder for Java classes with "JDT ignore extension" installed), am I correct?
You are correct: it is ignored through svn:ignore. The "JDT ignore extension" is excluding the "classes" folder, instead. I never saw problems on that folder. So, the problem is that Subversive does not honour the svn:ignore property sometimes (I never understood what is causing this and when).
I confirm this problem occurs also with the JavaHL connector: Subversive Team Provider 1.1.1.I20130816-1700 JavaHL 1.7.9 Win64 Binaries 3.0.2.I20130808-1700 It usually happens after a refresh action issued on a folder containing ignored subfolders. But not always...
Created attachment 239348 [details] Screenshot describing the problem Another typical case in which this problem happens is just after a successful commit. It just happened once again and I took a screenshot. You can see some interesting things, let's focus on project named "CARDINIS_APPLET_OLD": - the Project Explorer does not show any outgoing change - the Synchronize View shows as added all files in build folder - however, as you can see in the Properties view (and in the opened "Edit Property" dialog), the svn:ignore property is set on CARDINIS_APPLET_OLD folder and it includes the build folder The CARDINIS_APPLET_OLD project is physically nested inside another project (not shown in the screenshot). This root project has a resource filter that hides CARDINIS_APPLET_OLD from itself. Alexander, do you have any idea? It's very annoying and one of the reasons for which my co-workers are migrating to Subclipse :-(
(In reply to Mauro Molinari from comment #12) I understand how much annoying it is, but reviewing code hasn't helped at all and I can't reproduce the problem. I even tried it with JDT ignore extension off and still got nothing. :( There is still a chance it could be related to the nested projects case and that I can't detect it since my test projects for the case are way too small or somewhat different from what they should be like.
(In reply to Mauro Molinari from comment #12) In the end reviewing code has brought some results. While working on bug 427184 and bug 427183, I've found there is a chance that the code will load unversioned resources information wrongly. So, it may cause behaviour described in this bug. I'm not to sure it is the reason, since I wasn't able to reproduce the situation in the end, but nevertheless I've made some changes in order to avoid the problem. I think I'll publish a new build next week and I hope it'll help to solve the problem. P.S. Anyway, I won't close the report as fixed for awhile since I've no way to ensure if the bug is actually fixed or not.
Hi Alexander, thank you, I will try the new Early Access build as soon as it is available and will try to use it to see if this problem shows up again. By the way bug #427184 sounds like it could bring sensitive performance benefits on large projects, so well done!
(In reply to Mauro Molinari from comment #15) Hello! It is available now.
Downloaded and installed. I'll let you know. I don't know how long it will take (it occurs "randomly").
Alexander, I just realized that I have strange issues with the update of Subversive using the update sites. These are the update sites I have configured in my Eclipse which could be related to Subversive: http://download.eclipse.org/releases/kepler http://download.eclipse.org/technology/subversive/2.0/update-site/ http://community.polarion.com/projects/subversive/download/eclipse/3.0/kepler-site/ http://community.polarion.com/projects/subversive/download/eclipse/3.0/update-site/ http://community.polarion.com/projects/subversive/download/integrations/kepler-site/ They are all enabled. However, after doing a "Check for updates", the latest version of Subversive I was proposed to install was: Subversive SVN Team Provider 1.1.0.I20130527 which seems quite old to me. If I do a Help | Install new software... instead, and I choose "-- All available sites --", then I uncheck "Show only the latest versions...", I see that there would also be the following newer versions available: - Subversive SVN Team Provider 1.1.1.I20130816 (under "Collaboration" group - I suspect this comes from the Kepler update site) - Subversive SVN Team Provider 2.0.0.I20131101 (under "Subversive SVN Team Provider" - I suspect this comes from the Early Access update site) So, my questions are: - why isn't Subversive upgrading to 1.1.1 and 2.0.0 when I do a "check for updates"? - the version in the early access site has a timestamp of 20131101, which however seems quite old to me... is this supposed to (hopefully) contain the fix for this bug report?
If I try to select version 2.0.0 in the "Install new software", the "Install Remediation Page" of p2 comes out and suggests to install this new version, but to uninstall the following: JavaHL 1.7.9 Win64 Binaries Native JavaHL 1.7 Implementation Subversive Revision Graph Subversive SVN Connectors Subversive SVN Integration for the Mylyn Project Subversive SVN JDT Ignore Extensions SVNKit 1.7.11 Implementation So, I suspect there's an issue with the declared dependencies of all of these bundles that are preventing versions 2.0.0 of the Subversive SVN Team Provider to be installed. This explains why a "Check for updates" does not propose version 2.0.0 to be installed. Another strange thing, though, is that if I select version 1.1.1, instead, there are no errors reported by the p2 installer, so I can't understand why it is not proposed automatically when I do a "Check for updates".
Sorry for spamming, but looking at http://www.eclipse.org/subversive/latest-releases.php I understood I should install version 1.1.3 from the stable update site rather than version 2.0.0 from the Early Access update site (version 1.1.3 is timestamped at 20140206, so I think this is the version I need to install). I also discovered why the "Check for updates" didn't suggest me any of the 1.1.x versions: it was due to another update site (for another plugin) which was causing weird behaviours (I solved by disabling this problematic update site). So I'm now correctly installing Subversive 1.1.3 at last, I'll let you know.
(In reply to Mauro Molinari from comment #20) I'm sorry for not answering earlier, but just to be clear about the 2.0 version: Subversive 2.0 is not released yet, it is just an "early access" build for those who need to prepare for its API changes.
I still get the same problem even with the new 1.1.3 release. I have nested projects as well. One simple case that might help in pinpointing the problem is: if all my projects except for let's say multi_A are closed then synchronize does not show any outgoing changes. This is after recursively adding target, bin, and gen to svn:ignore Then I open a second project multi-B and run team-synchronize on it. Now I get 422 outgoing changes. All in target/checkout/ folder of project multi_A I have all team models active at the moment.
Then when I press F5 on one of the target/checkout/subfolder folders in the synchronize view I get SVN Errors. Hundreds. they all look like: Synchronize operation failed. svn: E160013: URL 'svn+ssh://company.com/data/svn/foo/trunk/target/checkout/nfcb-test/test-emv/target/classes/package/name/BootstrapModule$$ModuleAdapter$ProvideNfcDeviceComManagerProvidesAdapter.class' non-existent in that revision which might be completely unrelated to the topic at hand. I don't know.
(In reply to Raphael Ackermann from comment #22) I tried it with this structure: Root_Project bin/(something around 5000 files and folders) gen/(something around few hundreds files an folders) target/(something around 17000 files and folders) inner_project_1/(a few versioned files and folders) inner_project_2/(a few versioned files and folders) bin, target, and gen were added to svn:ignore by their name, then Root_Project properties were committed. All team models were enabled. After trying closing/opening projects, updating and synchronizing them I've got no result. So, is there possibly a difference from your setup that I was unable to reproduce properly?
(In reply to Alexander Gurov from comment #24) > So, is there possibly a difference from your setup that I was unable to > reproduce properly? Unfortunately, I got a new job and now I haven't the opportunity to do tests on my old environment with nested project any more. However, given your workspace, I would suggest some actions to try to reproduce: - commit some files - after that, refresh your project (both the root and the nested ones) - do the above steps in combination with an update (maybe from outside of Eclipse) of the contents of target and/or gen folders In your workspace, I would expect gen and/or target folders to show this problem (not bin, which is excluded through JDT extensions). I don't think it's relevant, however I always put my Synchronize View in "Change sets" mode.
Created attachment 243303 [details] Another screenshot, non-nested projects Unfortunately, today this problem happened to me even in a workspace without nested projects! :-((( The attached screenshot shows this: the "Add to version control" option is enabled, while "Add to svn:ignore" is disabled... because that folder is actually ignored!! Issuing Refresh on the containing project does not help. The workspace layout is flat: a checkout folder (ex.: c:\checkout\allprojects) contains 5 folders + the .svn folder. The workspace folder (ex.: c:\workspace\allprojects) contains 5 projects linked to c:\checkout\allprojects. The linking has been done by using the "Import Existing Project Into Workspace" wizard, by selecting c:\checkout\allprojects as the root folder, by checking all the 5 projects and keeping "Copy projects into workspace" unchecked. The fact that the .svn folder is outside the workspace and outside any project folder is common to my previous environment, which had nested projects. Maybe this could make the difference? Using: Subversive Team Provider 1.1.3.I20140206-1700 Subversive SVN Connectors 3.0.5.I20140122-1700 JavaHL 1.8.5 Win64 Binaries 3.0.5.I20140122-1700
Hi Alexander, Subversive 2.0 release notes at http://www.eclipse.org/subversive/changelogs/releasenotes.txt mention this bug as fixed. Did you do anything new then for this?
(In reply to Mauro Molinari from comment #27) > Hi Alexander, > Subversive 2.0 release notes at > http://www.eclipse.org/subversive/changelogs/releasenotes.txt mention this > bug as fixed. Did you do anything new then for this? Hi, I did some changes in order to fix the issue, but I can't check if it is actually fixed or not. So, the release notes says some work was done, but the issue is not closed as for now, since it is possible the issue still exists. :(
Ok, thank you. I will let you know if I still see the issue. I've just upgraded to Luna and Subversive 2.0 :-)
*** Bug 449073 has been marked as a duplicate of this bug. ***
There were 2 more related issues in code.
Thank you Alexander. I didn't give you any new feedback because, meanwhile, I saw this problem happening very rarely, probably also because I changed the type and structure of projects I'm working on. Anyway, it's always nice to see fixes and improvements in Subversive! :-)
(In reply to Mauro Molinari from comment #32) > I didn't give you any new feedback because, meanwhile, > I saw this problem happening very rarely, probably also because I changed > the type and structure of projects I'm working on. Thank you for informing me. Since there were no clear steps to reproduce there is a slight possibility that the bug still exists, so that's why I'll still monitor the issue. If it happen to appear at a later time, please feel free to notify me.
Forgot to mention. I expect the relevant fixes to make their way into 3.0.5 and 4.0.0 builds.
Looks like this introduced a regression (at least on my personal git repo which is a partial mirror of the trunk). A deleted file is not shown anymore in the synchronize view. git-svn-id: https://dev.eclipse.org/svnroot/technology/org.eclipse.subversive/trunk@21554 diff --git a/org.eclipse.team.svn.core/src/org/eclipse/team/svn/core/utility/FileUtility.java b/org.eclipse.team.svn.core/src/org/eclipse/team/svn/core/utility/FileUtility.java index a804f30..a7d93d6 100644 --- a/org.eclipse.team.svn.core/src/org/eclipse/team/svn/core/utility/FileUtility.java +++ b/org.eclipse.team.svn.core/src/org/eclipse/team/svn/core/utility/FileUtility.java @@ -255,10 +255,12 @@ } /* - * If the resource is a derived, team private or linked resource, it is ignored + * If the resource is inaccessible, the workspace root, a team private or a linked one, it should not be managed by SVN plug-in */ - public static boolean isIgnored(IResource resource) { - return resource.isDerived() || resource.isTeamPrivateMember() || FileUtility.isLinked(resource); + public static boolean isNotSupervised(IResource resource) { + return + resource instanceof IWorkspaceRoot || !resource.isAccessible() || + resource.isTeamPrivateMember() || FileUtility.isLinked(resource); } Here the comment and implementation (!resource.isAccessible()) seem to be wrong: this excludes all deleted files from SVN version control. As a result, I don't see any deleted files in the synchronize view. Removing !resource.isAccessible() condition or replacing it with resource.isDerived() fixes the regression.
(In reply to Andrey Loskutov from comment #35) > Looks like this introduced a regression I've created separated bug 491078 to track the fix.
