On Thu, Nov 4, 2010 at 12:30 PM, Mark Phippard <markp...@gmail.com> wrote: > On Thu, Nov 4, 2010 at 4:54 AM, Johan Corveleyn <jcor...@gmail.com> wrote: >> I think this is known "as-designed" behavior, because of the >> mixed-revision working copy system. Some nodes in your working copy >> may be at different revisions than others (if you commit a change to >> ^/parent/child, child will be at a new working revision, but parent's >> working revision will not be "bumped" automatically, because >> subversion doesn't know if other changes occurred at or below parent >> which would require it to be fully updated). So, even though *you* >> know that it isn't out-of-date semantically, for *svn* it is still >> out-of-date because its "working revision" is not as recent as the >> rest of the working copy. The full update at the top-level brings >> everything at the same working revision. >> >> You should take a look at this chapter from the book, for some general >> understanding of mixed-revision working copies: >> http://svnbook.red-bean.com/nightly/en/svn.basic.in-action.html#svn.basic.in-action.mixedrevs > > One of the plans being tossed around for 1.7 is to make merge throw an > error if the working copy is not at a single revision. So you will > have to run svn up before you can merge or pass a new option to the > merge command that tells it you want to ignore this best practice. > > Last I knew, patches were still being exchanged for this. I do not > think it has been committed to trunk yet.
Yes, this has already been committed to trunk: http://svn.apache.org/viewvc?view=revision&revision=1027970 ("Disallow merges into mixed-revision working copies by default.") Cheers, -- Johan