TableOfContents

On Using Hg

1. 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
2. Patching is less useful than publishing your repo
   • Much finer grained visibility. Proper branch naming communicate the author's intended state of readiness
   • For developers without a way to publish a repo, patches can be submitted to Trac
     • check the patch for collisions with the "blessed" repo as discussed below
     • the patch will be merged with the repo on a branch depending on its state of testing / modification
3. When a feature is ready for review, an aggregate patch should be assembled and posted on trac consistent with the Sage review process
   • This applies to just the finance and dsageng activities at this early stage. (See below)
   • Adjustments made during review can be posted as patches or, preferably, a branch url indicating the commit. The advantage of the latter is removal of ambiguity should bugs arise later. It becomes straightforward to reconstruct the state of the entire tree for that developer when the upgrade was checked in.

Hg for sage-finance and dsageng

The current model is you 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.

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.

To facilitate this process, my repo, can be found at

http://tarbox.org:9000 which can be browsed and "pulled" from using hg. Its also an easy way to determine if you need to merge or whether I've been asleep...

I'll also clone my repo on sage.math from time to time but thats really only useful for those with accounts on that machine and as a backup / disaster mechanism... of course, as we'll be replicating all the changes amongst ourselves, the implied backup strategy of distributed development is very useful.

You should read the mercurial docs... but some hints.

If you want a clean all by itself repo with all the history from the beginning of time:

hg clone http://tarbox.org:9000 sage-ght

remember about branches. Some helpful commands

• 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.
• hg view is nice but doesn't show branch names... I don't get it... but, fortunately, there's hg glog which makes a pretty nice ascii graph which includes branch info. You need to enable the extension... all documented.

CategoryCategory