Ouch, it gets worse...
On Mon, 10 Jul 2006, Daniel Rall wrote:
> 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).
2a. Make an additional (manual) change to the file.
> 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).
Your (manual) local change is also lost! This is particularly ungood,
since that change has likely never been under version control...
While our editor API has fields for the copyfrom information, our WC
editor does not use them. The add_file and add_directory APIs have
TODO comments to add handling for the copyfrom info. However, Garrett
tells me that our FS reporter is not even retrieving the copyfrom info
to send back to the client in the first place! Apparently Garrett had
to add retreival of that for ra_replay (see use of "struct copy_info"
in libsvn_repos/replay.c). While ra_replay has the advantage that
it's only dealing with a single revision at a time, we may only need
to care about the copyfrom info for the youngest (highest) revision in
a merge range.
This bug applies to 1.4 and trunk, and likely applies to much much
older versions of Subversion as well.
- application/pgp-signature attachment: stored
Received on Tue Jul 11 00:49:46 2006