On Thursday, August 8, 2002, at 04:44 PM, Branko Čibej wrote:
> No, this is _exactly_ what should be happening.
I'm still not convinced.
> Consider how the two nodes' lifelines look:
>
> TRUNK BRANCH
>
> (1) -->(X) -- add myFile (X)
> |
> |
> (2) --> +-----\ -- copy to branch
> | \---->+
> | |
> (3) --> | | (Y) -- add myOtherFlle (Y) on branch
> | | |
> | ......+ |
> (4) --> +<..... /-----+ -- merge to trunk
> | +<----/ | |
> | | | |
> . . . .
> . . . .
> . . . .
>
>
> (Dashed lines represent a node's history, dotted lines represent merge
> direction)
I think you should have the following:
TRUNK BRANCH
(1) -->(X) -- add myFile (X)
|
|
(2) --> +-----\ -- copy to branch
| \---->+
| |
(3) --> | | (Y) -- add myOtherFlle (Y) on branch
| | |
| /....+ |
(4) --> +<..../ /....+ -- merge to trunk
| +<...../ | |
| | | |
. . . .
. . . .
. . . .
Merges should have merge semantics, not copy semantics. You have trade
off here - you want all files to have a single historical root, whereas
I want merges to have the same semantics for all files.
I can see why merges having the same semantics for all files is useful.
I can't see why having all files have a single historical root is useful
(except as an approximate fix for not having merge history)
> From revision 2 onward, X's history has two forks, one on the trunk and
> one on the branch. Y did not exist until revision 3, but was added on
> the branch, not the trunk. When you merge X and Y to the trunk, you
> don't want to create a new fork on X's history (because it already has
> one on the trunk); you do want to fork Y's history, though.
Why do you want to fork Y's history? What does this buy you that having
merge history would not? (again, if you want this as a quick
approximate fix instead of merge history I have no argument. But I
think it is only approximately correct - see the log example for one
side effect.)
> "svn log" just follows the history line backwards in time, That's why
> "svn log trunk" shows changes to Y on the branch. Conversely, "svn log
> branch" would show changes to X on the trunk.
It would show you changes on the trunk from before the branch was made,
and it would be identical for all files that were copied. It is
certainly not behaving one way for some files and another way for others.
> Once we start recording merge sources (the dotted line), "svn log"
> could be taught to optinally show all versions on all branches that
> contributed to a file's contents.
I agree that with the merge sources you can patch the output either
way... which may make any argument irrelevant. And I don't want to
start another huge argument over something that can be patched up
later... so I'm going to be quiet now.
later,
\x/ill :-}
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 8 23:47:02 2002