On Wed, 12 Jul 2006, Philip Martin wrote:
> Lieven Govaerts <lgo@mobsol.be> writes:
>
> > Daniel Rall wrote:
> >> On Wed, 12 Jul 2006, Lieven Govaerts wrote:
> >>
> >>> Philip Martin wrote:
> >>>
> >>>> The copyfrom revision is more of a problem. I suppose the ranges A:B
> >>>> and B:C could combine to give A:C, but what about A:B and C:D when
> >>>> B!=C and none of the revisions between B:C affect the target? What if
> >>>> C<B but none of the duplicate revisions affect the target? If we do
> >>>> decide to update the copyfrom data it's not as simple as just updating
> >>>> the revision, the text-base will also need to be updated
> >>>>
> >>> Can you give me a (high-level) scenario and which the user
> >>> experiences this problem?
> >>>
> >>
> >> The "Steps to reproduce" in my original mail describes the specific
> >> steps. Given Philip's findings, in practice this problem would only
> >> be triggered by by a programmatic operation, likely some type of
> >> quickly-executing VC/SCM automation which doesn't do any range
> >> combining when applying merges to a WC (e.g. automated merging for an
> >> integration branch).
> >>
> > While my test passes on my machine (it's probably slow enough) I also
> > see that the copyfrom revision is filled in incorrectly. So my
> > question is, given the fact that the copyfrom revision is filled in
> > incorrectly, what problems can this give for the user? That way I can
> > add such a problem scenario to the test, mark it as XFAIL and commit
> > it to the repository.
>
> It's not really clear that the copyfrom revision is a bug; I don't
> think we have ever claimed that successive merges would update it.
> Your idea of identifying A:B followed by B:C as equivalent to A:C
> works in one particular case but I'm not sure it's a general solution.
> What happens if the copyfrom is the result of an explict user copy
> rather than a merge, is it still acceptable for merge to change the
> copyfrom revision?
Philip, I think I agree with you here -- that the repository had only
the content from the copyfrom rev was only a symptom of the root cause
(client communicating the wrong content to the server because of the
timestamp check mis-behavior).
It was certainly incorrect for the repos to only reflect rA after
-rB:C had also been merged into the WC and committed, but the copyfrom
rev is correct at rA -- the repos should've reflected rC, with
copyfrom rev of rA.
- Dan
- application/pgp-signature attachment: stored
Received on Thu Jul 13 02:56:50 2006