deps: repository dependencies extension
Aleix Conchillo Flaqué
aleix at member.fsf.org
Thu Feb 14 05:05:00 CST 2008
On Feb 14, 2008, at 10:54 AM, Thomas Arendsen Hein wrote:
> Did you look at the forest extension? This looks like a very similar
> use case.
To say the truth, not really. :-) But looking at it now, I am not sure
if its exactly the same, I will look at it deeply. Thanks for pointing
>> + [extensions]
>> + deps =
> I think better "hgext.deps =", though the other will work, too.
>> + [1.0]
>> + f24139319bdb libfoo lib/foo
>> + e296e11a9bc5 libbar lib/bar
>> + [0.9.1]
>> + 3a9b061bada1 libfoo lib/foo
>> + 89b6ae79bc88 libbar lib/bar
> Do I understand correctly?
> [foo] is the current repo's tag or revision and this list says:
> Tag or revision "foo" or children thereof need f24139319bdb (or
> children thereof) of libfoo and e296e11a9bc5 (or children) of libbar
> unless there is another section requiring newer revisions?
[foo] can be anything, but most times will be a tag, and there can be
as many as you want. You can also use another name, like in local tags.
With depsclone you get the revision of external dependencies at
specified time. For example, if I want to restore version 0.9.1 and
its dependencies, I will do:
$ hg clone myptoject
$ hg depsclone 0.9.1
$ hg update -r 0.9.1
Now I can build version 0.9.1 with the correct versions. Of course,
you can update to 0.9.1 and get dependencies of 1.0, but that would
possibly break your build.
> I think the .hgdeps file would only need to have the current set of
> dependencies, if it is part of the repository. This has the added
> benefit that it can be kept up to date between tagged versions.
As I say in the help, you can add dependencies when you want, as tags.
This has the inconvenience, that if you update the repository to a
certain tag, the .hgdeps will not exist, so before updating to that
tag you need to get dependencies first. The right way, would be as you
say, you first update to a tag revision and then you get dependencies.
Another possible feature that a friend of mine told me is to extend
the extension not only to Mercurial repositories, but anything. For
aliases = libfoo
alias.foo = :pserver:anonymous at cvs.savannah.nongnu.org:/sources/scew
alias.foo.command = cvs -z3 -r $TAG -d$SOURCE co $DEST
v1_r2 libfoo lib/foo
The cvs source, tag and destination would be mapped to the command
More information about the Mercurial-devel