git branching model
Locked
 
|
I recommend that you read my previous post about the development process depicted in
http://github.com/downloads/nvie/gitflow/Git-branching-model.pdf from this article: http://nvie.com/posts/a-successful-git-branching-model/ But I am interested in observations from other folks.... The model that Vincent describes makes a lot of sense to me and I think that it is a process model that we should provide support for through the MetacelloBrowser ... I'm not looking to model git directly, but several of the features that git provides (which make Vincent's model work in practice) are worth providing. I am very interesting in the notion of branching as depicted in the model. Monticello provides branching support at the package level and Metacello provides branching support from the versioning perspective, but the branching model as depicted is at multiple levels ... It does seem that there is a correlation between symbolic versions and branches that could be exploited more fully or not.... Some other observations: a symbolic version names a branch, and declares version on the head of the branch a single mcz version of a ConfigurationOf package maps to the dots in the diagram the ConfigurationOf package appears to be equivalent to the central origin repo? The biggest technical challenges will probably appear when we try to do automatic merging, but if we have a good branching model, we will know at least what needs to be merged ... Anyway I am interested in hearing what other folks have to say ... I would like to have a brainstorm-style discussions with lots of room for wacky ideas and little room for critical comments ... To me managing branching at the project level is one of the next problems we have to tackle ... Dale
|
|
|
On Apr 16, 2011, at 12:07 PM, Dale Henrichs wrote:
How does one do parallel development that is not tied to a specific version? So we have ongoing development for version '1.0', and I want to create a "automatic_merge" branch that doesn't directly map towards work on any specific production version. Do I create a literal version called 'automatic_merge' and just work within that version? I could use the import: spec to identify a starting version .... Do I branch the configuration itself creating an mcz file branch: ConfigurationOfXXX.automatic_merge-dkh.1? This doesn't seem to be the right direction at all ... it seems like the branches need to be first class objects in Metacello, but maybe those first class objects are versions with funny names? |
|
|
In reply to this post by Dale Henrichs
On Apr 16, 2011, at 12:07 PM, Dale Henrichs wrote:
How do multiple developers make parallel contributions to the same version? Three developers are working in parallel on code that will be contributed to the same production version, so let's say that they all want to branch version 1.0 which is currently open for development. They each may be making parallel changes to the structure of the version 1.0 adding or removing packages to the baseline. They aren't making changes to the same set of packages so collisions aren't the real issue here ... just the mechanics of managing things... In this scenario it feels right (necessary) to branch the configuration: ConfigurationOfXXX.tom-tom.5 ConfigurationOfXXX.dick-dick.5 ConfigurationOfXXX.harry-harry.5 And then someone merges there work back into the main branch ... Is this that different from the "automatic_merge" branch? Maybe not... When the automatic_merge work is ready to be integrated into the main branch, just the code could be brought in and the "automatic_merge" version dropped on the floor... Branching configs at the monticello level means that the noise level of dead ends or intermediate versions could be kept to a minimum in the main configuration... Dale |
|
|
In reply to this post by Dale Henrichs
We will need a patch abstraction and the ability to merge to a patch to a branch.
How #bleedingEdge fits in all that? Will we have #featureBranch, #releaseBranch, #hotfixes. Any plan to rename #stable to #master? Cheers, Alexandre On 16 Apr 2011, at 15:07, Dale Henrichs wrote: > I recommend that you read my previous post about the development process depicted in > > http://github.com/downloads/nvie/gitflow/Git-branching-model.pdf > > from this article: > > http://nvie.com/posts/a-successful-git-branching-model/ > > But I am interested in observations from other folks.... > > The model that Vincent describes makes a lot of sense to me and I think that it is a process model that we should provide support for through the MetacelloBrowser ... > > I'm not looking to model git directly, but several of the features that git provides (which make Vincent's model work in practice) are worth providing. > > I am very interesting in the notion of branching as depicted in the model. > > Monticello provides branching support at the package level and Metacello provides branching support from the versioning perspective, but the branching model as depicted is at multiple levels ... > > It does seem that there is a correlation between symbolic versions and branches that could be exploited more fully or not.... > > Some other observations: > > a symbolic version names a branch, and declares version on the head of the branch > a single mcz version of a ConfigurationOf package maps to the dots in the diagram > the ConfigurationOf package appears to be equivalent to the central origin repo? > > The biggest technical challenges will probably appear when we try to do automatic merging, but if we have a good branching model, we will know at least what needs to be merged ... > > Anyway I am interested in hearing what other folks have to say ... I would like to have a brainstorm-style discussions with lots of room for wacky ideas and little room for critical comments ... > > To me managing branching at the project level is one of the next problems we have to tackle ... > > Dale -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
|
|
At this point in time, I'm not sure whether there is value with tying symbolic versions into the branching model ... there may be value, but I think package-based branching is a better way to go at least from an experimental point of view...
It's tempting to rename #stable, but I want to see where we end up with branching before pulling the trigger on anything:) With my mini experiment this morning of merging changes from 1.59.2 into 1.60 (not much different than merging changes from branch "Issue132" into 1.60, the Monticello merge tools were adequate ... the thing that interests me is that in the absence of conflicts the merges can be done automatically and this is where the big value lies, IMHO ... Dale On Apr 17, 2011, at 5:24 PM, Alexandre Bergel wrote: > We will need a patch abstraction and the ability to merge to a patch to a branch. > How #bleedingEdge fits in all that? Will we have #featureBranch, #releaseBranch, #hotfixes. > Any plan to rename #stable to #master? > > Cheers, > Alexandre > > > On 16 Apr 2011, at 15:07, Dale Henrichs wrote: > >> I recommend that you read my previous post about the development process depicted in >> >> http://github.com/downloads/nvie/gitflow/Git-branching-model.pdf >> >> from this article: >> >> http://nvie.com/posts/a-successful-git-branching-model/ >> >> But I am interested in observations from other folks.... >> >> The model that Vincent describes makes a lot of sense to me and I think that it is a process model that we should provide support for through the MetacelloBrowser ... >> >> I'm not looking to model git directly, but several of the features that git provides (which make Vincent's model work in practice) are worth providing. >> >> I am very interesting in the notion of branching as depicted in the model. >> >> Monticello provides branching support at the package level and Metacello provides branching support from the versioning perspective, but the branching model as depicted is at multiple levels ... >> >> It does seem that there is a correlation between symbolic versions and branches that could be exploited more fully or not.... >> >> Some other observations: >> >> a symbolic version names a branch, and declares version on the head of the branch >> a single mcz version of a ConfigurationOf package maps to the dots in the diagram >> the ConfigurationOf package appears to be equivalent to the central origin repo? >> >> The biggest technical challenges will probably appear when we try to do automatic merging, but if we have a good branching model, we will know at least what needs to be merged ... >> >> Anyway I am interested in hearing what other folks have to say ... I would like to have a brainstorm-style discussions with lots of room for wacky ideas and little room for critical comments ... >> >> To me managing branching at the project level is one of the next problems we have to tackle ... >> >> Dale > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > |
«
Return to Metacello
|
1 view|%1 views
| Free forum by Nabble | Edit this page |