On Thu, Nov 4, 2010 at 12:30 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> 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.
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
Received on 2010-11-04 12:44:22 CET