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.
> 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?
Lieven.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 12 12:14:07 2006