(amber ♥ git) not
Locked
 
|
We decided to use amber for a few customer projects. The workflow is quite good and developing web stuff just so much more fun doing it with amber than plain javascript. However I cannot say the same for git. We are working with three people on the project and the git experience is horrible. To be honest I don't fully understand it. Amber just creates packages so the possibility of a conflict is very likely. In our experience the merge is often not automatic but has conflicts. The sections of the merge are really big and begin sometimes in the middle of a method.
Has anybody else such an experience. Are there any things to do additionally in order to help with that? How about a special merge driver? I'm sorry but I'm rather glueless what is the real problem. The only thing I know is that we loose a lot of code because the merges are big. thanks, Norbert -- You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
With little changes I had not have so many merge problems, but they can always appear as .js is generated.
One pragmatic way to solve merge conflicts is to ignore .js conflict(s), solve .st conflict(s), and run `grunt` to recompile those .st files. Norbert Hartl wrote: > We decided to use amber for a few customer projects. The workflow is quite good and developing web stuff just so much more fun doing it with amber than plain javascript. However I cannot say the same for git. We are working with three people on the project and the git experience is horrible. To be honest I don't fully understand it. Amber just creates packages so the possibility of a conflict is very likely. In our experience the merge is often not automatic but has conflicts. The sections of the merge are really big and begin sometimes in the middle of a method. > > Has anybody else such an experience. Are there any things to do additionally in order to help with that? How about a special merge driver? > > I'm sorry but I'm rather glueless what is the real problem. The only thing I know is that we loose a lot of code because the merges are big. > > thanks, > > Norbert > > > -- You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
That's what I do as well. Phil You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
In reply to this post by Herby Vojčík
> Am 18.05.2015 um 15:15 schrieb Herby Vojčík <[hidden email]>: > > With little changes I had not have so many merge problems, but they can always appear as .js is generated. > > One pragmatic way to solve merge conflicts is to ignore .js conflict(s), solve .st conflict(s), and run `grunt` to recompile those .st files. I wasn't talking about the js files because I fix the .st files and compile them to .js as well. But I have huge conflicts in .st. Norbert > > Norbert Hartl wrote: >> We decided to use amber for a few customer projects. The workflow is quite good and developing web stuff just so much more fun doing it with amber than plain javascript. However I cannot say the same for git. We are working with three people on the project and the git experience is horrible. To be honest I don't fully understand it. Amber just creates packages so the possibility of a conflict is very likely. In our experience the merge is often not automatic but has conflicts. The sections of the merge are really big and begin sometimes in the middle of a method. >> >> Has anybody else such an experience. Are there any things to do additionally in order to help with that? How about a special merge driver? >> > >> I'm sorry but I'm rather glueless what is the real problem. The only thing I know is that we loose a lot of code because the merges are big. >> >> thanks, >> >> Norbert >> >> >> > > -- > You received this message because you are subscribed to the Google Groups "amber-lang" group. > To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
Norbert
Just wondering. How many packages do you have? And you write that 3 people are working on the project. How are packages assigned to people? --Hannes On 5/18/15, Norbert Hartl <[hidden email]> wrote: > >> Am 18.05.2015 um 15:15 schrieb Herby Vojčík <[hidden email]>: >> >> With little changes I had not have so many merge problems, but they can >> always appear as .js is generated. >> >> One pragmatic way to solve merge conflicts is to ignore .js conflict(s), >> solve .st conflict(s), and run `grunt` to recompile those .st files. > > I wasn't talking about the js files because I fix the .st files and compile > them to .js as well. But I have huge conflicts in .st. > > Norbert > >> >> Norbert Hartl wrote: >>> We decided to use amber for a few customer projects. The workflow is >>> quite good and developing web stuff just so much more fun doing it with >>> amber than plain javascript. However I cannot say the same for git. We >>> are working with three people on the project and the git experience is >>> horrible. To be honest I don't fully understand it. Amber just creates >>> packages so the possibility of a conflict is very likely. In our >>> experience the merge is often not automatic but has conflicts. The >>> sections of the merge are really big and begin sometimes in the middle of >>> a method. >>> >>> Has anybody else such an experience. Are there any things to do >>> additionally in order to help with that? How about a special merge >>> driver? >>> >> >>> I'm sorry but I'm rather glueless what is the real problem. The only >>> thing I know is that we loose a lot of code because the merges are big. >>> >>> thanks, >>> >>> Norbert >>> >>> >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "amber-lang" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [hidden email]. >> For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "amber-lang" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [hidden email]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
> Am 18.05.2015 um 23:15 schrieb H. Hirzel <[hidden email]>: > > Norbert > > Just wondering. How many packages do you have? And you write that 3 > people are working on the project. How are packages assigned to > people? > We have 4 packages. One for backend code and one for frontend code and the corresponding test packages for each. I know we could limit the problem by creating more packages. But it wouldn't solve the issue. It is just that I find the merge behaviour of git weird because the diff sections are really huge. Usually the diff tools are quite good to detect what read differs. They manage to recognize if code has just been moved and such. And I know what I'm saying is a bit vague. I need to dig into that. I just wanted to know if there is anything that should be done when using amber with (!$%#!"%&) git. Norbert > --Hannes > > On 5/18/15, Norbert Hartl <[hidden email]> wrote: >> >>> Am 18.05.2015 um 15:15 schrieb Herby Vojčík <[hidden email]>: >>> >>> With little changes I had not have so many merge problems, but they can >>> always appear as .js is generated. >>> >>> One pragmatic way to solve merge conflicts is to ignore .js conflict(s), >>> solve .st conflict(s), and run `grunt` to recompile those .st files. >> >> I wasn't talking about the js files because I fix the .st files and compile >> them to .js as well. But I have huge conflicts in .st. >> >> Norbert >> >>> >>> Norbert Hartl wrote: >>>> We decided to use amber for a few customer projects. The workflow is >>>> quite good and developing web stuff just so much more fun doing it with >>>> amber than plain javascript. However I cannot say the same for git. We >>>> are working with three people on the project and the git experience is >>>> horrible. To be honest I don't fully understand it. Amber just creates >>>> packages so the possibility of a conflict is very likely. In our >>>> experience the merge is often not automatic but has conflicts. The >>>> sections of the merge are really big and begin sometimes in the middle of >>>> a method. >>>> >>>> Has anybody else such an experience. Are there any things to do >>>> additionally in order to help with that? How about a special merge >>>> driver? >>>> >>> >>>> I'm sorry but I'm rather glueless what is the real problem. The only >>>> thing I know is that we loose a lot of code because the merges are big. >>>> >>>> thanks, >>>> >>>> Norbert >>>> >>>> >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "amber-lang" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to [hidden email]. >>> For more options, visit https://groups.google.com/d/optout. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "amber-lang" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [hidden email]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google Groups "amber-lang" group. > To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
As you write, what you say is a bit vague. It seems to be a project
management issue. How to evolve the code base so that the three people can work comparatively independently. --Hannes On 5/19/15, Norbert Hartl <[hidden email]> wrote: > >> Am 18.05.2015 um 23:15 schrieb H. Hirzel <[hidden email]>: >> >> Norbert >> >> Just wondering. How many packages do you have? And you write that 3 >> people are working on the project. How are packages assigned to >> people? >> > We have 4 packages. One for backend code and one for frontend code and the > corresponding test packages for each. I know we could limit the problem by > creating more packages. But it wouldn't solve the issue. It is just that I > find the merge behaviour of git weird because the diff sections are really > huge. Usually the diff tools are quite good to detect what read differs. > They manage to recognize if code has just been moved and such. And I know > what I'm saying is a bit vague. I need to dig into that. I just wanted to > know if there is anything that should be done when using amber with > (!$%#!"%&) git. > > Norbert > >> --Hannes >> >> On 5/18/15, Norbert Hartl <[hidden email]> wrote: >>> >>>> Am 18.05.2015 um 15:15 schrieb Herby Vojčík <[hidden email]>: >>>> >>>> With little changes I had not have so many merge problems, but they can >>>> always appear as .js is generated. >>>> >>>> One pragmatic way to solve merge conflicts is to ignore .js >>>> conflict(s), >>>> solve .st conflict(s), and run `grunt` to recompile those .st files. >>> >>> I wasn't talking about the js files because I fix the .st files and >>> compile >>> them to .js as well. But I have huge conflicts in .st. >>> >>> Norbert >>> >>>> >>>> Norbert Hartl wrote: >>>>> We decided to use amber for a few customer projects. The workflow is >>>>> quite good and developing web stuff just so much more fun doing it >>>>> with >>>>> amber than plain javascript. However I cannot say the same for git. We >>>>> are working with three people on the project and the git experience is >>>>> horrible. To be honest I don't fully understand it. Amber just >>>>> creates >>>>> packages so the possibility of a conflict is very likely. In our >>>>> experience the merge is often not automatic but has conflicts. The >>>>> sections of the merge are really big and begin sometimes in the middle >>>>> of >>>>> a method. >>>>> >>>>> Has anybody else such an experience. Are there any things to do >>>>> additionally in order to help with that? How about a special merge >>>>> driver? >>>>> >>>> >>>>> I'm sorry but I'm rather glueless what is the real problem. The only >>>>> thing I know is that we loose a lot of code because the merges are >>>>> big. >>>>> >>>>> thanks, >>>>> >>>>> Norbert >>>>> >>>>> >>>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups >>>> "amber-lang" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an >>>> email to [hidden email]. >>>> For more options, visit https://groups.google.com/d/optout. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups >>> "amber-lang" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an >>> email to [hidden email]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "amber-lang" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [hidden email]. >> For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "amber-lang" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [hidden email]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
I disagree. Morphing a code base just to satisfy a tool is a bad hack and always turns back on you later. A code base should follow architectural requirements. To make working feasible you usually tweak the tools to manage source code not the code itself.
But having small packages can be both: architectural advisable and amber friendly :) Norbert > Am 19.05.2015 um 09:06 schrieb H. Hirzel <[hidden email]>: > > As you write, what you say is a bit vague. It seems to be a project > management issue. How to evolve the code base so that the three people > can work comparatively independently. > > --Hannes > > On 5/19/15, Norbert Hartl <[hidden email]> wrote: >> >>> Am 18.05.2015 um 23:15 schrieb H. Hirzel <[hidden email]>: >>> >>> Norbert >>> >>> Just wondering. How many packages do you have? And you write that 3 >>> people are working on the project. How are packages assigned to >>> people? >>> >> We have 4 packages. One for backend code and one for frontend code and the >> corresponding test packages for each. I know we could limit the problem by >> creating more packages. But it wouldn't solve the issue. It is just that I >> find the merge behaviour of git weird because the diff sections are really >> huge. Usually the diff tools are quite good to detect what read differs. >> They manage to recognize if code has just been moved and such. And I know >> what I'm saying is a bit vague. I need to dig into that. I just wanted to >> know if there is anything that should be done when using amber with >> (!$%#!"%&) git. >> >> Norbert >> >>> --Hannes >>> >>> On 5/18/15, Norbert Hartl <[hidden email]> wrote: >>>> >>>>> Am 18.05.2015 um 15:15 schrieb Herby Vojčík <[hidden email]>: >>>>> >>>>> With little changes I had not have so many merge problems, but they can >>>>> always appear as .js is generated. >>>>> >>>>> One pragmatic way to solve merge conflicts is to ignore .js >>>>> conflict(s), >>>>> solve .st conflict(s), and run `grunt` to recompile those .st files. >>>> >>>> I wasn't talking about the js files because I fix the .st files and >>>> compile >>>> them to .js as well. But I have huge conflicts in .st. >>>> >>>> Norbert >>>> >>>>> >>>>> Norbert Hartl wrote: >>>>>> We decided to use amber for a few customer projects. The workflow is >>>>>> quite good and developing web stuff just so much more fun doing it >>>>>> with >>>>>> amber than plain javascript. However I cannot say the same for git. We >>>>>> are working with three people on the project and the git experience is >>>>>> horrible. To be honest I don't fully understand it. Amber just >>>>>> creates >>>>>> packages so the possibility of a conflict is very likely. In our >>>>>> experience the merge is often not automatic but has conflicts. The >>>>>> sections of the merge are really big and begin sometimes in the middle >>>>>> of >>>>>> a method. >>>>>> >>>>>> Has anybody else such an experience. Are there any things to do >>>>>> additionally in order to help with that? How about a special merge >>>>>> driver? >>>>>> >>>>> >>>>>> I'm sorry but I'm rather glueless what is the real problem. The only >>>>>> thing I know is that we loose a lot of code because the merges are >>>>>> big. >>>>>> >>>>>> thanks, >>>>>> >>>>>> Norbert >>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups >>>>> "amber-lang" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an >>>>> email to [hidden email]. >>>>> For more options, visit https://groups.google.com/d/optout. >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups >>>> "amber-lang" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an >>>> email to [hidden email]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "amber-lang" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to [hidden email]. >>> For more options, visit https://groups.google.com/d/optout. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "amber-lang" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [hidden email]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google Groups "amber-lang" group. > To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
I cannot outline the strategy how to deal with it at the moment but
surely it is not a hack if you do it properly. It is about project management and design issues. --HH On 5/19/15, Norbert Hartl <[hidden email]> wrote: > I disagree. Morphing a code base just to satisfy a tool is a bad hack and > always turns back on you later. A code base should follow architectural > requirements. To make working feasible you usually tweak the tools to manage > source code not the code itself. > > But having small packages can be both: architectural advisable and amber > friendly :) > > Norbert > >> Am 19.05.2015 um 09:06 schrieb H. Hirzel <[hidden email]>: >> >> As you write, what you say is a bit vague. It seems to be a project >> management issue. How to evolve the code base so that the three people >> can work comparatively independently. >> >> --Hannes >> >> On 5/19/15, Norbert Hartl <[hidden email]> wrote: >>> >>>> Am 18.05.2015 um 23:15 schrieb H. Hirzel <[hidden email]>: >>>> >>>> Norbert >>>> >>>> Just wondering. How many packages do you have? And you write that 3 >>>> people are working on the project. How are packages assigned to >>>> people? >>>> >>> We have 4 packages. One for backend code and one for frontend code and >>> the >>> corresponding test packages for each. I know we could limit the problem >>> by >>> creating more packages. But it wouldn't solve the issue. It is just that >>> I >>> find the merge behaviour of git weird because the diff sections are >>> really >>> huge. Usually the diff tools are quite good to detect what read differs. >>> They manage to recognize if code has just been moved and such. And I >>> know >>> what I'm saying is a bit vague. I need to dig into that. I just wanted >>> to >>> know if there is anything that should be done when using amber with >>> (!$%#!"%&) git. >>> >>> Norbert >>> >>>> --Hannes >>>> >>>> On 5/18/15, Norbert Hartl <[hidden email]> wrote: >>>>> >>>>>> Am 18.05.2015 um 15:15 schrieb Herby Vojčík <[hidden email]>: >>>>>> >>>>>> With little changes I had not have so many merge problems, but they >>>>>> can >>>>>> always appear as .js is generated. >>>>>> >>>>>> One pragmatic way to solve merge conflicts is to ignore .js >>>>>> conflict(s), >>>>>> solve .st conflict(s), and run `grunt` to recompile those .st files. >>>>> >>>>> I wasn't talking about the js files because I fix the .st files and >>>>> compile >>>>> them to .js as well. But I have huge conflicts in .st. >>>>> >>>>> Norbert >>>>> >>>>>> >>>>>> Norbert Hartl wrote: >>>>>>> We decided to use amber for a few customer projects. The workflow is >>>>>>> quite good and developing web stuff just so much more fun doing it >>>>>>> with >>>>>>> amber than plain javascript. However I cannot say the same for git. >>>>>>> We >>>>>>> are working with three people on the project and the git experience >>>>>>> is >>>>>>> horrible. To be honest I don't fully understand it. Amber just >>>>>>> creates >>>>>>> packages so the possibility of a conflict is very likely. In our >>>>>>> experience the merge is often not automatic but has conflicts. The >>>>>>> sections of the merge are really big and begin sometimes in the >>>>>>> middle >>>>>>> of >>>>>>> a method. >>>>>>> >>>>>>> Has anybody else such an experience. Are there any things to do >>>>>>> additionally in order to help with that? How about a special merge >>>>>>> driver? >>>>>>> >>>>>> >>>>>>> I'm sorry but I'm rather glueless what is the real problem. The only >>>>>>> thing I know is that we loose a lot of code because the merges are >>>>>>> big. >>>>>>> >>>>>>> thanks, >>>>>>> >>>>>>> Norbert >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups >>>>>> "amber-lang" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send >>>>>> an >>>>>> email to [hidden email]. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups >>>>> "amber-lang" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an >>>>> email to [hidden email]. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups >>>> "amber-lang" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an >>>> email to [hidden email]. >>>> For more options, visit https://groups.google.com/d/optout. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups >>> "amber-lang" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an >>> email to [hidden email]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "amber-lang" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [hidden email]. >> For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "amber-lang" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [hidden email]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
> Am 19.05.2015 um 19:07 schrieb H. Hirzel <[hidden email]>: > > I cannot outline the strategy how to deal with it at the moment but > surely it is not a hack if you do it properly. > > It is about project management and design issues. > Are we a little bit vague at the moment? :P Norbert > --HH > > On 5/19/15, Norbert Hartl <[hidden email]> wrote: >> I disagree. Morphing a code base just to satisfy a tool is a bad hack and >> always turns back on you later. A code base should follow architectural >> requirements. To make working feasible you usually tweak the tools to manage >> source code not the code itself. >> >> But having small packages can be both: architectural advisable and amber >> friendly :) >> >> Norbert >> >>> Am 19.05.2015 um 09:06 schrieb H. Hirzel <[hidden email]>: >>> >>> As you write, what you say is a bit vague. It seems to be a project >>> management issue. How to evolve the code base so that the three people >>> can work comparatively independently. >>> >>> --Hannes >>> >>> On 5/19/15, Norbert Hartl <[hidden email]> wrote: >>>> >>>>> Am 18.05.2015 um 23:15 schrieb H. Hirzel <[hidden email]>: >>>>> >>>>> Norbert >>>>> >>>>> Just wondering. How many packages do you have? And you write that 3 >>>>> people are working on the project. How are packages assigned to >>>>> people? >>>>> >>>> We have 4 packages. One for backend code and one for frontend code and >>>> the >>>> corresponding test packages for each. I know we could limit the problem >>>> by >>>> creating more packages. But it wouldn't solve the issue. It is just that >>>> I >>>> find the merge behaviour of git weird because the diff sections are >>>> really >>>> huge. Usually the diff tools are quite good to detect what read differs. >>>> They manage to recognize if code has just been moved and such. And I >>>> know >>>> what I'm saying is a bit vague. I need to dig into that. I just wanted >>>> to >>>> know if there is anything that should be done when using amber with >>>> (!$%#!"%&) git. >>>> >>>> Norbert >>>> >>>>> --Hannes >>>>> >>>>> On 5/18/15, Norbert Hartl <[hidden email]> wrote: >>>>>> >>>>>>> Am 18.05.2015 um 15:15 schrieb Herby Vojčík <[hidden email]>: >>>>>>> >>>>>>> With little changes I had not have so many merge problems, but they >>>>>>> can >>>>>>> always appear as .js is generated. >>>>>>> >>>>>>> One pragmatic way to solve merge conflicts is to ignore .js >>>>>>> conflict(s), >>>>>>> solve .st conflict(s), and run `grunt` to recompile those .st files. >>>>>> >>>>>> I wasn't talking about the js files because I fix the .st files and >>>>>> compile >>>>>> them to .js as well. But I have huge conflicts in .st. >>>>>> >>>>>> Norbert >>>>>> >>>>>>> >>>>>>> Norbert Hartl wrote: >>>>>>>> We decided to use amber for a few customer projects. The workflow is >>>>>>>> quite good and developing web stuff just so much more fun doing it >>>>>>>> with >>>>>>>> amber than plain javascript. However I cannot say the same for git. >>>>>>>> We >>>>>>>> are working with three people on the project and the git experience >>>>>>>> is >>>>>>>> horrible. To be honest I don't fully understand it. Amber just >>>>>>>> creates >>>>>>>> packages so the possibility of a conflict is very likely. In our >>>>>>>> experience the merge is often not automatic but has conflicts. The >>>>>>>> sections of the merge are really big and begin sometimes in the >>>>>>>> middle >>>>>>>> of >>>>>>>> a method. >>>>>>>> >>>>>>>> Has anybody else such an experience. Are there any things to do >>>>>>>> additionally in order to help with that? How about a special merge >>>>>>>> driver? >>>>>>>> >>>>>>> >>>>>>>> I'm sorry but I'm rather glueless what is the real problem. The only >>>>>>>> thing I know is that we loose a lot of code because the merges are >>>>>>>> big. >>>>>>>> >>>>>>>> thanks, >>>>>>>> >>>>>>>> Norbert >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups >>>>>>> "amber-lang" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send >>>>>>> an >>>>>>> email to [hidden email]. >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups >>>>>> "amber-lang" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>>> an >>>>>> email to [hidden email]. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups >>>>> "amber-lang" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an >>>>> email to [hidden email]. >>>>> For more options, visit https://groups.google.com/d/optout. >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups >>>> "amber-lang" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an >>>> email to [hidden email]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "amber-lang" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to [hidden email]. >>> For more options, visit https://groups.google.com/d/optout. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "amber-lang" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [hidden email]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google Groups "amber-lang" group. > To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
Sure. To answer it properly we would need to have a look at the
problem analysis, development cycles, the architecture and design of the project :-) On 5/19/15, Norbert Hartl <[hidden email]> wrote: > >> Am 19.05.2015 um 19:07 schrieb H. Hirzel <[hidden email]>: >> >> I cannot outline the strategy how to deal with it at the moment but >> surely it is not a hack if you do it properly. >> >> It is about project management and design issues. >> > Are we a little bit vague at the moment? :P > > Norbert > >> --HH >> >> On 5/19/15, Norbert Hartl <[hidden email]> wrote: >>> I disagree. Morphing a code base just to satisfy a tool is a bad hack >>> and >>> always turns back on you later. A code base should follow architectural >>> requirements. To make working feasible you usually tweak the tools to >>> manage >>> source code not the code itself. >>> >>> But having small packages can be both: architectural advisable and amber >>> friendly :) >>> >>> Norbert >>> >>>> Am 19.05.2015 um 09:06 schrieb H. Hirzel <[hidden email]>: >>>> >>>> As you write, what you say is a bit vague. It seems to be a project >>>> management issue. How to evolve the code base so that the three people >>>> can work comparatively independently. >>>> >>>> --Hannes >>>> >>>> On 5/19/15, Norbert Hartl <[hidden email]> wrote: >>>>> >>>>>> Am 18.05.2015 um 23:15 schrieb H. Hirzel <[hidden email]>: >>>>>> >>>>>> Norbert >>>>>> >>>>>> Just wondering. How many packages do you have? And you write that 3 >>>>>> people are working on the project. How are packages assigned to >>>>>> people? >>>>>> >>>>> We have 4 packages. One for backend code and one for frontend code and >>>>> the >>>>> corresponding test packages for each. I know we could limit the >>>>> problem >>>>> by >>>>> creating more packages. But it wouldn't solve the issue. It is just >>>>> that >>>>> I >>>>> find the merge behaviour of git weird because the diff sections are >>>>> really >>>>> huge. Usually the diff tools are quite good to detect what read >>>>> differs. >>>>> They manage to recognize if code has just been moved and such. And I >>>>> know >>>>> what I'm saying is a bit vague. I need to dig into that. I just wanted >>>>> to >>>>> know if there is anything that should be done when using amber with >>>>> (!$%#!"%&) git. >>>>> >>>>> Norbert >>>>> >>>>>> --Hannes >>>>>> >>>>>> On 5/18/15, Norbert Hartl <[hidden email]> wrote: >>>>>>> >>>>>>>> Am 18.05.2015 um 15:15 schrieb Herby Vojčík <[hidden email]>: >>>>>>>> >>>>>>>> With little changes I had not have so many merge problems, but they >>>>>>>> can >>>>>>>> always appear as .js is generated. >>>>>>>> >>>>>>>> One pragmatic way to solve merge conflicts is to ignore .js >>>>>>>> conflict(s), >>>>>>>> solve .st conflict(s), and run `grunt` to recompile those .st >>>>>>>> files. >>>>>>> >>>>>>> I wasn't talking about the js files because I fix the .st files and >>>>>>> compile >>>>>>> them to .js as well. But I have huge conflicts in .st. >>>>>>> >>>>>>> Norbert >>>>>>> >>>>>>>> >>>>>>>> Norbert Hartl wrote: >>>>>>>>> We decided to use amber for a few customer projects. The workflow >>>>>>>>> is >>>>>>>>> quite good and developing web stuff just so much more fun doing it >>>>>>>>> with >>>>>>>>> amber than plain javascript. However I cannot say the same for >>>>>>>>> git. >>>>>>>>> We >>>>>>>>> are working with three people on the project and the git >>>>>>>>> experience >>>>>>>>> is >>>>>>>>> horrible. To be honest I don't fully understand it. Amber just >>>>>>>>> creates >>>>>>>>> packages so the possibility of a conflict is very likely. In our >>>>>>>>> experience the merge is often not automatic but has conflicts. The >>>>>>>>> sections of the merge are really big and begin sometimes in the >>>>>>>>> middle >>>>>>>>> of >>>>>>>>> a method. >>>>>>>>> >>>>>>>>> Has anybody else such an experience. Are there any things to do >>>>>>>>> additionally in order to help with that? How about a special merge >>>>>>>>> driver? >>>>>>>>> >>>>>>>> >>>>>>>>> I'm sorry but I'm rather glueless what is the real problem. The >>>>>>>>> only >>>>>>>>> thing I know is that we loose a lot of code because the merges are >>>>>>>>> big. >>>>>>>>> >>>>>>>>> thanks, >>>>>>>>> >>>>>>>>> Norbert >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> You received this message because you are subscribed to the Google >>>>>>>> Groups >>>>>>>> "amber-lang" group. >>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>> send >>>>>>>> an >>>>>>>> email to [hidden email]. >>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups >>>>>>> "amber-lang" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send >>>>>>> an >>>>>>> email to [hidden email]. >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups >>>>>> "amber-lang" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send >>>>>> an >>>>>> email to [hidden email]. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups >>>>> "amber-lang" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an >>>>> email to [hidden email]. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups >>>> "amber-lang" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an >>>> email to [hidden email]. >>>> For more options, visit https://groups.google.com/d/optout. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups >>> "amber-lang" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an >>> email to [hidden email]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "amber-lang" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [hidden email]. >> For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "amber-lang" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [hidden email]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
> Am 19.05.2015 um 19:37 schrieb H. Hirzel <[hidden email]>: > > Sure. To answer it properly we would need to have a look at the > problem analysis, development cycles, the architecture and design of > the project :-) > Thanks for the IT consultant text macro. I used the infamous "we could do it if only the formal definitions were ready" excuse myself a lot. It is totally lame but usually nobody recognizes that. So it turns out to be a strategy that is cheap and effective :) Norbert > On 5/19/15, Norbert Hartl <[hidden email]> wrote: >> >>> Am 19.05.2015 um 19:07 schrieb H. Hirzel <[hidden email]>: >>> >>> I cannot outline the strategy how to deal with it at the moment but >>> surely it is not a hack if you do it properly. >>> >>> It is about project management and design issues. >>> >> Are we a little bit vague at the moment? :P >> >> Norbert >> >>> --HH >>> >>> On 5/19/15, Norbert Hartl <[hidden email]> wrote: >>>> I disagree. Morphing a code base just to satisfy a tool is a bad hack >>>> and >>>> always turns back on you later. A code base should follow architectural >>>> requirements. To make working feasible you usually tweak the tools to >>>> manage >>>> source code not the code itself. >>>> >>>> But having small packages can be both: architectural advisable and amber >>>> friendly :) >>>> >>>> Norbert >>>> >>>>> Am 19.05.2015 um 09:06 schrieb H. Hirzel <[hidden email]>: >>>>> >>>>> As you write, what you say is a bit vague. It seems to be a project >>>>> management issue. How to evolve the code base so that the three people >>>>> can work comparatively independently. >>>>> >>>>> --Hannes >>>>> >>>>> On 5/19/15, Norbert Hartl <[hidden email]> wrote: >>>>>> >>>>>>> Am 18.05.2015 um 23:15 schrieb H. Hirzel <[hidden email]>: >>>>>>> >>>>>>> Norbert >>>>>>> >>>>>>> Just wondering. How many packages do you have? And you write that 3 >>>>>>> people are working on the project. How are packages assigned to >>>>>>> people? >>>>>>> >>>>>> We have 4 packages. One for backend code and one for frontend code and >>>>>> the >>>>>> corresponding test packages for each. I know we could limit the >>>>>> problem >>>>>> by >>>>>> creating more packages. But it wouldn't solve the issue. It is just >>>>>> that >>>>>> I >>>>>> find the merge behaviour of git weird because the diff sections are >>>>>> really >>>>>> huge. Usually the diff tools are quite good to detect what read >>>>>> differs. >>>>>> They manage to recognize if code has just been moved and such. And I >>>>>> know >>>>>> what I'm saying is a bit vague. I need to dig into that. I just wanted >>>>>> to >>>>>> know if there is anything that should be done when using amber with >>>>>> (!$%#!"%&) git. >>>>>> >>>>>> Norbert >>>>>> >>>>>>> --Hannes >>>>>>> >>>>>>> On 5/18/15, Norbert Hartl <[hidden email]> wrote: >>>>>>>> >>>>>>>>> Am 18.05.2015 um 15:15 schrieb Herby Vojčík <[hidden email]>: >>>>>>>>> >>>>>>>>> With little changes I had not have so many merge problems, but they >>>>>>>>> can >>>>>>>>> always appear as .js is generated. >>>>>>>>> >>>>>>>>> One pragmatic way to solve merge conflicts is to ignore .js >>>>>>>>> conflict(s), >>>>>>>>> solve .st conflict(s), and run `grunt` to recompile those .st >>>>>>>>> files. >>>>>>>> >>>>>>>> I wasn't talking about the js files because I fix the .st files and >>>>>>>> compile >>>>>>>> them to .js as well. But I have huge conflicts in .st. >>>>>>>> >>>>>>>> Norbert >>>>>>>> >>>>>>>>> >>>>>>>>> Norbert Hartl wrote: >>>>>>>>>> We decided to use amber for a few customer projects. The workflow >>>>>>>>>> is >>>>>>>>>> quite good and developing web stuff just so much more fun doing it >>>>>>>>>> with >>>>>>>>>> amber than plain javascript. However I cannot say the same for >>>>>>>>>> git. >>>>>>>>>> We >>>>>>>>>> are working with three people on the project and the git >>>>>>>>>> experience >>>>>>>>>> is >>>>>>>>>> horrible. To be honest I don't fully understand it. Amber just >>>>>>>>>> creates >>>>>>>>>> packages so the possibility of a conflict is very likely. In our >>>>>>>>>> experience the merge is often not automatic but has conflicts. The >>>>>>>>>> sections of the merge are really big and begin sometimes in the >>>>>>>>>> middle >>>>>>>>>> of >>>>>>>>>> a method. >>>>>>>>>> >>>>>>>>>> Has anybody else such an experience. Are there any things to do >>>>>>>>>> additionally in order to help with that? How about a special merge >>>>>>>>>> driver? >>>>>>>>>> >>>>>>>>> >>>>>>>>>> I'm sorry but I'm rather glueless what is the real problem. The >>>>>>>>>> only >>>>>>>>>> thing I know is that we loose a lot of code because the merges are >>>>>>>>>> big. >>>>>>>>>> >>>>>>>>>> thanks, >>>>>>>>>> >>>>>>>>>> Norbert >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> You received this message because you are subscribed to the Google >>>>>>>>> Groups >>>>>>>>> "amber-lang" group. >>>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>>> send >>>>>>>>> an >>>>>>>>> email to [hidden email]. >>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>> >>>>>>>> -- >>>>>>>> You received this message because you are subscribed to the Google >>>>>>>> Groups >>>>>>>> "amber-lang" group. >>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>> send >>>>>>>> an >>>>>>>> email to [hidden email]. >>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups >>>>>>> "amber-lang" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send >>>>>>> an >>>>>>> email to [hidden email]. >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups >>>>>> "amber-lang" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>>> an >>>>>> email to [hidden email]. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups >>>>> "amber-lang" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an >>>>> email to [hidden email]. >>>>> For more options, visit https://groups.google.com/d/optout. >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups >>>> "amber-lang" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an >>>> email to [hidden email]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "amber-lang" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to [hidden email]. >>> For more options, visit https://groups.google.com/d/optout. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "amber-lang" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [hidden email]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google Groups "amber-lang" group. > To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
This post was updated on .
In reply to this post by philippeback
They manage to recognize if meizu mx5 buy code has just been moved and such. And I know what I'm saying is a bit vague. I need to dig into that.
|
|
|
This post was updated on .
In reply to this post by philippeback
We decided to use amber for a few customer projects. The workflow is quite good and developing web stuff just so much more fun doing it with amber than plain javascript.meizu mx5 pro However I cannot say the same for git.
|
«
Return to Amber Smalltalk
|
1 view|%1 views
| Free forum by Nabble | Edit this page |