Re: [Git migration] Merge strategy

2018-02-05 Thread Mark Thomas
Thanks for all the input. Consensus appears to be for cherry-picking so I'll update the wiki page accordingly and move onto the next question. Mark On 22/01/18 21:16, Mark Thomas wrote: > The plan when we migrate to git is to migrate to single git repo with > the following branches: > > master

Re: [Git migration] Merge strategy

2018-01-23 Thread Rainer Jung
Am 23.01.2018 um 08:48 schrieb Rémy Maucherat: On Mon, Jan 22, 2018 at 10:16 PM, Mark Thomas wrote: The plan when we migrate to git is to migrate to single git repo with the following branches: master - 9.0.x development tc8.5 - 8.5.x development tc8.0 - 8.0.x development tc7.0 - 7.0.x dev

Re: [Git migration] Merge strategy

2018-01-22 Thread Rémy Maucherat
On Mon, Jan 22, 2018 at 10:16 PM, Mark Thomas wrote: > The plan when we migrate to git is to migrate to single git repo with > the following branches: > > master - 9.0.x development > tc8.5 - 8.5.x development > tc8.0 - 8.0.x development > tc7.0 - 7.0.x development > > We need to decide how we

Re: [Git migration] Merge strategy

2018-01-22 Thread Martin Grigorov
On Mon, Jan 22, 2018 at 10:45 PM, Mark Thomas wrote: > On 22/01/18 21:37, Martin Grigorov wrote: > > Hi Mark, > > > > On Mon, Jan 22, 2018 at 10:16 PM, Mark Thomas wrote: > > > >> The plan when we migrate to git is to migrate to single git repo with > >> the following branches: > >> > >> master

Re: [Git migration] Merge strategy

2018-01-22 Thread jean-frederic clere
On 22/01/18 22:16, Mark Thomas wrote: > 1. Make the change in master and cherry-pick as required to earlier >versions. This is, essentially, what we do now in svn. That is what most of the github "hosted" projects are doing, so +1 for it. Additionally it prevents forgetting fixing master...

Re: [Git migration] Merge strategy

2018-01-22 Thread Violeta Georgieva
2018-01-22 23:16 GMT+02:00 Mark Thomas : > > The plan when we migrate to git is to migrate to single git repo with > the following branches: > > master - 9.0.x development > tc8.5 - 8.5.x development > tc8.0 - 8.0.x development > tc7.0 - 7.0.x development > > We need to decide how we are going t

Re: [Git migration] Merge strategy

2018-01-22 Thread Huxing Zhang
+1 on Option 1. Our internal Tomcat fork has basically the same structure, and we use option 1. I can't find an easy way to implement option 2. On Tue, Jan 23, 2018 at 5:16 AM, Mark Thomas wrote: > The plan when we migrate to git is to migrate to single git repo with > the following branches: > >

Re: [Git migration] Merge strategy

2018-01-22 Thread Mark Thomas
On 22/01/18 21:37, Martin Grigorov wrote: > Hi Mark, > > On Mon, Jan 22, 2018 at 10:16 PM, Mark Thomas wrote: > >> The plan when we migrate to git is to migrate to single git repo with >> the following branches: >> >> master - 9.0.x development >> tc8.5 - 8.5.x development >> tc8.0 - 8.0.x dev

Re: [Git migration] Merge strategy

2018-01-22 Thread Martin Grigorov
Hi Mark, On Mon, Jan 22, 2018 at 10:16 PM, Mark Thomas wrote: > The plan when we migrate to git is to migrate to single git repo with > the following branches: > > master - 9.0.x development > tc8.5 - 8.5.x development > tc8.0 - 8.0.x development > tc7.0 - 7.0.x development > > We need to dec

[Git migration] Merge strategy

2018-01-22 Thread Mark Thomas
The plan when we migrate to git is to migrate to single git repo with the following branches: master - 9.0.x development tc8.5 - 8.5.x development tc8.0 - 8.0.x development tc7.0 - 7.0.x development We need to decide how we are going to handle a fix that applies to multiple versions. I can se