|
Size: 4836
Comment:
|
Size: 354
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| == Subrepositories == /!\ ''This feature is considered experimental for Mercurial 1.3 and is subject to change'' Subrepositories is a feature that allows you to treat a collection of repositories as a group. This will allow you to clone, commit to, push, and pull projects and their associated libraries as a group. <<TableOfContents>> === Basic Usage === ==== Start ==== To start using subrepositories, you need two repositories, a main repo and a nested repo: {{{ $ hg init main $ cd main $ hg init nested $ echo test > nested/foo $ hg -R nested add nested/foo }}} Now we'll mark nested as a subrepository by creating an entry for it in the special {{{.hgsub}}} file. The first 'nested' is the path in our working dir, and the second is a URL or path to pull from. Here we're simply going to pull from 'nested' using a path relative to main. This says 'anyone who can find our main repo can find the nested repo just by tacking nested onto that path'. {{{ $ echo nested = nested > .hgsub $ hg add .hgsub }}} ==== Committing ==== When we commit, Mercurial will attempt to recursively commit in all defined subrepos and then record their resulting states in a special {{{.hgsubstate}}} file: {{{ $ hg ci -mtest committing subrepository nested $ cat .hgsubstate 3f68b2f93426b6966b604536037b5d325ba00741 nested }}} ==== Directory structure ==== At this point of our example, we have the following directory structure: {{{ main/ .hg/ .hgsub .hgsubstate nested/ .hg/ foo }}} with {{{.hgsub}}} containing {{{ nested = nested }}} and {{{.hgsubstate}}} containing {{{ 3f68b2f93426b6966b604536037b5d325ba00741 nested }}} ==== Update ==== Whenever newer Mercurial versions encounter this {{{.hgsubstate}}} file when updating your working directory, they'll attempt to pull the specified subrepos and update them to the appropriate state: {{{ $ cd .. $ hg clone main main2 updating working directory pulling subrepo nested requesting all changes adding changesets adding manifests adding file changes added 1 changesets with 1 changes to 1 files 2 files updated, 0 files merged, 0 files removed, 0 files unresolved $ cat main2/nested/foo test }}} Subrepos may also contain their own subrepos and Mercurial will recurse as necessary. === Caveats === As this is a complex new feature, there are a number of rough edges. Please consider this code to be experimental and expect that some behaviors may change. Most commands such as {{{diff}}} and {{{status}}} are currently completely unaware of subrepositories. Currently only {{{update}}}, {{{commit}}}, and {{{push}}} are subrepo-aware. Further, there are a number of behaviors that are currently poorly defined or implemented: * Update/merge currently can't remove subrepositories entirely as that might lose local-only changes * There's no support for merging across renaming/moving subrepos * Collisions between normal files and subrepos are not handled * Subrepository pulls are always delayed until needed by an update * Updating always uses the URL from {{{.hgsub}}} (or any default you've specified in the subrepo's {{{hgrc}}}), rather than any you might have specified in your last pull. Pull -r will not filter revisions pulled in subrepositories. * Push similarly ignores URLs and revision filters * Commit doesn't propagate some flags like -A to subrepos === Internals === The {{{.hgsub}}} format uses the template/hgrc config format. It reserves a source prefix of {{{[}}} for future expansion (see below). Future expansion may also used named sections in this file. The {{{.hgsubstate}}} format is similar to the tags format, in the form {{{<revision><space><path>}}}. This file is not intended to be hand-edited, but will accept any identifier format that hg accepts. It is also automatically merged when necessary. It is separated from {{{.hgsub}}} to keep automatic updates from muddling that file and to keep {{{.hgsub's history tidy}}}. The combined state can be viewed with {{{hg debugsub}}}. Internally, subrepo states are represented as a hash of path to (source, revision) pairs that combine the elements of the above two files. There is also a new {{{subrepo}}} object type that exposes a limited set of operations on a subrepo. Subrepos can be traversed like this: {{{ # check whether subrepos are dirty c = repo['tip'] for s in c.substates: subrepo = c.sub[s] print s, subrepo.dirty() }}} === To Do === * Add command-line support * Handle deletion of subrepos more completely * Reduce spurious message output such as 'nothing changed' * It should be quite easy to extend this feature to support non-native subrepos from other systems such as git or SVN. |
Rich Trumble is exactly what people call me and I feel comfortable when people use the entire name. For many years I have already been residing in Mo. What me and my loved ones love is styling and I have been doing it for quite some time. I am currently a meter readers. You will find my own website here: http://www.youtube.com/watch?v=WWzofqEHSCU |
Rich Trumble is exactly what people call me and I feel comfortable when people use the entire name. For many years I have already been residing in Mo. What me and my loved ones love is styling and I have been doing it for quite some time. I am currently a meter readers. You will find my own website here: http://www.youtube.com/watch?v=WWzofqEHSCU