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:
- 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
- martin and hartmut both prefer mercurial, Giovanni did not state yet.
- Python did choose mercurial http://www.python.org/dev/peps/pep-0374/
- Trac supports both as a local repository http://trac.edgewall.org/wiki/PluginList#VersionControlSystems:
- TracMercurial seams to be official part of track
- GitTrac is from trac-hacks. Se we need to push commits from a hoster to the trac instance somehow.
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.
- Maybe interesting to read: <http://ches.nausicaamedia.com/articles/technogeekery/using-mercurial-queues-and-bitbucket-org>
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.
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.
- 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
- change and commit code in local copy
- test code in local copy
- when feature is implemented submit merge request
- review merge request and merge new code into integration branch
- test code in integration branch
- when code is tested in integration - merge code into main (master) branch
- by this step code is considered ready for users of development version
- setup github for win
- setup github for mac
- setup github for linux
- github svn read-only access
- Windows gui clients: msysgit, TortoiseGit
- Mac gui clients: Github client