Working with a combination of Springsource Tool Suite, Subversion and the Subversive plugin, one of the things that really bugs me is the issues I keep on getting as a result of messed up source control of the “target” directory.
This directory typically holds all of the compiled classes as well as a stacktrace log and a few other things. In general it never really needs to be put under version control.
One of the things I keep forgetting to do, that frustrates the hell out of me is to set the svn:ignore property as soon as the repository is created. You see, without this property set, the target directory is submitted (added) to version control and once it’s in there, there’s no (easy) way of getting it out, as the Subversion documentation says:
“…Once an object is under Subversion’s control, the ignore pattern mechanisms no longer apply to it…”
And even if you set the “svn:ignore” property on the directory, it still probably won’t work properly. Instead committing all of the class files and so forth that you couldn’t give two craps about.
All this is well and good, but could be written off as a minor problem, if it weren’t for the fact that when you try to revert your changes, Subversion could very well pick up “conflicts” between the class files, and in fact can put you in a situation where you’re struggling to get a functional checkout of the repository, simply because of the “target” directory.
The problem seems to be with the nature of the files being stored in the directory being constantly deleted/recreated etc… which seems to screw up Subversion. At the moment there doesn’t seem to be a fix for the issue i.e. every time I see the problem, I just manually manage the conflicting files.