I've been using Eclipse 3.1 final + svn 1.2.1 + subclipse 0.3.9 for two weeks now and here is what I have found.
All these observations are from use in Eclipse so I guess the niggles are all due to the implementation of subclipse (i hope). My use is not an 'experiment'. I'm working in a team of 4 developers on a substantial project. Syncing occurs more than 10 times a day. 1. SVN ignore files are not respected at all. ever. This is really really annoying as each developer needs to create personalized versions of a few spring xml files (and a hibernate properties file) from templates. Since SVN ignore files are not respected the custom files show up in the synchronize view ever time and have to be manually removed from the view before committing. After a week and a half I found a workaround. Right click on each file, choose properties, and select the 'derived' flag. This setting is workspace dependant and can't be shared via the repository so each developer has to set the flag for each file in their workspace. 2. Quite often if another developer adds or removes a file in the repository, that change *will not* appear in my workbench when I sync up. This results in broken workbench builds. With some detective work you realize that a change didn't show up and you can resync a few times until the change appears. Even then only the package will appear as changed. We are all working the same room so it has become an informal policy to announce verbally such changes so everybody knows their next sync will be problematic. 3. In the subclispe commit dialog you have to explicitly check a box to add a new file. This is exactly the opposite to the cvs experience where one would exclude a file you don't want to commit(add) by removing it from the synch view *before* invoking the commit dialog. Several times I've committed a set of files only to discover that the new files didn't go in because I didn't check the box in the commit dialog. 4. We tried to share Java formatter settings by using the project specific preferences feature in Eclipse. That would allow us to avoid sharing an export separately and then manually importing the settings. Doing the puts a .somethingorother file in the root of the project. This failed spectacularly. The user who shares the .somethingorother file is ok but anybody else who tried to sync up found that jvm crashes causing eclipse to go poof. The cause was JNI problems with the svn native bindings. There are other niggles that I have not experience personally so I can't comment on them. That said, the above problems man that the transition from cvs to svn in Eclipse is not seamless. Hindsight is 20/20 but,knowing what I know now, if I had joined this team before they moved from cvs to svn I would have fought it vigorously. Lastly, the other users in my group are not Eclipse veterans so I have to repeatedly explain that it was not Eclipse that sucked. Rather it is the subclipse plugin implementation that sucks. Geoff -- The Spindle guy. http://spindle.sf.net Get help with Spindle: http://lists.sourceforge.net/mailman/listinfo/spindle-user Announcement Feed: http://www.jroller.com/rss/glongman?catname=/Announcements Feature Updates: http://spindle.sf.net/updates --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
