The reason is explained in the blog post. The reason is that there is
no right answer. It is not always true that excluding the revision is
the right thing to do.
First off, there are inexperienced or sloppy users that will commit a
merge that also contains other unrelated changes. If we just skip the
revision those changes are lost.
The main issue is that when you commit a merge you also are committing
the conflict resolution work you did. If you skip the revision you
skip all of that work.
Anyway, this would be a better request for users_at_subversion as this
logic would have to be added to Subversion.
On Mon, Feb 22, 2010 at 6:54 AM, jcompagner <jcompagner_at_gmail.com> wrote:
> thx for the input
> but i still think that subversion or the merge client (but thats then client
> side not the most optimal solution) can fix it pretty easy
> lets say i have this
> first i make a change (revision 1) in branch and merge that to trunk
> (revision 2)
> At this time the svn:mergeinfo of trunk/project1 has an entry:
> Then i make a change in trunk and commit it (revision 3)
> now i go to the branch and tell it to merge the one from trunk.
> Why cant svn then not look up the merge info of trunk (the /branch/project1
> with revision 1) or the merge revision info (dont know where that is stored)
> and there you have a revision 2 (of trunk) that has a merged revision 1 (of
> branch) and filter revision 2 out of the stuff you return?
> On Fri, Feb 19, 2010 at 17:34, Mark Phippard <markphip_at_gmail.com> wrote:
>> This is a core Subversion issue and the same reason that drives the
>> need for the reintegrate option:
>> You can use the Block option to record the revision on your branch,
>> but as you indicate it is something you have to know to do and do
>> On Fri, Feb 19, 2010 at 8:04 AM, jcompagner <jcompagner_at_gmail.com> wrote:
>> > Hi,
>> > Dont know if this is a subclipse/merge client thing or a subversion
>> > thing
>> > itself
>> > So i will just ask it here.
>> > Most of the time if i make a change i know upfront ok that should be
>> > first
>> > in the branch and then i merge it to trunk
>> > But there are also other times that i first do it on trunk and then
>> > later on
>> > its decided ok thats tested and should also go into the branch.
>> > But if you merge like this both ways.
>> > Then i find it a bit confusing (and i constantly have to remember it and
>> > check it again) that a merge of revision 10 from trunk to branch.
>> > Is again in the list of things to merge, if i merge from branch to trunk
>> > then i see revision 20 from branch (which is the merge of 10 from trunk)
>> > Cant the merge client or subversion not see this for me? And not show me
>> > those options that are already in trunk because that was the original
>> > code?
>> > More like a auto block revision on trunk when i do the merge in/on
>> > branch.
>> > (i know this is not possible because you cant of course change trunk
>> > when
>> > you are working/merging in branch)
>> > But i think when i ask i want to the branch url for the revisions it
>> > should
>> > try to look in the merge properties of that url/project and see that
>> > there
>> > are the merge properties of those revisions and that filter them out for
>> > me.
>> > johan
>> Mark Phippard
>> To unsubscribe from this discussion, e-mail:
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subclipse.tigris.org].
Received on 2010-02-22 16:52:56 CET