merging default into stable

[Dmitry Zanozin]

21.01.2010 16:55, venizio krups wrote:
>>
>> I don't think this is a big problem.
>> In distributed development environment we often have a lot
>> of parallel branches. Most of them are unnamed branches
>> within the bounds of default branch.
>> So its quite usual don't have "straight" default branch history.
>> It doesn't matter what kind of objects form the final view of
>> default branch - named or unnamed branches.
>>
>> Dmitry
>>      
> how do you track all the unnamed branches? you eye-ball it? bookmarks?
>    

I mean unnamed branches generated by daily developers commits to their
local repos with the following push changes to main repo (in the evening).
As far as I have not so much developers in my team I eye-ball the
changes one or two times per day.

> we use to eye-ball it, and its a little nerve racking. default/stable
> works well.
>
> i sympathize with adrian's concerns, but after you use this scheme
> coupled with a good visual tool (tortoise's hgtk) it doesn't seem to
> be a big deal. actually the ability to end a branch and re-start it
> later seem like a more powerful way to think about branches.
>
> -venizio
>    

We used the "close-reopen" approach for stable branch before.
I don't like it.
Now we use always-existing default-stable branches pair
for development. All releases are produced from stable branch.
All tags (for releases) are set on stable branch.
By default all my employees commit to default branch until I tell them
to commit particular change to stable branch to produce bugfix
release.
All cross-branch merges I do myself (as team leader).
During development process all merges are from stable to default.
All test builds of future planed release are produced from default branch.
There is the only one merge from default to stable just before
the final release with the following tagging "stable changeset".

Dmitry