On Thu, Nov 26, 2009 at 07:27:25AM +0100, Andreas Krey wrote:
> When you do a backmerge, you just need to do a
> diff3 --merge with the heads of trunk and branch as leaves,
> and the revision the last merge between branch and trunk
> originated from. Like:
>
> --A--B--C--D--E--F (trunk)
> \ \
> J--K--L--M--N (branch)
>
> When you now go to merge trunk and branch you take F and N
> as the leaves, and C as the base. Note that this is completely
> symmetric: The files resulting from the merge do not depend
> on whether they are going on the trunk or the branch.
>
> Possibly the problem with svn is that it insists in the backmerge
> case to merge a set of revisions from the branch, and does not
> see the possibility that C--N is the proper diff to put on F.
The above should then be made to work for directory tree changes, too.
But our diff/merge code cannot do diffs of arbitrary trees properly.
It wasn't originally written with that requirement in mind, sorry.
We need proper arbitrary tree diffing to automate tree conflict
resolution as much as possible. This could also help merge in the long run.
On Subversion's timeline, there was a push for getting merge-tracking
implemented before tree conflicts came into the picture. Some think this
was a mistake, that it should have been the other way around (fix
structural merges first, then track them). But that's how it happened,
no amount of complaining will fix this.
> > That said, what is the big deal with specifying --reintegrate?
>
> It just as stupid as to require to specify a revision range...
And as stupid as keeping backwards-compatibility to 1.4?
Changing Subversion in the 1.x line implies a lot of constraints.
I'm not happy either with many of the shortcomings of Subversion (though
I couldn't care less about having to say "this is a reintegrate merge"
or not). But there are exciting new ideas being worked on which will
improve things a lot (e.g. the new working copy format, and a better
client<->server API to communicate tree changes).
I'd like you to stay around and monitor improvements we'll make in
1.7 and subsequent releases.
It's not easy to turn something that started out as a better CVS (a goal
which has arguably been reached long ago) into a magic wand that does
everything you ask it to do, by reading your mind and translating your
personal brain-wave patterns into version control, and make it all
backwards compatible, too.
> > It
> > turns out Subversion did have a merge algorithm that does work
> > properly and specifying --reintegrate just lets it know to apply it.
>
> ...and needing to specify --reintegrate nowadays is the definition of
> 'does not work properly'.
Wow, that's harsh judgement. I would accept this if Subversion could
not do reintegrate merges. But what you want to do is possible to do,
maybe just not as conveniently as you would like, you have to type a
total of 13 characters more (or use a shell alias). That's not "does not
work properly". That's "the tool needs your help a bit because it's not
smart enough". But it still does most of the hard work for you.
(And I guess git users especially don't consider typing command line
options hard to do *cough* *cough* ;)
> There are others out there that just do it.
And these others have other problems that svn doesn't have.
Try locking a jpeg file for exclusive access in other systems so you
don't have to merge it. Try hiding a folder from a particular user.
Try merging a refactored directory tree and get warnings that all your
java packages are now messed up and contain classes that don't belong
in there. Many can't do it while also providing the other features svn
provides. But maybe they can do bi-directional merges without any command
line flags, or they can handle file-renames automatically with only few
false positives, or maybe they have better performance because all they do
is disk i/o. There is no perfect tool, it depends on what you need.
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2424572
Please start new threads on the <users_at_subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <users-subscribe_at_subversion.apache.org>.
Received on 2009-11-26 12:22:30 CET