Differences between revisions 2 and 3
Revision 2 as of 2015-08-24 22:53:07
Size: 135
Editor: Rain
Comment:
Revision 3 as of 2015-08-24 23:16:10
Size: 945
Editor: Rain
Comment:
Deletions are marked like this. Additions are marked like this.
Line 6: Line 6:
== The Problem == == The (Overall) Problem ==
Line 8: Line 8:
== Use Cases == There should be a lightweight way to transparently sync working copies across repositories in the background. This document covers one part of a proposed implementation.

=== Why would you even want to sync working copies? ===

Imagine that you're working in a local repository and have local changes. At many organizations, to test your changes you would need to sync the contents over to a remote server to e.g. test by sending a small amount of production traffic.

The usual way to do that is to make an explicit commit and push, then have a hook on the server that updates the test repo to that commit.

{{{#!bash
hg commit && hg push test-server -r .
}}}

=== Why not just make real commits on disk and strip them when we're done? ===

That requires that the repository store lock be taken, and

In-Memory Commit Plan

1. The (Overall) Problem

There should be a lightweight way to transparently sync working copies across repositories in the background. This document covers one part of a proposed implementation.

1.1. Why would you even want to sync working copies?

Imagine that you're working in a local repository and have local changes. At many organizations, to test your changes you would need to sync the contents over to a remote server to e.g. test by sending a small amount of production traffic.

The usual way to do that is to make an explicit commit and push, then have a hook on the server that updates the test repo to that commit.

hg commit && hg push test-server -r .

1.2. Why not just make real commits on disk and strip them when we're done?

That requires that the repository store lock be taken, and

2. The Plan

WorkingCopySyncPlan (last edited 2015-08-26 17:34:10 by Rain)