|
|
(61 intermediate revisions by 16 users not shown) |
Line 1: |
Line 1: |
− | The Dreamwidth code uses a [[Mercurial]] repository. However, it also uses code that uses different repository systems like [[subversion]].
| + | #REDIRECT [[Git How To]] |
− | | + | |
− | There are currently two separate strategies for editing code, [[Dev Version Control#Working with $LJHOME/bin/cvsreport.pl|Working with $LJHOME/bin/cvsreport.pl]] and [[Dev Version Control#Using Mercurial|Using Mercurial]].
| + | |
− | | + | |
− | == Checking out the code ==
| + | |
− | | + | |
− | Get the bootstrap script that downloads all of the code:
| + | |
− | | + | |
− | wget http://hg.dwscoalition.org/dw-free/raw-file/tip/bin/bootstrap.pl
| + | |
− | | + | |
− | If your <code>$LJHOME</code> environment variable is set up (see [[Dreamwidth Scratch Installation]] for more information on this), run the script:
| + | |
− | | + | |
− | perl bootstrap.pl
| + | |
− | | + | |
− | Checking out all the various packages and repositories will take some time. Afterwards, you can delete the bootstrap script:
| + | |
− | | + | |
− | rm bootstrap.pl
| + | |
− | | + | |
− | == Working with $LJHOME/bin/cvsreport.pl ==
| + | |
− | | + | |
− | The workhorse that ties all the version control systems of all the code bases together is <code>$LJHOME/bin/cvsreport.pl</code>. With it, you can update to new versions and track changes.
| + | |
− | | + | |
− | Here is a list of the options that come up with <code>bin/cvsreport.pl -help</code>:
| + | |
− | | + | |
− | --help Get this help
| + | |
− | --sync Put files where they need to go.
| + | |
− | All files, unless you specify which ones.
| + | |
− | --diff Show diffs of changed files.
| + | |
− | --cvsonly Don't consider files changed in live dirs.
| + | |
− | --liveonly Don't consider files changed in the CVS dirs.
| + | |
− | --init Copy all files from cvs to main, unconditionally.
| + | |
− | --update Updates files in the CVS dirs from the cvs repositories.
| + | |
− | --justfiles -1 Only output files, not the old -> new arrow. (good for xargs)
| + | |
− | --livelist -ll Output the list of all accounted-for files.
| + | |
− | --which Output the source of the given file
| + | |
− | --these -t Refuse to --sync if no files are specified.
| + | |
− | --map Like --livelist and --which combined.
| + | |
− | --all Overrides --these, allowing --sync to run with no args.
| + | |
− | --print-current-branches -pcb Print repositories and their current branches
| + | |
− | --print-branches -pb Print repositories and their branches.
| + | |
− | --print-repos -pr Print repositories and their resource URLs.
| + | |
− | --print-vars -pv Print configuration variables specified in .conf files.
| + | |
− | --no-space-changes -b Do not display whitespace differences.
| + | |
− | | + | |
− | === Updating to the latest code ===
| + | |
− | | + | |
− | See the [[Dev Maintenance]] article for instructions on this.
| + | |
− | | + | |
− | === Displaying code changes ===
| + | |
− | | + | |
− | This will show all the changes you've made to the code:
| + | |
− | | + | |
− | .$LJHOME/bin/cvsreport.pl -diff
| + | |
− | | + | |
− | You can make a patch by directing this output to a file (see [[Dev Patches]] for more information on patches):
| + | |
− | | + | |
− | $LJHOME/bin/cvsreport.pl -diff > PATCHFILE.
| + | |
− | | + | |
− | Suggested patchfile name should be something along the lines of bug#_desc.patch, like bug56_titlefix.patch.
| + | |
− | | + | |
− | === Reverting changes ===
| + | |
− | | + | |
− | There is unfortunately no <code>.$LJHOME/bin/cvsreport.pl -revert</code>. One way to revert changes is to delete the file with the changes from the live code and then run:
| + | |
− | | + | |
− | bin/cvsreport.pl -sync -cvsonly
| + | |
− | | + | |
− | == Using Mercurial ==
| + | |
− | | + | |
− | === Mercurial Queues ===
| + | |
− | | + | |
− | Mercurial queues is a feature for managing commits as a series of patches. It's good for making local changes that are meant to be temporary, like patches you are working on before submitting them to review/commit. Instead of mixing your commits with the official ones, you can have a series, or queue, of patches which can be applied or unapplied at any time. It's also useful when you're going through files implementing a new feature. While you're doing that, you see typos, bugs, or missing/misleading comments and you need to sort your changes by type.
| + | |
− | | + | |
− | This is useful to make a convient updatable workflow: apply your patches while you are working, unapply before you grab the latest changes to prevent conflict, merge in the updates, then apply your patches again.
| + | |
− | | + | |
− | When you are working with an MQ system, you will be making changes to the code in the <code>$LJHOME/cvs/dw-free</code> directory. To apply and test those changes to the live code, you will need to use <code>$LJHOME/bin/cvsreport.pl</code> to sync. An easy way to do this is to make an alias <code>dwsync</code> command:
| + | |
− | | + | |
− | alias dwsync="$LJHOME/bin/cvsreport.pl --sync --cvsonly"
| + | |
− | | + | |
− | === Starting out ===
| + | |
− | | + | |
− | Check that mercurial queues are enabled on your system with:
| + | |
− | | + | |
− | hg help
| + | |
− | | + | |
− | There should be a section of commands that start with q.
| + | |
− | | + | |
− | To set up MQ for Dreamwidth code, first create a repository to store and keep track of your patches:
| + | |
− | | + | |
− | cd $LJHOME/cvs/dw-free
| + | |
− | hg qinit -c
| + | |
− | | + | |
− | === Working with patches ===
| + | |
− | | + | |
− | To start out with, make sure you are in dw-free:
| + | |
− | | + | |
− | cd $LJHOME/cvs/dw-free
| + | |
− | | + | |
− | Make sure you have no outstanding changes. You can check that you are working with a clean checkout by using <code>hg diff</code> and use <code>hg revert --all</code> to get there if you're willing to lose all the current changes.
| + | |
− | | + | |
− | To make a new patch, use the command:
| + | |
− | | + | |
− | hg qnew PATCHNAME
| + | |
− | | + | |
− | To see what patch is currently on top:
| + | |
− | | + | |
− | hg qtop
| + | |
− | | + | |
− | To add changes to a patch, edit a file and do:
| + | |
− | | + | |
− | hg qrefresh
| + | |
− | | + | |
− | This updates your patch with all your changes. You can change the "commit" message on a patch at the same time you use qrefresh. To see what changes your patch has, use:
| + | |
− | | + | |
− | hg export qtip
| + | |
− | | + | |
− | To see what changes you have made that aren't saved in a patch:
| + | |
− | | + | |
− | hg diff
| + | |
− | | + | |
− | To see what changes your patches has, plus all changes that aren't saved in a patch:
| + | |
− | | + | |
− | hg qdiff
| + | |
− | | + | |
− | === Applying and unapplying patches ===
| + | |
− | | + | |
− | Patches are a stack of patches. Using <code>hg qnew</code> to create a new patch will place it on the top of the stack. You can unapply the patch at the top of the stack (and remove it from the stach) using <code>hg qpop</code>, and apply a patch with <code>hg qpush</code>.
| + | |
− | | + | |
− | See also: [[Dev Patches]]
| + | |
− | | + | |
− | === Updating your code ===
| + | |
− | | + | |
− | Add this alias to your <code>~/.bashprofile</code> and <code>source ~/.bashprofile</code>:
| + | |
− |
| + | |
− | alias dwupdate='hg -R $LJHOME/cvs/dw-free qpop -a && \
| + | |
− | hg -R $LJHOME/cvs/dw-free update && \
| + | |
− | hg -R $LJHOME/cvs/dw-free qpush -a'
| + | |
− | | + | |
− | === Making a patchfile ===
| + | |
− | | + | |
− | You can also use qdiff to make a patch file:
| + | |
− | | + | |
− | hg qdiff > PATCHFILE
| + | |
− | | + | |
− | Suggested patchfile name should be something along the lines of bug#_desc.patch, like bug56_titlefix.patch.
| + | |
− | | + | |
− | === Further MQ References ===
| + | |
− | | + | |
− | * [http://hgbook.red-bean.com/hgbookch12.html#x16-26700012 Managing change with Mercurial Queues]
| + | |
− | * [http://developer.mozilla.org/en/Mercurial_Queues Mercurial Queues]
| + | |
− | | + | |
− | == Committing changes ==
| + | |
− | | + | |
− | Only <ljuser>xb95</ljuser> and a few other developers can do this.
| + | |
− | | + | |
− | For details, see [[Dev Committing Guidelines]]
| + | |
− | | + | |
− | [[Category: Development]]
| + | |