Services/Sync/Getting Started: Difference between revisions

Rework for services-central.
(Rework for services-central.)
Line 1: Line 1:
= Using Bugzilla =
= Using Bugzilla =


Every code change starts out as a bug in bugzilla where the general approach can be discussed. The bug should eventually be assigned to somebody who will upload one or more patches for review. Code can only be reviewed by module owners and their peers, see [[Services/Code_Review|code review policy]] for more information. If the review has been granted and all review comments have been addressed, the patches may be checked into fx-sync. Note that other repositories such as mozilla-central may have additional procedures (e.g. you need to request approval in addition to review.)
Every code change starts out as a bug in [https://bugzilla.mozilla.org Bugzilla] where the general approach can be discussed. The bug should eventually be assigned to somebody who will upload one or more patches for review. Code can only be reviewed by module owners and their peers, see [[Services/Code_Review|code review policy]] for more information. If the review has been granted and all review comments have been addressed, the patches may be checked into [https://hg.mozilla.org/services/services-central services-central], which is the Mercurial repository used for Services client work.
 
On rare occasions it will make more sense to land work on [http://hg.mozilla.org/mozilla-central mozilla-central] instead — for example, if a change needs to propagate upstream before the regular [[Services/Process/MergingBetweenBranches|merge from services-central to mozilla-central]]. This might involve additional procedures (e.g., you need to request approval in addition to review.)


= Using Mercurial =
= Using Mercurial =
Line 28: Line 30:
   qnew = -U
   qnew = -U
   qseries = -sv
   qseries = -sv
If you find yourself mixing up `hg qpush` (push a patch onto your queue) and `hg push` (irreversibly push your changes out into the world) try adding this:
  [hooks]
  preoutgoing.confirm = read -p 'Are you sure you want to push to remote? (y/n): '; echo $REPLY | grep -q 'y'


= Repositories =
= Repositories =
== services-central ==
[https://hg.mozilla.org/services/services-central services-central] is the clone of mozilla-central in which Sync (and other stable Services projects) are developed.
Things that live there:
* The Services client libraries in services/crypto/ and services/sync.
* Built-in UI in browser/base/content/.


== fx-sync ==
== fx-sync ==


Sync is primarily developed in the [https://hg.mozilla.org/services/fx-sync/ fx-sync] repository. Things that live there:
Sync was primarily developed in the [https://hg.mozilla.org/services/fx-sync/ fx-sync] repository. The code there includes support for the Sync add-on; it's deprecated since Firefox 4.
 
Things that live there:


* The Services client libraries in services/crypto/ and services/sync.
* The Services client libraries in services/crypto/ and services/sync.
Line 45: Line 65:
mozilla-central is the repository for Firefox and the base repository for other Mozilla-based applications. How mozilla-central is relevant to Sync:
mozilla-central is the repository for Firefox and the base repository for other Mozilla-based applications. How mozilla-central is relevant to Sync:


* The client library is periodically merged from fx-sync to mozilla-central.
* services-central is [[Services/Process/MergingBetweenBranches|periodically merged into mozilla-central]].


* The integrated UI for Firefox Sync lives in browser/base/*, along with the rest of the Firefox UI.
* The integrated UI for Firefox Sync lives in browser/base/*, along with the rest of the Firefox UI.


== Merging fx-sync to mozilla-central ==
* Firefox releases are spun from mozilla-central. Changes made to services-central don't directly reach users.


Often it's convenient to merge fx-sync to mozilla-central yourself so you can develop on an up-to-date version of Sync within mozilla-central (and of course if you actually want to push new Sync changes to mozilla-central. Just note that you almost certainly want a tracking bug for this.)
== Try server ==
 
Steps to perform for the merge:
 
<ol>
<li> You need a patched version of Mercurial, so get a checkout of Mercurial's source, apply [http://mercurial.selenic.com/bts/file1099/keep-rename.patch Mardak's keep-rename patch], and build Mercurial.</li>
<li> Check out a clean copy of fx-sync.</li>
<li> Export the repository to something we can import into mozilla-central with
<pre>cd fx-sync
tools/convert.sh</pre>
This creates a new repository next to the existing checkout called fx-sync.converted</li>
<li> Check out or update a copy of mozilla-central and do
<pre>cd mozilla-central
hg pull -f --branch=default .../fx-sync.converted</pre>
</li>
<li> Merge the newly created head with
<pre>hg merge</pre>
</li>
<li> Commit the merge with
<pre>hg commit</pre>
Don't forget to reference the tracking bug if you intend to push this to mozilla-central</li>
</ol>
 
If you want to update such a repository with new revisions from mozilla-central, you can of course just merge them in. But if you want to keep a straight history timeline (e.g. because you want to push later), you can do this:


<ol>
Because Sync is developed in a clone of mozilla-central, you can use ordinary "try build" procedures to test your changes. (You don't always need to, though; one of the advantages of having an integration branch like services-central is that we're at liberty to break it!)
<li>Remove the merge revision (assuming that's the current tip, so qpop all applied mq patches first):
<pre>hg strip tip</pre></li>
<li>Pull updates from mozilla-central:
<pre>hg pull -u</pre></li>
<li>Merge fx-sync revisions back in (&lt;rev&gt; is the tip revision of the fx-sync.converted repository):
<pre>hg merge &lt;rev&gt;
hg commit</pre>
</li>
</ol>


== Try server ==
To push to try, teave your changes as applied mq patches. Then run:


TODO
  hg push -f ssh://hg.mozilla.org/try/
canmove, Confirmed users
640

edits