On Fri, 2010-10-01 at 09:16 -0400, Paul Burba wrote: > 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.
It should be (C): a dry-run should be as close as possible to the "real" behaviour. I can't see any benefit in making a dry-run merge behave differently from a non-dry-run merge in this respect. > 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. Agreed. > >> 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. I have no opinion on that. > > 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 - Julian
