Size: 6
Comment:
|
Size: 945
Comment:
|
Deletions are marked like this. | Additions are marked like this. |
Line 1: | Line 1: |
Wat. | #pragma section-numbers 2 = In-Memory Commit Plan = <<TableOfContents>> == 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. === 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 == The Plan == |
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