Difference between revisions of "Mercurial/Cws"
m |
|||
| Line 67: | Line 67: | ||
$ hg commit -m"foo42: #i4711#: implement feature foo" foo.cxx | $ hg commit -m"foo42: #i4711#: implement feature foo" foo.cxx | ||
| − | {{Template:Documentation/Caution| Remember, ''hg commit'' will search the whole tree for to be committed changes if no file/directory is specified | + | {{Template:Documentation/Caution| Remember, ''hg commit'' will search the whole tree for to be committed changes if no file/directory is specified.}} |
| − | {{Template:Documentation/Note| Why the name of the CWS as first part of the first message line? This way we can immediately see | + | {{Template:Documentation/Note| Why the name of the CWS as first part of the first message line? This way we can immediately see which CWS was the origin of a changeset when browsing the history.}} |
| − | {{Template:Documentation/Tip| Make the first line of your commit message concise and stand alone (like an email subject). This will make for far better browseable history in the long run. See [ http://mercurial.selenic.com/wiki/ChangeSetComments here] why this is so.}} | + | {{Template:Documentation/Tip| Make the first line of your commit message concise and stand alone (like an email subject). This will make for a far better browseable history in the long run. See [http://mercurial.selenic.com/wiki/ChangeSetComments|here] why this is so.}} |
Revision as of 21:24, 25 October 2009
This page discusses the Mercurial part of handling child workspaces (CWSs). It assumes some basic Mercurial knowledge which you can find here.
Contents
Other Mercurial Topics
- Setting up Mercurial
- Migrating existing CVS or SVN based child workspaces to Mercurial
- Using Mercurial with OpenOffice.org: getting started
- Tips and Tricks
The OpenOffice.org repository setup
The OpenOffice.org Mercurial repository is huge, it contains more than 260000 changesets and exceeds 1 GiB in size. Repeatably exchanging this vast numbers of changesets over the Net is prohibitive and wasteful. It's also not necessary. We were careful to employ a setup which is designed to minimize the number of changesets exchanged over the Net. The basic idea is to create a so called 'outgoing' repository for each CWS on the main OOo SCM server. The 'outgoing' repository already has each changeset up to and including the milestone the CWS was created on. It is meant as the main collaboration tool around the child workspace and is also the place where release engineering will fetch a child workspace when it's ready for integration.
Workflow
The workflow is best explained with an example:
Creating the child workspace in EIS
Create child workspace with name foo42, latest available milestone:
$ cws create --hg DEV300 foo42
This command will register CWS foo42 with EIS and set it's SCM property to Mercurial. An 'outgoing' repository will be created (this may take up to one hour) on the SCM server where you can publish your changes.
As an alternative way you can use the EIS web fronted to create the CWS and set it to status 'new'. Don't forget to set the SCM property to 'HG'.
Prepare the your working tree
Method A
Make sure that your local pristine copy contains the latest milestone.
$ cd <local_pristine_copy> $ hg pull http://hg.services.openoffice.org/DEV300
Clone your working tree from the pristine local copy
$ hg clone <local_pristine_copy> foo42
Change the default push location to the OOo SCM server
$ echo 'default-push=ssh://hg@hg.services.openoffice.org/cws/foo42' >> foo42/.hg/hgrc
If there are already changes in the outgoing repository pull them into your working tree
$ cd foo42 $ hg pull -u http://hg.services.openoffice.org/cws/foo42
Method B
If there is a proper $HOME/.cwsrc configuration (see below), you can use the cws fetch command.
$ cws fetch -c foo42 foo42
 |
Make sure that either your local source contains the used milestone *or* the 'outgoing' repository is already available on the server. Otherwise you might base your working tree on an older milestone. If this happened, just do a pull/merge from http://hg.services.openoffice.org/DEV300 |
The cws fetch command adds the default-push location and a hook (prevent the commit of CR/LF in changed files), no need to configure this by hand.
Commit changes
Not much to be said here. Please format the first line of the commit message according to the example below:
$ hg commit -m"foo42: #i4711#: implement feature foo" foo.cxx
|
Remember, hg commit will search the whole tree for to be committed changes if no file/directory is specified. |
