I do not really want to touch that logic. Performance wise, I believe
you would actually have to be running the "log -g" API on the path you
are merging so that for each revision you can see if it was a merge,
and if so, what revisions it merged. You cannot just look at the
current mergeinfo and learn anything.
This would really need to be done by Subversion itself.
On Mon, Feb 22, 2010 at 7:56 AM, jcompagner <jcompagner_at_gmail.com> wrote:
> ah ok.
> But then could we extract it to the merge client?
> Had have an option there "filter merges"
> And if we enable that it does a get merge revision query to the server that
> filters all id's that the other already has?
> (the question is more, is there an query option for that?)
>
> If so then i could look if i can make that into the merge client code and
> create a patch for it.
>
> johan
>
>
> On Mon, Feb 22, 2010 at 16:52, Mark Phippard <markphip_at_gmail.com> wrote:
>>
>> 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.
>>
>> Mark
>>
>>
>> On Mon, Feb 22, 2010 at 6:54 AM, jcompagner <jcompagner_at_gmail.com> wrote:
>> > Mark,
>> >
>> > 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
>> >
>> > /trunk/project1
>> >
>> > and
>> >
>> > /branch/project1
>> >
>> > 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:
>> >
>> > /branch/project1:1
>> >
>> > 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?
>> >
>> > johan
>> >
>> >
>> >
>> > 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:
>> >>
>> >> http://blogs.open.collab.net/svn/2008/07/subversion-merg.html
>> >>
>> >> 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
>> >> yourself.
>> >>
>> >> Mark
>> >>
>> >> 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
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Thanks
>> >>
>> >> Mark Phippard
>> >> http://markphip.blogspot.com/
>> >>
>> >> ------------------------------------------------------
>> >>
>> >>
>> >> http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1047&dsMessageId=2449143
>> >>
>> >> To unsubscribe from this discussion, e-mail:
>> >> [users-unsubscribe_at_subclipse.tigris.org].
>> >
>> >
>>
>>
>>
>> --
>> Thanks
>>
>> Mark Phippard
>> http://markphip.blogspot.com/
>>
>> ------------------------------------------------------
>>
>> http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1047&dsMessageId=2450514
>>
>> To unsubscribe from this discussion, e-mail:
>> [users-unsubscribe_at_subclipse.tigris.org].
>
>
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1047&dsMessageId=2450518
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subclipse.tigris.org].
Received on 2010-02-22 17:00:21 CET