0

I'm accessing a Subversion repository with Subclipse. Some of the folders in the Package Explorer window of MyEclipse show up with the uncommitted changes decorator: uncommited changes decorator on folder

Usually, this means that one or more files in the directory on my machine have local, uncommitted changes. Right now, though, some of the folders appear to contain no files or subfolders with uncommitted changes. (I.e. I don't see any of these: uncommitted changes decorator on file)

This inconsistency is supported by Team Synchronization mode. When I tell Subclipse to synchronize with the repository for one of the affected directories, I see the following screen:

empty list under folder with outgoing decorator

Under normal conditions, there would be a list under the folder of every file that didn't match its repository counterpart. However, as you can see, there's nothing there but a "will be committed" decorator on the folder itself. The "SVN update" and "replace with repository version" commands do nothing, and "compare with repository version" brings up a "no changes found" dialog.

In short, it seems as though some of my directories are getting marked as having uncommitted changes even though they don't. Why is this happening, and how can I resolve it?

(Icon decorator names and descriptions taken in part from this answer to one of my earlier questions.)

Community
  • 1
  • 1
Pops
  • 30,199
  • 37
  • 136
  • 151

2 Answers2

2

When it comes to IDEs and graphical tools, I typically perform a sanity check from the good ole command line client. If you can, open a terminal and run "svn status" to see what Subversion thinks the state of the working copy is. As for valid places where this can happen are versioned properties, out of sync project/filesystem and changes made outside of MyEclipse.

Jeremy Whitlock
  • 3,808
  • 26
  • 16
  • Although this doesn't literally answer the question, it directly led to me figuring out what was going on -- I've posted my findings as a separate answer -- so I'm marking it accepted. (Not like acceptance would do my answer any good anyways.) – Pops Feb 23 '11 at 20:04
  • Seems like it did answer the question. :) The problem was there was a versioned property modification that the two views you were using to see your changes didn't address. Using the cli client got you the information you need. – Jeremy Whitlock Feb 23 '11 at 21:19
0

I followed the advice Jeremy Whitlock gave in his answer and ran svn status on the affected directories. Here are the results, for anyone who has this problem in the future:

14:42 C:\snip\org.oasis_open.docs.ns.cmis> svn status
 M      .

14:43 C:\snip\org.oasis_open.docs.ns.cmis> svn diff

Property changes on: .
___________________________________________________________________
Added: svn:ignore
   + target



14:44 C:\snip\org.oasis_open.docs.ns.cmis>

The other affected directories had the same issue. As for how to resolve it, I'll ask a separate question and then update this answer with a link I've asked a separate question here.

Community
  • 1
  • 1
Pops
  • 30,199
  • 37
  • 136
  • 151