> On Mon, 5 Apr 2004 20:39:37 -0500, Folker Schamel <schamel23@spinor.com> wrote:
>
>>It's not only "one scenario", its the standard case:
>>If a file has the history of another file,
>>this means per definition that it has the same content
>>plus modifications, and merging is necessary
>>in the same way as for normal modified files.
>
>
> But how would you ever get those 'plus modifications', if every change
> you made to either file was automatically merged to the other?
To avoid misunderstandings:
I'm only taling about renames / copies *within* a project, e.g.
*within* trunk. I'm not talking about branch / tag copies.
Of course, you don't want to propagate changes into a branch copy.
But when you merge, your branch is out of the merge scope anyway.
Sample:
You have
-> trunk/menu.c
-> trunk/dialog.c
you make a branch "copy trunk branch/1"
-> branches/1/menu.c
-> branches/1/dialog.c
and you make a second branch "copy branch/1 branch/2"
-> branches/2/menu.c
-> branches/2/dialog.c
In trunk, you split your dialog into two dialogs,
e.g. "copy trunk/dialog.c trunk/dialog1.c"
plus "move trunk/dialog.c trunk/dialog2.c"
and then modificating trunk/menu.c, trunk/dialog1.c,
and trunk/dialog2.c
-> trunk/menu.c
-> trunk/dialog1.c
-> trunk/dialog2.c
Then you do a bug fix A in branches/1/menu.c
and a bugfix B in branches/1/dialog.c.
This means that trunk/menu.c likely will contain bug A, too,
and trunk/dialog1.c and trunk/dialog2.c likely will contain
bug B, too, for the same reason. But of course
depending on the changes you did on the files.
Then, when merging "merge branches/1 -r m:n trunk"
you want to merge bug fix A into trunk/menu.c,
and bug fix B into trunk/dialog1.c and trunk/dialog2.c
NOT merging bug fix B into trunk/dialog1.c would be dangerous.
But of course, when merging from branches/1 to trunk,
you don't want to apply any changes to branches/2.
And of course, maybe because of changes in trunk/menu.c,
the bug fix A may make no sense to merge into trunk/menu.c
anymore, or in the same way because of changes in
trunk/dialog1.c, bug fix B may make no sense to merge into
trunk/dialog1.c anymore.
But thats a classical issue which is the same for menu.c and
dialog1.c and is no related to moving or copying in any way.
My point is: The need for a merge is independent
from the file still having the same name,
being renamed or being copied within a project.
Note that I am not talking about possible
implementations. As Greg I'm only talking about
"the best merge we can expect from a version control tool".
Cheers,
Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 6 12:46:21 2004