Size: 135
Comment:
|
Size: 945
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
Contents
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