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].
>
------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1047&dsMessageId=2450517
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subclipse.tigris.org].
Received on 2010-02-22 16:57:26 CET