You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Christian Müller <ch...@gmail.com> on 2012/07/09 21:48:32 UTC
[DISCUSS] force switching from SVN to GIT
I would like to get your opinion about switching from SVN to Git [1].
At this point Git support is pretty stable. All projects that's requested
to be transferred has been switched so far.
What's your preference?
Should we "force" the switch or wait until (at some time) may all projects
are switched?
I'm +1 to force the switch.
[1] https://git-wip-us.apache.org/docs/switching-to-git.html
Best,
Christian
Re: [DISCUSS] force switching from SVN to GIT
Posted by Łukasz Dywicki <lu...@code-house.org>.
So far this thread was sleepy. I would like to back to it and discuss git "flow" we could use.
Currently we have release branches and trunk which is in general big feature branch. There is no issue branches or separate feature branches for different things we would like support. This lack of issue branches leads usage of svnmerge which allows to have substitute of feature branches. For example when 2.8.x have some important bug fix it must be merged from 2.8.x to 2.9.x branch and 2.10.x. In this process we must exclude things designed only for 2.8.x to don't mess up other things.
In this particular case we don't have to track what was or was not merged to camel-2.9.x or camel-2.10.x from trunk because all things we do have separate branches. Every feature should have corresponding JIRA, just like issues. With git (flow) we can have:
master - master branch which contains production versions, it's place where tags are created
develop - (current trunk) main feature branch contains all stable features which was under development
feature/CAMEL-5422 - new stuff to be implemented
release/2.9.x
release/2.10.x
bugfix/CAMEL-5456
If something should go to 2.9.x branch then we simply rebase (or merge) things to develop and then to 2.9. If we would like start branch for 2.11 we simply pick develop and create branch from it. The only thing not described in "A successful Git branching model" is working with multiple release branches, but I believe we can handle that. Main change with git I expect to see is much more branches and much less merges. ;) The less you merge, the better.
Kind regards,
Lukasz Dywicki
--
Code-House
http://code-house.org
Wiadomość napisana przez aedwards w dniu 11 lip 2012, o godz. 16:11:
> +1 for git support, have recently switched on all our internal projects,
> really like Git.
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/DISCUSS-force-switching-from-SVN-to-GIT-tp5715773p5715860.html
> Sent from the Camel Development mailing list archive at Nabble.com.
Re: [DISCUSS] force switching from SVN to GIT
Posted by aedwards <ad...@middleware360.com>.
+1 for git support, have recently switched on all our internal projects,
really like Git.
--
View this message in context: http://camel.465427.n5.nabble.com/DISCUSS-force-switching-from-SVN-to-GIT-tp5715773p5715860.html
Sent from the Camel Development mailing list archive at Nabble.com.
Re: [DISCUSS] force switching from SVN to GIT
Posted by Daniel Kulp <dk...@apache.org>.
On Tuesday, July 10, 2012 04:47:37 PM Łukasz Dywicki wrote:
> I am not sure if svnmerge is needed with git. With svn all informations
> about previous commits are lost after merge on new branch so it's hard to
> get the commits included in merge commit. With git where you have
> multiple branches you just use merge without fast forward. In this case
> issues can be hotfixed on branches, then merged to release branches and
> tagged. With whole nice tree.
Depends on what you are interested in. If all you care about is what HAS
been merged onto a particular branch, sure. The git tracking (or even the
svn tracking that was introduced in 1.6) is fine.
However, I'm more concerned about the list of stuff that has NOT been merged
onto a branch and that's what the svnmerge tracking provides. Basically,
for each commit that isn't merged onto a fixes branch, I'd like to know:
1) Is the commit explicitely not supposed to be on the branch due to it
being a new feature or something that cannot be on that branch.
or
2) If not (1), it's likely that it hasn't been reviewed for inclusion on the
branch. Did the developer forget to merge it back.
Basically, the extra information makes sure fixes get merged onto each of
the branches where they should be and things don't get forgotten or missed.
Dan
>
> Best regards,
> Lukasz
>
> Wiadomość napisana przez Johan Edstrom w dniu 9 lip 2012, o godz. 23:24:
> > I'd be +1 for the offline, branching and commit simplicity as well as a
> > easier merge.>
> > On Jul 9, 2012, at 22:35, Daniel Kulp <dk...@apache.org> wrote:
> >> On Monday, July 09, 2012 09:48:32 PM Christian Müller wrote:
> >>> I would like to get your opinion about switching from SVN to Git [1].
> >>> At this point Git support is pretty stable. All projects that's
> >>> requested
> >>> to be transferred has been switched so far.
> >>>
> >>> What's your preference?
> >>> Should we "force" the switch or wait until (at some time) may all
> >>> projects are switched?
> >>
> >> Well, one issue would be the merge tracking that we do for backporting
> >> would need a major update for a pure git thing. It currently uses
> >> svn properties on the root directory to maintain it's information.
> >> Those are obviously not available in a pure git setup.
> >>
> >> That said, I've thought about moving them out of svn properties and
> >> into a ".mergeinfo" file in the root. I haven't done it as using the
> >> properties maintains compatibility with the svnmerge.py script.
> >> Obviously that script would be irrelevant for pure git. :-)
> >>
> >> Really wouldn't be TOO much work to update my DoMerges script for a
> >> pure git environment and use those files. It already supports a
> >> "git-svn" environment using cherry-pick/commit/push setups (and just
> >> uses a little "svn" to update the properties).
> >>
> >> Dan
> >>
> >>> I'm +1 to force the switch.
> >>>
> >>> [1] https://git-wip-us.apache.org/docs/switching-to-git.html
> >>>
> >>> Best,
> >>> Christian
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: [DISCUSS] force switching from SVN to GIT
Posted by Łukasz Dywicki <lu...@code-house.org>.
I am not sure if svnmerge is needed with git. With svn all informations about previous commits are lost after merge on new branch so it's hard to get the commits included in merge commit. With git where you have multiple branches you just use merge without fast forward. In this case issues can be hotfixed on branches, then merged to release branches and tagged. With whole nice tree.
Best regards,
Lukasz
Wiadomość napisana przez Johan Edstrom w dniu 9 lip 2012, o godz. 23:24:
> I'd be +1 for the offline, branching and commit simplicity as well as a easier merge.
>
>
> On Jul 9, 2012, at 22:35, Daniel Kulp <dk...@apache.org> wrote:
>
>> On Monday, July 09, 2012 09:48:32 PM Christian Müller wrote:
>>> I would like to get your opinion about switching from SVN to Git [1].
>>> At this point Git support is pretty stable. All projects that's requested
>>> to be transferred has been switched so far.
>>>
>>> What's your preference?
>>> Should we "force" the switch or wait until (at some time) may all projects
>>> are switched?
>>
>> Well, one issue would be the merge tracking that we do for backporting would
>> need a major update for a pure git thing. It currently uses svn properties
>> on the root directory to maintain it's information. Those are obviously
>> not available in a pure git setup.
>>
>> That said, I've thought about moving them out of svn properties and into a
>> ".mergeinfo" file in the root. I haven't done it as using the properties
>> maintains compatibility with the svnmerge.py script. Obviously that script
>> would be irrelevant for pure git. :-)
>>
>> Really wouldn't be TOO much work to update my DoMerges script for a pure git
>> environment and use those files. It already supports a "git-svn"
>> environment using cherry-pick/commit/push setups (and just uses a little
>> "svn" to update the properties).
>>
>> Dan
>>
>>
>>
>>
>>
>>>
>>> I'm +1 to force the switch.
>>>
>>> [1] https://git-wip-us.apache.org/docs/switching-to-git.html
>>>
>>> Best,
>>> Christian
>> --
>> Daniel Kulp
>> dkulp@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
Re: [DISCUSS] force switching from SVN to GIT
Posted by Johan Edstrom <se...@gmail.com>.
I'd be +1 for the offline, branching and commit simplicity as well as a easier merge.
On Jul 9, 2012, at 22:35, Daniel Kulp <dk...@apache.org> wrote:
> On Monday, July 09, 2012 09:48:32 PM Christian Müller wrote:
>> I would like to get your opinion about switching from SVN to Git [1].
>> At this point Git support is pretty stable. All projects that's requested
>> to be transferred has been switched so far.
>>
>> What's your preference?
>> Should we "force" the switch or wait until (at some time) may all projects
>> are switched?
>
> Well, one issue would be the merge tracking that we do for backporting would
> need a major update for a pure git thing. It currently uses svn properties
> on the root directory to maintain it's information. Those are obviously
> not available in a pure git setup.
>
> That said, I've thought about moving them out of svn properties and into a
> ".mergeinfo" file in the root. I haven't done it as using the properties
> maintains compatibility with the svnmerge.py script. Obviously that script
> would be irrelevant for pure git. :-)
>
> Really wouldn't be TOO much work to update my DoMerges script for a pure git
> environment and use those files. It already supports a "git-svn"
> environment using cherry-pick/commit/push setups (and just uses a little
> "svn" to update the properties).
>
> Dan
>
>
>
>
>
>>
>> I'm +1 to force the switch.
>>
>> [1] https://git-wip-us.apache.org/docs/switching-to-git.html
>>
>> Best,
>> Christian
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
Re: [DISCUSS] force switching from SVN to GIT
Posted by Daniel Kulp <dk...@apache.org>.
On Monday, July 09, 2012 09:48:32 PM Christian Müller wrote:
> I would like to get your opinion about switching from SVN to Git [1].
> At this point Git support is pretty stable. All projects that's requested
> to be transferred has been switched so far.
>
> What's your preference?
> Should we "force" the switch or wait until (at some time) may all projects
> are switched?
Well, one issue would be the merge tracking that we do for backporting would
need a major update for a pure git thing. It currently uses svn properties
on the root directory to maintain it's information. Those are obviously
not available in a pure git setup.
That said, I've thought about moving them out of svn properties and into a
".mergeinfo" file in the root. I haven't done it as using the properties
maintains compatibility with the svnmerge.py script. Obviously that script
would be irrelevant for pure git. :-)
Really wouldn't be TOO much work to update my DoMerges script for a pure git
environment and use those files. It already supports a "git-svn"
environment using cherry-pick/commit/push setups (and just uses a little
"svn" to update the properties).
Dan
>
> I'm +1 to force the switch.
>
> [1] https://git-wip-us.apache.org/docs/switching-to-git.html
>
> Best,
> Christian
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com