On Fri, 2010-10-01 at 09:16 -0400, Paul Burba wrote:
> On Fri, Oct 1, 2010 at 7:25 AM, Julian Foad <julian.foad_at_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
Received on 2010-10-01 16:59:37 CEST