3

Yesterday, I asked a question about why directories can appear to Subclipse to contain uncommitted changes when they actually don't. The answer was that setting svn:ignore status on the pseudo-directory . counted as a modification, but Subclipse didn't show anything because it doesn't deal with ..

Knowing the cause is nice, but the issue isn't fully resolved. Is it safe to commit the addition of ignore status to the . pseudo-directory? I do not want the actual directory to be ignored by SVN; I only want to make the uncommitted change decorator go away. (No, I haven't tried just doing it. I wouldn't know how to cleanly revert the change if it turned out to be problematic.)

EDIT:
As pointed out in Tim's answer, blaming the modification of . is misleading. . was only marked modified because one of the subdirectories was set to svn:ignore; that's the real change and root cause.

Community
  • 1
  • 1
Pops
  • 30,199
  • 37
  • 136
  • 151
  • Also, is there a proper term for what I'm calling a pseudo-directory? It's hard to search for anything involving stop words/special characters. – Pops Feb 23 '11 at 20:34
  • I would consider . to be a reference to the current directory. Directory reference, directory pointer, symbolic link may all be considered applicable, although plenty would disagree with each of them for various reasons. I personally would consider pseudo-directory acceptable because it accurately conveys the concept, so it fulfills its purpose. – corsiKa Feb 23 '11 at 20:39

1 Answers1

4

Based on the output of svn diff that you received, you were actually setting svn:ignore for the resource target. This property information is saved on the parent versioned resource (in this case the project root .) so that it can be committed to the repository independent of your local ignore settings.

Given this, is it safe to commit the property change? It depends on what impact you want to make. The documentation makes this note about the svn:ignore property:

The svn:ignore property is a good way to tell Subversion to ignore files that are likely to be present in every user's working copy of that directory, such as compiler output...

So, by committing this change, you'd effective ignore the target resource for anyone who pulled the project from the repository (provided it's currently unversioned). It's possible that this may not be the policy at your workplace though, so you may want to avoid this. To remove the property, you can take one of the following actions:

  • Run svn propdel svn:ignore . from the command line
  • In Eclipse (with Subclipse), right-click the project folder, go to Team -> Show Properties, select the svn:ignore property entry, right-click, and click Delete Property

This should get rid of the modification notice on the root directory. With respect to your previous question, the problem would have been more apparent had it not been for the fact that property changes show as normal outgoing changes in the Synchronization view. If you were to bring up the Commit dialog, you should actually see the distinct Property Change decorator.

Unfortunately, this leaves you with the target resource unignored. To fix this in Eclipse, you can add target to the list of ignored resources. To get to this option, go to Window -> Preferences -> Team -> Ignored Resources. You can then add "target" to the list of ignore patterns. If you wish to apply the ignore pattern to Subversion globally, you can modify the global-ignores setting of your Subversion configuration file.

The problem with this approach is that it ignores the target resource for all projects in the Eclipse workspace, or all Subversion actions across the system (depending on your ignore method of choice). At the moment, I can't think of a way to reverse this on a case-by-case basis.

Community
  • 1
  • 1
Tim Stone
  • 19,119
  • 6
  • 56
  • 66
  • Great answer, which is unsurprising since we were talking about it in chat. One minor quibble: removing the ignore proprety sets the `target` folder to the not-yet-under-version-control state, which doesn't remove the uncommitted changes (AKA dirty) decorator from the parent folder's icon. – Pops Feb 23 '11 at 22:11
  • @LordTorgamus Right, the `target` folder will be set to versioning-pending until it's added to the list of ignored resources. Once it's ignored locally, the `?` should disappear and the parent folder should revert to the up-to-date state (though with Eclipse it might take a refresh). – Tim Stone Feb 23 '11 at 22:14