Re: [BUG] Data loss when committing a new file which is a target of multiple merges

Daniel Rall <dlr@collab.net> writes:

> Steps to reproduce:
>
> 1. Merge content into a WC in a manner which creates a new file.
> 2. Before committing, perform a subsequent merge with an adjacent
> merge range (e.g. 2:5, then 5:7).
> 3. Commit the new contents of your WC.
>
>
> Observed behavior:
>
> After step #2, the file in your WC will contain the expected content.
> However, after step #3 the repository will not contain the result of
> the second merge. Instead, it only contains the the result through
> the end of your first merge (e.g. the "copied from" revision will be
> r5, even if the second operation merged in more changes).
>
>
> 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. Without a sleep the commit outputs:

  Adding /tmp/wc/foo.txt

  Committed revision 8.

with a sleep the commit outputs:

  Adding /tmp/wc/foo.txt
  Transmitting file data .
  Committed revision 8.

indicating that the modifications beyond the copyfrom revision have
beed detected and committed.

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.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org