[Pharo-project] Merge tool. No way to cherry pick the changes?
I don't understand, when i merging, the merge tool showing me all the difference between current version and incoming one. It says '0 conflicts' and its ok to merge, but what if i want to choose to keep an old version for some methods, while merge the rest? What i see that there is no way to do that .. all menu items which would allow me to do that, like 'keep current version' 'use incoming verison' 'mark as conflict' are disabled. Which means that once machine decided that there is no conflict, you cannot do much. I tried to quickly hack the UI and enable those menu items , but it doesn't works, because the model itself seems like don't supports that. So, the question is how we can change that? As to me, it is certainly a missing feature, if i cannot freely choose between current and incoming version at my will, when merging. Gary (& all)? Any ideas? -- Best regards, Igor Stasenko AKA sig.
I'm missing that too. In previous versions, IIRC, there was a menu item for changed methods named "Install". Adrian On Jun 21, 2011, at 14:37 , Igor Stasenko wrote:
I don't understand, when i merging, the merge tool showing me all the difference between current version and incoming one. It says '0 conflicts' and its ok to merge, but what if i want to choose to keep an old version for some methods, while merge the rest?
What i see that there is no way to do that .. all menu items which would allow me to do that, like 'keep current version' 'use incoming verison' 'mark as conflict' are disabled.
Which means that once machine decided that there is no conflict, you cannot do much. I tried to quickly hack the UI and enable those menu items , but it doesn't works, because the model itself seems like don't supports that.
So, the question is how we can change that? As to me, it is certainly a missing feature, if i cannot freely choose between current and incoming version at my will, when merging.
Gary (& all)? Any ideas?
-- Best regards, Igor Stasenko AKA sig.
Yeap, preety annoying. It's annoying too that you can't do any kind of filter (for example, to not show the ones marked as "revision changed"). Merging Glorp was kind of a mess :). On Tue, Jun 21, 2011 at 11:00 AM, Adrian Lienhard <adi@netstyle.ch> wrote:
I'm missing that too.
In previous versions, IIRC, there was a menu item for changed methods named "Install".
Adrian
On Jun 21, 2011, at 14:37 , Igor Stasenko wrote:
I don't understand, when i merging, the merge tool showing me all the difference between current version and incoming one. It says '0 conflicts' and its ok to merge, but what if i want to choose to keep an old version for some methods, while merge the rest?
What i see that there is no way to do that .. all menu items which would allow me to do that, like 'keep current version' 'use incoming verison' 'mark as conflict' are disabled.
Which means that once machine decided that there is no conflict, you cannot do much. I tried to quickly hack the UI and enable those menu items , but it doesn't works, because the model itself seems like don't supports that.
So, the question is how we can change that? As to me, it is certainly a missing feature, if i cannot freely choose between current and incoming version at my will, when merging.
Gary (& all)? Any ideas?
-- Best regards, Igor Stasenko AKA sig.
we should improve that aspect First would be to resurrect the install menu and behavior. Stef On Jun 21, 2011, at 4:04 PM, Guillermo Polito wrote:
Yeap, preety annoying. It's annoying too that you can't do any kind of filter (for example, to not show the ones marked as "revision changed"). Merging Glorp was kind of a mess :).
On Tue, Jun 21, 2011 at 11:00 AM, Adrian Lienhard <adi@netstyle.ch> wrote: I'm missing that too.
In previous versions, IIRC, there was a menu item for changed methods named "Install".
Adrian
On Jun 21, 2011, at 14:37 , Igor Stasenko wrote:
I don't understand, when i merging, the merge tool showing me all the difference between current version and incoming one. It says '0 conflicts' and its ok to merge, but what if i want to choose to keep an old version for some methods, while merge the rest?
What i see that there is no way to do that .. all menu items which would allow me to do that, like 'keep current version' 'use incoming verison' 'mark as conflict' are disabled.
Which means that once machine decided that there is no conflict, you cannot do much. I tried to quickly hack the UI and enable those menu items , but it doesn't works, because the model itself seems like don't supports that.
So, the question is how we can change that? As to me, it is certainly a missing feature, if i cannot freely choose between current and incoming version at my will, when merging.
Gary (& all)? Any ideas?
-- Best regards, Igor Stasenko AKA sig.
Here the code http://code.google.com/p/pharo/issues/detail?id=4439 please tell me if it works for you. I tested on simple merge and it works fine (the changes which i marked as not applicable are not loaded). -- Best regards, Igor Stasenko AKA sig.
Perhaps the "non-applicable" could be streamlined. I.e., "keep current version" = not applicable. No need for the extra menu item then. Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, June 22, 2011 3:40 PM Subject: Re: [Pharo-project] Merge tool. No way to cherry pick the changes?
Here the code http://code.google.com/p/pharo/issues/detail?id=4439
please tell me if it works for you. I tested on simple merge and it works fine (the changes which i marked as not applicable are not loaded).
-- Best regards, Igor Stasenko AKA sig.
On 22 June 2011 17:43, Gary Chambers <gazzaguru2@btinternet.com> wrote:
Perhaps the "non-applicable" could be streamlined. I.e., "keep current version" = not applicable.
yes, could be.. but that logic are only for conflics.. and i didn't wanted to mess with it because its a lot more work. Because strangely , instead of using field to indicate a conflict (in MCPatchOperation record) it does something strange and overly complicated (MCConflict). So, then each entry could contain 'isApplicable' and 'isConflicting' and once user resolves the conflict, the isConflicting should be set to false, while isApplicable are uniformly to indicate which version to use (current or incoming one), when merging.
No need for the extra menu item then.
Regards, Gary
----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, June 22, 2011 3:40 PM Subject: Re: [Pharo-project] Merge tool. No way to cherry pick the changes?
Here the code http://code.google.com/p/pharo/issues/detail?id=4439
please tell me if it works for you. I tested on simple merge and it works fine (the changes which i marked as not applicable are not loaded).
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
On 22 June 2011 20:00, Igor Stasenko <siguctua@gmail.com> wrote:
On 22 June 2011 17:43, Gary Chambers <gazzaguru2@btinternet.com> wrote:
Perhaps the "non-applicable" could be streamlined. I.e., "keep current version" = not applicable.
yes, could be.. but that logic are only for conflics.. and i didn't wanted to mess with it because its a lot more work.
btw, Stephane, this is a good topic for dealing with it on friday, if you don't have anything else in mind.
Because strangely , instead of using field to indicate a conflict (in MCPatchOperation record) it does something strange and overly complicated (MCConflict).
So, then each entry could contain 'isApplicable' and 'isConflicting'
and once user resolves the conflict, the isConflicting should be set to false, while isApplicable are uniformly to indicate which version to use (current or incoming one), when merging.
No need for the extra menu item then.
Regards, Gary
----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, June 22, 2011 3:40 PM Subject: Re: [Pharo-project] Merge tool. No way to cherry pick the changes?
Here the code http://code.google.com/p/pharo/issues/detail?id=4439
please tell me if it works for you. I tested on simple merge and it works fine (the changes which i marked as not applicable are not loaded).
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
Perhaps the "non-applicable" could be streamlined. I.e., "keep current version" = not applicable.
yes, could be.. but that logic are only for conflics.. and i didn't wanted to mess with it because its a lot more work.
btw, Stephane, this is a good topic for dealing with it on friday, if you don't have anything else in mind.
ok did you run MC tests? I htink that we should invest more in running tests.
Because strangely , instead of using field to indicate a conflict (in MCPatchOperation record) it does something strange and overly complicated (MCConflict).
So, then each entry could contain 'isApplicable' and 'isConflicting'
and once user resolves the conflict, the isConflicting should be set to false, while isApplicable are uniformly to indicate which version to use (current or incoming one), when merging.
No need for the extra menu item then.
Regards, Gary
----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, June 22, 2011 3:40 PM Subject: Re: [Pharo-project] Merge tool. No way to cherry pick the changes?
Here the code http://code.google.com/p/pharo/issues/detail?id=4439
please tell me if it works for you. I tested on simple merge and it works fine (the changes which i marked as not applicable are not loaded).
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
On 22 June 2011 23:10, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Perhaps the "non-applicable" could be streamlined. I.e., "keep current version" = not applicable.
yes, could be.. but that logic are only for conflics.. and i didn't wanted to mess with it because its a lot more work.
btw, Stephane, this is a good topic for dealing with it on friday, if you don't have anything else in mind.
ok did you run MC tests? I htink that we should invest more in running tests.
well, the changes i made are not intrusive, i mean it will work as before unless user plays with this flag using UI. So, MC will behave exactly as before and there is no problem from that side.
Because strangely , instead of using field to indicate a conflict (in MCPatchOperation record) it does something strange and overly complicated (MCConflict).
So, then each entry could contain 'isApplicable' and 'isConflicting'
and once user resolves the conflict, the isConflicting should be set to false, while isApplicable are uniformly to indicate which version to use (current or incoming one), when merging.
No need for the extra menu item then.
Regards, Gary
----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, June 22, 2011 3:40 PM Subject: Re: [Pharo-project] Merge tool. No way to cherry pick the changes?
Here the code http://code.google.com/p/pharo/issues/detail?id=4439
please tell me if it works for you. I tested on simple merge and it works fine (the changes which i marked as not applicable are not loaded).
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
Isn't it one of the features supported by backport ? http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-September/082094... Nicolas 2011/6/23 Igor Stasenko <siguctua@gmail.com>:
On 22 June 2011 23:10, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Perhaps the "non-applicable" could be streamlined. I.e., "keep current version" = not applicable.
yes, could be.. but that logic are only for conflics.. and i didn't wanted to mess with it because its a lot more work.
btw, Stephane, this is a good topic for dealing with it on friday, if you don't have anything else in mind.
ok did you run MC tests? I htink that we should invest more in running tests.
well, the changes i made are not intrusive, i mean it will work as before unless user plays with this flag using UI. So, MC will behave exactly as before and there is no problem from that side.
Because strangely , instead of using field to indicate a conflict (in MCPatchOperation record) it does something strange and overly complicated (MCConflict).
So, then each entry could contain 'isApplicable' and 'isConflicting'
and once user resolves the conflict, the isConflicting should be set to false, while isApplicable are uniformly to indicate which version to use (current or incoming one), when merging.
No need for the extra menu item then.
Regards, Gary
----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, June 22, 2011 3:40 PM Subject: Re: [Pharo-project] Merge tool. No way to cherry pick the changes?
Here the code http://code.google.com/p/pharo/issues/detail?id=4439
please tell me if it works for you. I tested on simple merge and it works fine (the changes which i marked as not applicable are not loaded).
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
no backport is no cherry picking. Stef On Jun 25, 2011, at 10:18 PM, Nicolas Cellier wrote:
Isn't it one of the features supported by backport ?
http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-September/082094...
Nicolas
2011/6/23 Igor Stasenko <siguctua@gmail.com>:
On 22 June 2011 23:10, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Perhaps the "non-applicable" could be streamlined. I.e., "keep current version" = not applicable.
yes, could be.. but that logic are only for conflics.. and i didn't wanted to mess with it because its a lot more work.
btw, Stephane, this is a good topic for dealing with it on friday, if you don't have anything else in mind.
ok did you run MC tests? I htink that we should invest more in running tests.
well, the changes i made are not intrusive, i mean it will work as before unless user plays with this flag using UI. So, MC will behave exactly as before and there is no problem from that side.
Because strangely , instead of using field to indicate a conflict (in MCPatchOperation record) it does something strange and overly complicated (MCConflict).
So, then each entry could contain 'isApplicable' and 'isConflicting'
and once user resolves the conflict, the isConflicting should be set to false, while isApplicable are uniformly to indicate which version to use (current or incoming one), when merging.
No need for the extra menu item then.
Regards, Gary
----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, June 22, 2011 3:40 PM Subject: Re: [Pharo-project] Merge tool. No way to cherry pick the changes?
Here the code http://code.google.com/p/pharo/issues/detail?id=4439
please tell me if it works for you. I tested on simple merge and it works fine (the changes which i marked as not applicable are not loaded).
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
On 25 June 2011 22:18, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
Isn't it one of the features supported by backport ?
http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-September/082094...
yes, sounds similar. Except that i never used this feature since it is mystery to me, how it works. Documentation....
Nicolas
2011/6/23 Igor Stasenko <siguctua@gmail.com>:
On 22 June 2011 23:10, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Perhaps the "non-applicable" could be streamlined. I.e., "keep current version" = not applicable.
yes, could be.. but that logic are only for conflics.. and i didn't wanted to mess with it because its a lot more work.
btw, Stephane, this is a good topic for dealing with it on friday, if you don't have anything else in mind.
ok did you run MC tests? I htink that we should invest more in running tests.
well, the changes i made are not intrusive, i mean it will work as before unless user plays with this flag using UI. So, MC will behave exactly as before and there is no problem from that side.
Because strangely , instead of using field to indicate a conflict (in MCPatchOperation record) it does something strange and overly complicated (MCConflict).
So, then each entry could contain 'isApplicable' and 'isConflicting'
and once user resolves the conflict, the isConflicting should be set to false, while isApplicable are uniformly to indicate which version to use (current or incoming one), when merging.
No need for the extra menu item then.
Regards, Gary
----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, June 22, 2011 3:40 PM Subject: Re: [Pharo-project] Merge tool. No way to cherry pick the changes?
Here the code http://code.google.com/p/pharo/issues/detail?id=4439
please tell me if it works for you. I tested on simple merge and it works fine (the changes which i marked as not applicable are not loaded).
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
On Jun 27, 2011, at 1:26 PM, Igor Stasenko wrote:
On 25 June 2011 22:18, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
Isn't it one of the features supported by backport ?
http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-September/082094...
yes, sounds similar. Except that i never used this feature since it is mystery to me, how it works. Documentation....
it is explained in the monticello chapter of pharo by example 2
Nicolas
2011/6/23 Igor Stasenko <siguctua@gmail.com>:
On 22 June 2011 23:10, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Perhaps the "non-applicable" could be streamlined. I.e., "keep current version" = not applicable.
yes, could be.. but that logic are only for conflics.. and i didn't wanted to mess with it because its a lot more work.
btw, Stephane, this is a good topic for dealing with it on friday, if you don't have anything else in mind.
ok did you run MC tests? I htink that we should invest more in running tests.
well, the changes i made are not intrusive, i mean it will work as before unless user plays with this flag using UI. So, MC will behave exactly as before and there is no problem from that side.
Because strangely , instead of using field to indicate a conflict (in MCPatchOperation record) it does something strange and overly complicated (MCConflict).
So, then each entry could contain 'isApplicable' and 'isConflicting'
and once user resolves the conflict, the isConflicting should be set to false, while isApplicable are uniformly to indicate which version to use (current or incoming one), when merging.
No need for the extra menu item then.
Regards, Gary
----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, June 22, 2011 3:40 PM Subject: Re: [Pharo-project] Merge tool. No way to cherry pick the changes?
Here the code http://code.google.com/p/pharo/issues/detail?id=4439
please tell me if it works for you. I tested on simple merge and it works fine (the changes which i marked as not applicable are not loaded).
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
On 27 June 2011 22:13, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Jun 27, 2011, at 1:26 PM, Igor Stasenko wrote:
On 25 June 2011 22:18, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
Isn't it one of the features supported by backport ?
http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-September/082094...
yes, sounds similar. Except that i never used this feature since it is mystery to me, how it works. Documentation....
it is explained in the monticello chapter of pharo by example 2
so, why you saying it's completely different? one or another way, backport allows to cherry-pick changes (from what i have read in link that Nicolas gave). -- Best regards, Igor Stasenko AKA sig.
On 25 June 2011 22:18, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
Isn't it one of the features supported by backport ?
http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-September/082094...
yes, sounds similar. Except that i never used this feature since it is mystery to me, how it works. Documentation....
it is explained in the monticello chapter of pharo by example 2
so, why you saying it's completely different? one or another way, backport allows to cherry-pick changes (from what i have read in link that Nicolas gave).
Not from what I understood back when we wrote the chapter. But may be yes. Have a look at what we wrote. Stef
Indeed, MC only supports keep-current/use-incoming if the item is a conflict. I'd be happy to help with the UI if you want to have a go at making the model work ;-) Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: "Pharo Development" <Pharo-project@lists.gforge.inria.fr> Sent: Tuesday, June 21, 2011 1:37 PM Subject: [Pharo-project] Merge tool. No way to cherry pick the changes?
I don't understand, when i merging, the merge tool showing me all the difference between current version and incoming one. It says '0 conflicts' and its ok to merge, but what if i want to choose to keep an old version for some methods, while merge the rest?
What i see that there is no way to do that .. all menu items which would allow me to do that, like 'keep current version' 'use incoming verison' 'mark as conflict' are disabled.
Which means that once machine decided that there is no conflict, you cannot do much. I tried to quickly hack the UI and enable those menu items , but it doesn't works, because the model itself seems like don't supports that.
So, the question is how we can change that? As to me, it is certainly a missing feature, if i cannot freely choose between current and incoming version at my will, when merging.
Gary (& all)? Any ideas?
-- Best regards, Igor Stasenko AKA sig.
participants (6)
-
Adrian Lienhard -
Gary Chambers -
Guillermo Polito -
Igor Stasenko -
Nicolas Cellier -
Stéphane Ducasse