Michael Brouwer wrote:
> On 3/10/07, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>
> Let's be really careful here. The fact that a conflict occurs in an
> area of code that is going to be deleted does not mean that the conflict
> can be ignored.
>
> I'm thinking of the situation that in branch B1 a function is modified
> in one revision, and moved to another file in a later revision, while in
> branch B2 the same function is modified in a different way but left in
> place. If branch B1 is merged into B2, then it might seem that a
> conflict between the function modifications can be ignored (giving a
> clean merge) because the function code is expected to disappear later.
> But unbeknownst to svn, the function code isn't disappearing but is
> rather being moved to another file. So presumably the change made in B2
> has to be resolved with the change made in B1 and both of them moved to
> the new file. The conflict is thus necessary to indicate that human
> intervention is necessary.
>
> Unless the function that was moved to a new file in branch B1 was done
> as part of a svn rename or copy, how is svn supposed to know that a
> function was moved at all?
>
> It seems that, to solve the problem you outline you need to go one step
> further. Even if a change to a file that is about to be deleted merges
> cleanly, that fact that one branch modifes a file and another branch
> deletes it should probably result in a conflict, between a modification
> and a deletion, just so the user can make sure that the modification
> doesn't need to go someplace else instead now that the file is being
> deleted.
Yes, I agree. The check before a file deletion can be merged should be
the same check as is done by "patch"--the patch includes the old text of
the file and only allows the deletion to go through cleanly if the
current contents of the file are the same as the old text listed in the
patch.
> This of course unless you decide to tell svn about any code moving from
> one file to another somehow.
I don't think that is realistic without a whole different concept of
diffs/branching/merging.
The ideal, of course, is that the revision control system doesn't record
file changes but rather user changes at the level of refactoring steps.
A sequence of changes should really be recorded at a level like this:
1. Rename variable "x" to "y" (some SCMs actually try to support this one).
2. Pull method f() up from DerivedClass to BaseClass and adjust callers.
3. Inline function g() at callers.
4. Adjust all copyright notices to include year "2007".
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Mar 11 21:39:50 2007