> I realize people have different opinions here. If the problem is > that so-called "non-conflicting" putbacks should always be taken > without interaction, then 2 makes sense. If the problem is that it > takes too much time, keep in mind that automating it on the client > side (hopefully after user confirmation) will not just make each > cycle easier and quicker, but also reduce the likelihood of > additional conflicts. > > A compromise I would probably find acceptable (since I do see the > annoyance in needing to resync due to obviously unrelated changes) > would be if a changeset could be flagged as conflicting for more than > just having an overlap in their file lists. e.g. > > changes made to different files within the same directory > changes made to common header files and anything else > (sucks for the header file changer) > changes made to makefile includes and makefiles in subdirectories
This sounds like a good middle-ground if feasible. -- meem
