myk wrote:It should not affect them at all. It would be the equivalent of doing an 'svn up' command before running 'mvn package'. For people who are just syncing svn to stay bleeding edge, it would actually be less work compared to now, since they would no longer need to do explicit svn updates. It would just be a potential annoyance if (1) local changes are unmerged and conflict with something that was just checked in by someone else or (2) you're doing revision bisecting trying to find the first bad commit while tracking down a bug. We could solve (2) by introducing an optional commandline parameter (e.g. 'mvn -DdoUpdate=false package'), but I do fear that (1) might cause some angst. Those devs who do not want svn to be automatically updated could create a properties file and set doUpdate to false in there, and we could read that from the pom, but of course if that were to become popular to do, why have the autoupdate at all. We could try it and see how it goes -- it might not become a problem at all. Let me test it out locally for a bit to see if it causes issues.
edit: not sure if this is an option, but this particular kind of problem doesn't exist with git.
The auto updating might be more of a problem for other people than myself. Then again, people are creatures of habit and it is not easy to get us to change even if it is in our best interests.
Oh, we tried git for a couple of months and then decided to go back to SVN.
We were on googlecode SVN for a couple of years and went to git in an effort to avoid the sleeping giant. Git turned out to be more complicated for those people who were into the project more as a hobby and did not have much tech background.
We moved to the current SVN in the hopes that people like myself would be able to stay with the project.
Posted: 21 Feb 2013, 17:43