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. -- Thanks Mark Phippard http://markphip.blogspot.com/
