none
Giorgos Keramidas
keramida at ceid.upatras.gr
Thu Jan 20 07:38:52 CST 2011
On Thu, 20 Jan 2011 10:13:44 -0000, "Andy Cunningham" <andrew.cunningham at dai.co.uk> wrote:
> Thanks Martin,
>
> I had seen the subrepository feature, but I'm not sure it really does
> what I want. Mainly there is a strong feeling around here that all
> files in one directory is a good solution. Changing that would
> probably be more trouble than it's worth!
>
> Therefore either way I will probably need to wrap up standard access
> patterns to mercurial in a script. So in that case, I'm not certain I
> would need to link the repositories together.
If you like keeping all the files in the same directory, then maybe you
can use named branches for each 'component', e.g.:
Creating a new 'component' branch, with null-id as its parent:
$ hg up -C null
$ hg branch email-lib
... create email_xxx.[ch] files, e.g. with an editor, copy, etc. ...
$ hg add email_xxx.[ch]
$ hg ci -m 'New email-lib component branch'
Then you can 'pull' snapshots of each component into your 'default'
branch by the merging machinery:
$ hg update -C default
$ hg merge email-lib
A few weeks later, someone decides that email-lib now needs a new
feature, so they update to the 'email-lib' branch, hack a couple of
hours, and commit it:
$ hg update --clean email-lib
... hack, hack ...
$ hg commit -m 'email-lib can now frob the gnat faster'
You can then pull the updated email-lib files into your default branch:
$ hg update --clean default
$ hg merge email-lib
Maybe this is not the perfect solution, but it's probably one of the
easiest ways to keep multiple 'components' with their own separate
'history' in the same repo. What you will be doing is, essentially,
creating and maintaining a 'vendor branch' for each component.
See also:
---------
http://www.selenic.com/pipermail/mercurial/2008-July/020052.html
http://www.selenic.com/pipermail/mercurial/2008-July/020081.html
More information about the Mercurial
mailing list