On 5/10/2016 22:49, Stewart Gordon wrote:
> This is the problem I am trying to solve. Somebody took a file from
> the repository and, in error, committed a new version of it as a new
> file. Let's call the original file A, and then new one B. Luckily, in
> this instance both A and B are still in the repository at the moment.
> There has been a further change to B since the incident.
> Is there a way to merge the histories of the two files - so that we
> have only one file in there, whose revision history is the history of A
> followed by the history of B - just like what is frequently done by
> admins on Wikipedia to repair cut and paste moves?
I don't think there's a straightforward way to do it, no.
The closest way that I can think of is to delete the new version B, then
copy-with-history A in to replace it (use the repo browser or log to
access the most recent version of A, and make sure SVN lists it as "A+"
or "added" with a history path). Commit that.
Now export the first edition of B elsewhere and then non-SVN-copy it
over the top of A (so SVN sees it as a modification rather than a
replacement) and commit that.
Then use the log to reapply any patches to B made after the initial
commit, committing between each one.
You're still going to end up with a fairly messy repository history, but
the file history should be reasonably continuous at that point (as long
as you have "stop on copy" turned off).
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2016-10-06 00:29:58 CEST