On Wed, 12 Jul 2006, Lieven Govaerts wrote:
> Philip Martin wrote:
> >Daniel Rall <dlr@collab.net> writes:
> >
> >
> >>Expected behavior:
> >>
> >>The repository and WC should contain the same data. The "copied from"
> >>info should be updated to account for the end revision of the first
> >>contiguous merge range applied to your WC (across multiple merges).
> >>
> >
> >The file content is a timestamp bug, if I add a sleep command between
> >the two merges then the correct file contents get committed to the
> >repository.
> >
> I see the same thing in my python test for this issue. The data in the
> repository is exactly what we expect, so there's no data loss at all.
Philip's testing showed this difference to be related to the passage
of time between operations. The combination of the Python tests and
your hardware is likely the difference here; enough extra milliseconds
are passing in your testing environment that this bug is not tickled.
> >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 it's obivously not going to occur often, when it does occur,
this is a very severe bug (data loss).
Garrett proposed trying to deal only with the timestamp issue. While
I'm not particularly statisfied with the idea, I suggested the
possibility of using svn_sleep_for_timestamps() as we do for other
operations. Based I Philip's findings, I'm assuming we'd add this at
the end of the 'merge' operation...
This issue is currently the only possible blocker for a 1.4.0 RC2.
- Dan
- application/pgp-signature attachment: stored
Received on Wed Jul 12 19:56:24 2006