On Mon, 2004-02-23 at 11:57, Alexander Staubo wrote:
> The article at http://www.onlamp.com/lpt/a/4522, published Jan 29, claims:
>
> > Moreover, Subversion's support for merging is limited and resembles
> > that of CVS. (i.e., merges to branches where files were moved will not
> > be performed correctly).
>
> I can't find any reference to this limitation in the Subversion book;
> is it still the case? I assume by "move" they also mean renaming.
I'm not sure what Shlomi meant by that statement. If you're performing
a merge that includes a move, then the move will happen. If, on the
other hand, your merge is trying to patch a file that has *already* been
renamed on the branch, then yes, 'svn merge' isn't smart enough to know
that the patch should be applied to the new filename.
Of course, this isn't a huge deal: if you look at the merge operation
as the application of a giant patch (a patch which understands tree
operations in addition to textual changes), then this is a case of part
of the patch not applying, a "failed hunk" as it were. If that
happened, I would say: "hm, is this patch really appropriate? did I
choose the correct patch to apply?" If it were a routine merge from one
branch to another, I'd attribute it to user error. If it were
cherry-picked changeset that you're applying, then I'd shrug and work
out the problem by hand.
It's the last great frontier: being able to arbitrarily merge any
changeset to any tree with as few "failed hunks" as possible. It's the
problem that projects like bitkeeper and arch have been working on for
years, and which svn has hardly touched yet.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Feb 23 19:19:28 2004