Re: [naviserver-devel] Greetings

[Gustaf N. <ne...@wu...>]

On 09.10.12 23:02, Stephen Deasey wrote:
> On Tue, Oct 9, 2012 at 7:49 PM, Zoran Vasiljevic <zv...@ar...> wrote:
>
>>> Propose
>>> changes on the development list and then make changes to the main
>> This is how we have worked so far. This mostly covers bug fixes.
>> Whole-sale changes are little bit different... but they happen
>> seldom. In that case, a branch consisting of all the changes is
>> prefered.
> Conceptually yes, but don't actually use a mercurial branch for
> temporary development. You can't delete branches.
>
> On your local computer just clone an existing checkout into a new
> directory, it'll use hard links so it's fast and efficient. If you
> want to publish it for feedback then click the 'fork' button on the
> naviserver project at bitbucket and create a new repo under your own
> account: push your changes directly to it. If it's a small change,
> just post it here.
For larger changes (not just cleanup or fixes) feature branches
are the best way. That works nicely and perfectly in our
(git) developents, and keeps a change set focused to a
topic (it's telling a story, as stephen said) while still
being able to improve the change set.

We have not used feature branches with hg/naviserver so
far, but it seems certainly to be a good idea to start with this
Bitbucket advertises the work via via pull requests prominently
in its new web-design

https://bitbucket.org/naviserver/naviserver/pull-requests

Pull requests work with branches and forks
https://confluence.atlassian.com/display/BITBUCKET/Working+with+pull+requests

but it seems the approach with forks is better, since 
conceptually
branches (mercurial calls it named branches) are in 
mercurial thought
to be long-living:

http://stackoverflow.com/questions/6357012/in-mercurial-how-do-i-merge-remove-a-feature-branch-so-i-can-commit

-gustaf neumann