On Thu, Nov 4, 2010 at 4:54 AM, Johan Corveleyn <jcorvel_at_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/
Received on 2010-11-04 12:31:13 CET