On Mon, Nov 28, 2011 at 5:04 PM, Branko Čibej <br...@xbc.nu> wrote: > On 22.11.2011 14:57, C. Michael Pilato wrote: >> On 11/22/2011 02:26 AM, Daniel Shahaf wrote: >>> On Tuesday, November 22, 2011 12:23 AM, "Johan Corveleyn" >>> <jcor...@gmail.com> wrote: >>>> Hi all, >>>> >>>> I'm wondering if it would be feasible to (make it possible to) >>>> alter/add copyfrom information in an SVN repository. And if so, would >>>> this be a desirable feature? >>> It's not feasible for FSFS without a format bump and a new layer of >>> code. I believe trivial for BDB though. >> I'm not convinced that it's "trivial". > > What happens to mergeinfo and merging in general if you add copyfrom > info to a historical revision?
I'm not completely sure. That's one of the things I'm trying to find out from discussing on this list :-). But you're right, it's one of the issues I was wondering about. Is this a form of history manipulation that has an acceptable amount of impact on the rest of history? Can existing working copies remain? ... Sure, the semantics of such a merge changes slightly, but maybe that's okay, and even expected? Thinking of merge and copyfrom, there is also still the open issue of merge not transposing copyfrom information into equivalent copyfrom in the merge-target [1]. Say rX is (missing copyfrom): D trunk/file.txt A trunk/moved.txt Merging rX to branch, this gives the following result: D branch/file.txt A branch/moved.txt (copied from trunk/moved.txt@rX) So if rX were to be fixed with copyfrom, that would not directly impact the merge, but would help when following 'svn log -g'. Okay, rX when I merged it is not the same as rX after the history-fix, but is that a problem? -- Johan [1] http://subversion.tigris.org/issues/show_bug.cgi?id=2685 - Move + Merge => lose modifications
