wiki:Development/DiscussDVCS

To have the code on a hosted service is good in following situation:

  • we do not need to worry if somebody has svn write access
  • we would just accept or reject change requests
  • everyone can easily manage his/her changes before submitting patches

Having everyone with it's own branch:

  • this is similar to having people work in svn_trunk/branches on different features but in this case it's a branch per developer not per feature.
  • this would make it easier to integrate changes from others
  • this way the trunk or main branch would be kept more stable and not being the bleeding edge since the code would be more tested in the developer branch.

Decisions to be made

If we are moving from SVN to a DVCS, we need to decide on the following topics:

Repository Design

  • Use named branches or clone branches? Python decided to named branches
  • How much history to keep?
  • Manually slice merges together? This is quite a lot of work, is it worth?
    • What merges you mean to slice?
  • Keep SVN (read-only) for reference?
    • Does it mean the full history won't be preserved?

mercurial vs. git

bitbucket, github or …

  • Do we need an external hoster at all?
    • Would delever.com upgrade to a newer trac if it would meet our requirements?
    • Could a DVCS-Repos at the trac instance efficiently handle pull-requests?
    • With external hosting you don't need to worry about other users having write access. You will only accept or reject pull requests.
  • github has much more features, but do we need them? Really?
  • bitbucked is Australian based while github is US-bases. This may be a difference since e.g. Sourcforge has been forced to exclude some countries from accessing the service.

Integration with out trac instance

  • GitHub supports some notification to external trac services (requires a github-trac-plugin at our trac to receive the messages). hartmut has not yet found this for bitbucket.

Martin wrote:

I would love to have our Trac integrated with git/mercurial the same way as with svn.

I think for start we could start with git/mercurial on a hosting service and from time to time export changes from git/mercurial into current svn.

Votes

giovanni martin hartmut
Which DVCS? git git git
Hoster github github github

Implementation

Hartmut started an migration tool at https://bitbucket.org/htgoebel/pyi-migrate-svn2hg. This is basically a collection of data required for migration plus some wrapper scripts for running the actual migration-tools.


Development Workflow

Branches:

  • main branch'
    • changes merged only from integration branch
    • used by users depending on development PyInstaller? version
  • integration branch (development branch)
    • branch for integrating patches
    • code merged from developers' branches
    • code tested by continuous integration system (jenkins)
  • per developer or per feature branch
  1. change and commit code in local copy
  2. test code in local copy
  3. when feature is implemented submit merge request
  4. review merge request and merge new code into integration branch
  5. test code in integration branch
  6. when code is tested in integration - merge code into main (master) branch
    • by this step code is considered ready for users of development version

http://nvie.com/posts/a-successful-git-branching-model/


Notes

Last modified 3 years ago Last modified on Dec 16, 2011 1:37:04 PM