On Fri, Oct 1, 2010 at 7:25 AM, Julian Foad <julian.f...@wandisco.com> wrote: > Stefan Sperling wrote: >> I'd like to propose that we disallow merges into mixed-revision working >> copies by default for 1.7, and only allow such merges if a special command >> line option has been passed.
What will the behavior be during --dry-run merges? A) No change B) Warn that your target is mixed-rev, but proceed as we always did C) Fail unless the new option is used. What about --record-only merges? I think here it makes sense to mirror whatever behavior we decide upon for a "real" merge-tracking aware merge. >> The reason for this is that merges into mixed-rev WCs can easily create >> conflicts which are tedious to resolve. Even if you know about the problem >> and try to run "svn update" before every merge, it's quite easy to forget >> about running "svn update". >> >> Also, we've been advertising this as best practice for some time. >> Quoting the book on the matter: >> Never merge into working copies with a mixture of working revision >> numbers, or with “switched” subdirectories (as described next in the >> section called “Traversing Branches”). A merge target should be a >> working copy which represents a single location in the repository at a >> single point in time. >> >> Note that while the book recommends not to merge into working copies >> with switched subtrees, I don't intend to enforce this by default. >> >> I've talked about this with Paul on IRC and he had no objections. >> See http://colabti.org/irclogger/irclogger_log/svn-dev?date=2010-09-30#l468 >> for the full discussion. >> >> Below is a work-in-progress diff that starts making this change. >> Tests fail with it. I've only checked the merge tests for now. >> >> Before continuing with this, fixing up tests, bumping APIs, and eventually >> adding the command line option that allows merges into mixed-rev WCs, >> I'd like to ask whether anyone has concerns about this idea. > > The proposal sounds good to me. > > To be more specific about what the proposal is: > > * It does not apply to re-integrate merges. (They always enforce this > anyway?) Right, there should be *no* override on reintegrate's requirement for a uniform rev target. > * It applies to merge-tracking merges. > > * It [applies/does not appy] to non-merge-tracking merges? Stefan and I didn't discuss these last two. I'm inclined to think that this warning should apply only to merge-tracking aware merges. > As for the tests: I think it would be best to keep some or all of the > tests doing merges into a mixed-rev WC as they do now, partly so as not > to lose test coverage of this condition, but more importantly to > preserve the purpose of any regression tests that happen to be testing > for bugs which only showed up in mixed-rev mode. > > In other words, fix most of them by adding the bypass flag rather than > by adding an "svn update" command. Good point, that makes more sense. Paul
