Difference between revisions of "Version Control"

From Dreamwidth Notes
Redirect page
Jump to: navigation, search
(Committing changes)
(Redirected page to Git How To)
 
(47 intermediate revisions by 6 users not shown)
Line 1: Line 1:
The Dreamwidth code uses a [http://www.selenic.com/mercurial/wiki/index.cgi/Tutorial Mercurial] repository.  However, it also uses code that uses different repository systems like [http://www.owlnet.rice.edu/~comp314/svn.html Subversion].  (If you aren't familiar with repositories, [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ here's a good intro].)
+
#REDIRECT [[Git How To]]
 
+
There are currently two separate strategies for editing code, [[#Working with $LJHOME/bin/cvsreport.pl|Working with $LJHOME/bin/cvsreport.pl]] and [[#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:
+
 
+
$LJHOME/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.
+
 
+
If not, you'll have to add this to a file at <tt>~/.hgrc</tt>:
+
 
+
[extensions]
+
hgext.mq =
+
 
+
You might also want to add a username to that file:
+
 
+
[ui]
+
username = foxfirefey <skittisheclipse@gmail.com>
+
 
+
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: (Do this ''before'' you start making the changes!)
+
 
+
hg qnew PATCHNAME
+
 
+
If part of your patch involves creating new files, identify the new files for Mercurial:
+
 
+
hg add relative/path/to/NEWFILE relative/path/to/NEWFILE1 relative/path/to/NEWFILE2&hellip;
+
 
+
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 stack) 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>~/.bash_profile</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'
+
 
+
See [[Dev Maintenance]] for more details.
+
 
+
=== 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 <dwuser>xb95</dwuser> and a few other developers can do this.
+
 
+
For details, see [[Dev Committing Guidelines]]
+
 
+
[[Category: Development]]
+

Latest revision as of 07:38, 21 October 2014