|
⇤ ← Revision 1 as of 2015-09-10 11:16:44
Size: 2569
Comment:
|
← Revision 2 as of 2015-09-10 11:18:26 ⇥
Size: 2525
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| #pragma section-numbers 2 | |
| Line 3: | Line 2: |
| Line 9: | Line 7: |
| Line 19: | Line 16: |
| Hgmod acts almost same as native mercurial subrepo feature (and it is built on top of subrepo) differences are: | |
| Line 20: | Line 18: |
| Hgmod acts almost same as native mercurial subrepo feature (and it is built on top of subrepo) differences are: * it store it's config in .hgmod file and it's format is the same as for .hgsub * it store state data in .hgmodstate file * it allows modules (subrepos for hgmod) outside of the repository * it stores state of all modules in root repo |
* it store it's config in .hgmod file and it's format is the same as for .hgsub; * it store state data in .hgmodstate file; * it allows modules (subrepos for hgmod) outside of the repository; * it stores state of all modules in root repo; |
| Line 37: | Line 29: |
| We have many subrepos and many dependencies in our projects. And it's common for us when one project (bunch of repos) depends on more then one project. |
We have many subrepos and many dependencies in our projects. And it's common for us when one project (bunch of repos) depends on more then one project. |
| Line 40: | Line 31: |
| Common case is when we have repo '''D''' (build system for example), repo '''C''' (server side framework), repo '''B''' (client side framework), repo '''A''' some project. Build system is used in both server side and client side frameworks. Server side framework and client side framework can be developed independently and subrepos are OK in that case. |
Common case is when we have repo '''D''' (build system for example), repo '''C''' (server side framework), repo '''B''' (client side framework), repo '''A''' some project. Build system is used in both server side and client side frameworks. Server side framework and client side framework can be developed independently and subrepos are OK in that case. |
| Line 45: | Line 33: |
| But when we begin to develop project '''A''' we need all '''B''', '''C''' and '''D'''. With subrepos we will have three copies of '''D''' and it's not really comfortable. With hgmod we can place all repos in one folder and reference one copy of '''D''' from all three others. |
But when we begin to develop project '''A''' we need all '''B''', '''C''' and '''D'''. With subrepos we will have three copies of '''D''' and it's not really comfortable. With hgmod we can place all repos in one folder and reference one copy of '''D''' from all three others. |
| Line 49: | Line 35: |
| State of '''all''' modules (subrepos) is stored in root repo. We understand that this can make some modules inconsistent at some point (modules revisions stored in subrepo does not correspond to real revisions), but this is not bad. When we're working on project '''A''', we're satisfied with all modules revisions and we don't care about frameworks. But if're working on frameworks we have separate state for frameworks dependencies. |
State of '''all''' modules (subrepos) is stored in root repo. We understand that this can make some modules inconsistent at some point (modules revisions stored in subrepo does not correspond to real revisions), but this is not bad. When we're working on project '''A''', we're satisfied with all modules revisions and we don't care about frameworks. But if're working on frameworks we have separate state for frameworks dependencies. |
| Line 52: | Line 37: |
| This 'feature' also allows us to make '''no''' commits to frameworks (for example) when we make change to build system which is required only for project '''A'''. |
This 'feature' also allows us to make '''no''' commits to frameworks (for example) when we make change to build system which is required only for project '''A'''. |
| Line 62: | Line 46: |
| Line 64: | Line 47: |
HgMod
Yet another way working with subrepos (modules in case of hgmod).
Contents
Status
This extension is not distributed with Mercurial.
Author: Viktor Kuzmin
Repository: https://bitbucket.org/kvaster/hgmod
Web page: https://bitbucket.org/kvaster/hgmod
Overview
Hgmod acts almost same as native mercurial subrepo feature (and it is built on top of subrepo) differences are:
- it store it's config in .hgmod file and it's format is the same as for .hgsub;
- it store state data in .hgmodstate file;
- it allows modules (subrepos for hgmod) outside of the repository;
- it stores state of all modules in root repo;
Hgmod allows to make plain structure of repositories - i.e. all subrepos in one folder
Hgmod allows cross-references in subrepos ( A->B, A->C, B->D, C->D ) without additional copies of subrepo.
Why hgmod ?
We have many subrepos and many dependencies in our projects. And it's common for us when one project (bunch of repos) depends on more then one project.
Common case is when we have repo D (build system for example), repo C (server side framework), repo B (client side framework), repo A some project. Build system is used in both server side and client side frameworks. Server side framework and client side framework can be developed independently and subrepos are OK in that case.
But when we begin to develop project A we need all B, C and D. With subrepos we will have three copies of D and it's not really comfortable. With hgmod we can place all repos in one folder and reference one copy of D from all three others.
State of all modules (subrepos) is stored in root repo. We understand that this can make some modules inconsistent at some point (modules revisions stored in subrepo does not correspond to real revisions), but this is not bad. When we're working on project A, we're satisfied with all modules revisions and we don't care about frameworks. But if're working on frameworks we have separate state for frameworks dependencies.
This 'feature' also allows us to make no commits to frameworks (for example) when we make change to build system which is required only for project A.
Configuration
Configure your .hgrc to enable the extension by adding following lines:
[extensions] hgmod = ~/hgmod.py