Kepler

I successfully reproduced this. Here is what I tried:

cd build-area
ant update
ant update-ptolemy -Drev=head
vim ../ptolemy/ptolemy/actors/TimedActor.java
(make a minor change)
ant update

I get:
[update-modules] The following classes have been modified in the ptolemy module:
[update-modules] /Users/berkley/project/kepler/ptolemy/ptolemy/actor/TimedActor.java
[update-modules] WARNING: the ptolemy module cannot be updated because of modifications.

Looking into this.

This is not a bug, this is a feature.

The problem that this feature solves is that when you update and there is a conflict, the build freezes entirely with no feedback or error messages.

The major source of conflicts is local modifications. Of course, local modifications are a superset of conflicts. That is, sometimes there is no conflict even though there is a local modification. However, reproducing the analysis that SVN undergoes to detect conflicts is not feasible, at least in the short-term. Therefore, detecting modifications is an imperfect proxy.

Basically, what this says is that if you have local modifications, you have to either check those in or update manually for that module that you are working on and making local modifications to.

Remember, that "ant update" is a convenience method for updating a bunch of modules at once, most of which you will not be working on, and thus not modifying locally. If you are making local modifications and want to update that module, either use "svn update" or check in your code before using "ant update."

The only disadvantage here is that assuming that all modifications might be conflicts is over-inclusive. In fact, most modifications can be merged automatically by SVN and are not conflicts that need to be manually resolved. However, the need to use "ant update" which is merely a convenience method that calls "svn update" on all the modules in modules.txt is not compelling for modules you are actively modifying locally. The need for using "ant update" instead of "svn update" for modified modules is very weak, since it is reasonable to expect developers to manually deal with modules they are actively working with using "svn update" or "svn ci" either before or after running "ant update" to get updates from other developers for modules they are not modifying locally. While there is some cost imposed, since in most cases in fact modifications would never have turned out to be conflicts, that cost is less than having the build hang with no feedback whatsoever when a conflict in fact does occur. The build hanging like that is unacceptable.

I am working on what I hope will be an even better solution. However, in the meantime, this is the fix that is in place to prevent the build from hanging on conflicts. I am closing this bug, since the better solution (if it does in fact turn out to be better) is associated with a different bug.

I think I came up with a simpler fix to the original problem. I changed the SVN command that is run to have the --accept postpone arguments. This way, SVN shows the conflict, but does not stop to wait for user input. I think this is better than stopping people from updating just because of any local modification.

Original Bugzilla ID was 4670