|
Size: 2413
Comment:
|
Size: 2246
Comment: converted to 1.6 markup
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| ## page was renamed from GlennTarbox/HgDevelopment | |
| Line 8: | Line 9: |
| [[TableOfContents]] | <<TableOfContents>> |
| Line 10: | Line 11: |
| = On Using Hg = | = Developing with DVCS = Distributed Version Control Systems are a huge improvement in the system development process for a number of reasons but its easily researched on Google. So, I'm not going to get into to all the issues. Some thoughts |
| Line 13: | Line 15: |
| Line 14: | Line 17: |
| * Space is discretized into developers * Time is discretized into commits * Add a little meta data linking points in the eveloper / commit Field, throw on some collision free identifiers (SHA-1) and you have the complete genetic history of every line of code * Repositories are a cache and no importance / significance WRT the general abstraction of DVCS * don't forget to push or you might lose some DNA 1. Patching is a degenerate way to use Hg * Based on CVS / SVN when branching and merging were hard * Hg isn't SVN |
|
| Line 23: | Line 18: |
| = Hg for sage-finance and dsageng = | * Space is discretized into developers |
| Line 25: | Line 20: |
| The current model is you only push to your own repo's. For most, this will mean pushing to a repo in your home directory on sage.math. I'll pull revisions / branches into my repo which is, by convention only, the official state for finance and dsageng. | * Time is discretized into commits |
| Line 27: | Line 22: |
| It is critical to push to your public repo often. We'll come up with a naming convention but there will be branches marked as your current working state. You shouldn't merge your working branch into your "ready to merge with ghtdak branch" unless you've checked for collisions with the blessed trunk at a minimum... and it would help if you would check for collisions with my primary working branch. | * Add a little meta data linking points in the developer / commit sequence and you have a graph describing the evolution of the code. Throw on some collision free identifiers (SHA-1) and you have the complete genetic history of every line of code |
| Line 29: | Line 24: |
| To facilitate this process, my repo, can be found at | * Repositories are a cache / detail without significance in and of themselves |
| Line 31: | Line 26: |
| http://tarbox.org:9000 which can be browsed and "pulled" from using hg | * don't forget to push often so others can import your changes |
| Line 33: | Line 28: |
| I'll also clone that repo on sage.math from time to time but thats really only useful for those with accounts there. | 1. Only push to repos you own |
| Line 35: | Line 30: |
| You should read the mercurial docs... but some hints. | * This is probably the least understood aspect of DVCS. The key concept to understand here is that as long as you can get other people's work, you should be pulling and merging from their repos, and only pushing to your own. An example is the repo on your laptop being pushed to '''your repo''' on the server for publishing. |
| Line 37: | Line 32: |
| If you want a clean all by itself repo with all the history from the beginning of time: | * When your repo is published, others can pull / merge / publish. By convention, cerain people's repos, specfically, certain branches on well known repos will have meaning. |
| Line 39: | Line 34: |
| {{{ hg clone http://tarbox.org:9000 sage-ght }}} |
* There are no permissions required which turns version control on its head. You publish your work, make it known (the usual suspects), and it can be pulled by anyone with interest and as part of the process used by a specific project |
| Line 43: | Line 36: |
| remember about branches. Some helpful commands | 1. You are not your code - http://blog.red-bean.com/sussman/?p=96 |
| Line 45: | Line 38: |
| * hg help branches * hg help branch * hg help clone * hg update -C finpatch * figure out how to get hg view to work * hint: get hgk from the mercurial site, adjust your .hgrc * this will likely be part of the sage distro soon enough. |
1. Relevant Videos - on Git but the concepts are explained * http://video.google.com/videoplay?docid=-2199332044603874737&q=&hl=en * http://video.google.com/videoplay?docid=-3999952944619245780 |
| Line 54: | Line 45: |
| CategoryCategory | CategoryDevelopment |
Contents
Developing with DVCS
Distributed Version Control Systems are a huge improvement in the system development process for a number of reasons but its easily researched on Google. So, I'm not going to get into to all the issues. Some thoughts
- There are only branches and revisions.
- Think of code development as a process through time and space.
- Space is discretized into developers
- Time is discretized into commits
- Add a little meta data linking points in the developer / commit sequence and you have a graph describing the evolution of the code. Throw on some collision free identifiers (SHA-1) and you have the complete genetic history of every line of code
- Repositories are a cache / detail without significance in and of themselves
- don't forget to push often so others can import your changes
- Only push to repos you own
This is probably the least understood aspect of DVCS. The key concept to understand here is that as long as you can get other people's work, you should be pulling and merging from their repos, and only pushing to your own. An example is the repo on your laptop being pushed to your repo on the server for publishing.
- When your repo is published, others can pull / merge / publish. By convention, cerain people's repos, specfically, certain branches on well known repos will have meaning.
- There are no permissions required which turns version control on its head. You publish your work, make it known (the usual suspects), and it can be pulled by anyone with interest and as part of the process used by a specific project
You are not your code - http://blog.red-bean.com/sussman/?p=96
- Relevant Videos - on Git but the concepts are explained