Changes

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 fx[https://hg.mozilla.org/services/services-central services-synccentral], which is the Mercurial repository used for Services client work. On rare occasions it will make more sense to land work on [http://hg. Note that other repositories such as mozilla.org/mozilla-central mozilla-central may have ] 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.)

Sync is 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 client library services-central is [[Services/Process/MergingBetweenBranches|periodically merged from fx-sync to into mozilla-central]].

== Merging fx* Firefox releases are spun from mozilla-sync central. Changes made to mozillaservices-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.) 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-synctools/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-centralhg 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:= Try server ==

<ol><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 Because Sync is developed in a clone of mozilla-central:<pre>hg pull -u</pre></li><li>Merge fx-sync revisions back in , you can use ordinary "try build" procedures to test your changes. (&ltYou don't always need to, though;rev&gt; is one of the tip revision advantages of the fxhaving an integration branch like services-sync.converted repositorycentral is that we're at liberty to break it!):<pre>hg merge &lt;rev&gt;hg commit</pre></li></ol>