[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: Mark Phippard <markphip_at_gmail.com>
Date: Thu, 4 Nov 2010 07:30:33 -0400

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.

Mark Phippard
Received on 2010-11-04 12:31:13 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.