Differences between revisions 4 and 5
Revision 4 as of 2012-09-30 22:43:50
Size: 1757
Editor: cpc21-cmbg15-2-0-cust35
Comment:
Revision 5 as of 2012-10-02 21:32:51
Size: 2920
Editor: cpc21-cmbg15-2-0-cust35
Comment:
Deletions are marked like this. Additions are marked like this.
Line 14: Line 14:
The sync extension provides a useful option for users making changes unlikely to conflict with other repository users, for example Technical Authors and Graphical Designers in an otherwise developer-only project. The intended workflow with the tool is: sync, change, commit, sync. The sync extension provides a useful option for users making changes unlikely to conflict with other repository users, for example Technical Authors and Graphical Designers in an otherwise developer-only project. The intended workflow with the tool is: ''sync, change, commit, sync''.
Line 16: Line 16:
The command is made of 3 actions each of which is atomic and dependent on the previous: pull, merge, push. The command is made of 3 actions each of which is atomic and dependent on the previous: pull, update/merge, push.

Which is hopefully more straightforward than the normal:
''pull, change, commit, [pull, merge, push]'' - where the last 3 steps need repeating if you're too slow in pushing.

=== Difference from fetch extension ===
Fetch is designed as an atomic operation. It either succeeds or changes nothing.

Sync is designed from a user workflow perspective. It was intended to be a "do the right thing" button, and as such is not an atomic operation.

For example when you have uncommitted changes:

 * Fetch will immediately bail out, changing nothing.
 * Sync will pull changes from the remote repository, then bail out, having achieved as much as it can without user intervention.

The basic workflow of ''sync, change, commit, sync'' is the same as a fetch.
In fetch, if the user ends up updated to something other than tip, they need to learn an extra thing - how to update.
Sync automatically does the update.
Line 20: Line 37:
This is a non-atomic command such that pulled changes remain if later parts fail. This is a non-atomic command such that pulled changes remain if later parts fail, but any merge attempt is rolled back if the user cancels.
Line 25: Line 42:
Configure your .hgrc file to enable the extension by adding following lines: To use this extension with hg, you need to edit the hg configuration file in: %USERPROFILE%\mercurial.ini or $HOME/.hgrc
Line 27: Line 44:
Enable the extension in Mercurial by adding the following lines (replacing path/to with the appropriate path in both cases):

Sync Extension

This extension is not distributed with Mercurial.

Author: Graham Helliwell Co-author: Chris Moore

Web page: https://bitbucket.org/GrahamHelliwell/hg-sync

Repository: https://bitbucket.org/GrahamHelliwell/hg-sync

Overview

The sync extension provides a useful option for users making changes unlikely to conflict with other repository users, for example Technical Authors and Graphical Designers in an otherwise developer-only project. The intended workflow with the tool is: sync, change, commit, sync. If the command completes, the local and remote repositories will contain the same changesets (except those marked as secret). The command is made of 3 actions each of which is atomic and dependent on the previous: pull, update/merge, push.

Which is hopefully more straightforward than the normal: pull, change, commit, [pull, merge, push] - where the last 3 steps need repeating if you're too slow in pushing.

Difference from fetch extension

Fetch is designed as an atomic operation. It either succeeds or changes nothing.

Sync is designed from a user workflow perspective. It was intended to be a "do the right thing" button, and as such is not an atomic operation.

For example when you have uncommitted changes:

  • Fetch will immediately bail out, changing nothing.
  • Sync will pull changes from the remote repository, then bail out, having achieved as much as it can without user intervention.

The basic workflow of sync, change, commit, sync is the same as a fetch. In fetch, if the user ends up updated to something other than tip, they need to learn an extra thing - how to update. Sync automatically does the update.

Technical Details

The sync command pulls from remote. If there are local-only committed changes, they are merged (and the merge is committed). Then a push is performed. This is a non-atomic command such that pulled changes remain if later parts fail, but any merge attempt is rolled back if the user cancels.

Configuration

To install the extension, first download from the site above, and extract it to a folder where you prefer to keep extensions (e.g. $HOME/hgext) or clone it.

To use this extension with hg, you need to edit the hg configuration file in: %USERPROFILE%\mercurial.ini or $HOME/.hgrc

Enable the extension in Mercurial by adding the following lines (replacing path/to with the appropriate path in both cases):

[extensions]
sync=path/to/sync.py

[tortoisehg]
#The following line is a list of toolbar tool names separated by spaces.
workbench.custom-toolbar = sync

[tortoisehg-tools]
#Define the sync tool
sync.icon = path/to/hg-sync.svg
sync.command = hg sync
sync.label = sync
sync.showoutput = True
sync.tooltip = Pull incoming changes, update/merge and push outgoing changes


CategoryExtensionsByOthers

SyncExtension (last edited 2012-10-02 22:40:37 by cpc21-cmbg15-2-0-cust35)