[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: mergeinfo not inherrited when I thought it should

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Thu, 4 Nov 2010 12:43:23 +0100

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.")


Received on 2010-11-04 12:44:22 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.