Sharing files in a managed approach between hg repos.

Hello,

Problem: One hg repository has a file I want to update & maintain in another hg repository, and I do not want to copy & paste. I do want to have the file available in both repos.

Scenario:

Working on Product 0001

Project A has an hg repository.

Down the road, a Project B is spun up. There is largely no coupling between Project A and B, but there are some files that could be shared.

Version controlling files in a managed approach is critical: copy & pasting is not a viable solution.

There are some solutions that may work -

Merging both repos into a product repo. But, this means the version numbers for a set of files will be changing due to churn elsewhere. Plus, the different projects aren't terribly related.
Convert both into a subrepo. I am not sure this is the right approach, subrepos seem to have some funky behavior relating with the parent repo. (Or they used to?)

Extending this issue is the concept of sharing certain files between Products. Somehow, a file needs to be shared and correctly tracked as being a singular file, but in two different Products.

The general problem might be stated as this -

Given a set of products, each with their own repository, under development which share and develop upon files living in each other's repositories (think utility routines and frameworks), what is the hg solution to maintaining file-version consistently between products.

What is a good solution here?

Your second call is correct. You should extract the files that would be in both repositories and make that a third repo, which you in turn make a sub repo for each of project A and project B.

I don't know when you first looked at subrepos, but they've been around for a year now and are supported quite well.

Read a few of the subrepo related answers here on stack overflow, make sure to make your subrepo paths relative (not absolute w/ http:// etc.) in them and they'll treat you very well.

Update:

Today's 1.7 release of mercurial includes these enhancements for subrepos:

support remapping of subrepository source paths (see [subpaths] in hgrc(5))
make add, diff, incoming, outgoing and status commands recurse into subrepos with --subrepos/-S
subrepo: add support for 'hg archive'
subrepo: fix status check on SVN subrepos (issue2445)

http://mercurial.selenic.com/wiki/Subrepositories says that diff and status are ignorant of subrepos. Further, http://mercurial.selenic.com/wiki/SubrepoWork suggests that subrepos are seriously still in the "half-baked" stage.

Paul Nathan 2010-10-25 21:58:40

That means diff and status don't descend down into your subrepositories, but that's seldom what one actually wants and will never be the default. Subrepos are being used extensively in many organizations and they'll only grow. Sun built the NetBeans repos atop the ForestExtension, which was always against advice, but subrepos are here to stay and ready for prime time.

Ry4an 2010-10-26 01:42:07

@Ry4an: I'm not convinced that non-recursive diff and status aren't what I want.

Paul Nathan 2010-10-26 14:28:23

fair enough. The goal is to be developing against a fixed revision of the subrepo, not against its tip -- the subrepo is for ease-of-update, not co-development. Still I've seen people create an alias like: `rdiff = for therepo in $(find $(hg root) -type d -name .hg | xargs -l dirname) ; do hg --repository $therepo diff ; done` which would provide recursive diff (or status or outgoing) and is easy enough if you're in to that sort of thing.

Ry4an 2010-10-26 16:15:53

@R4yan: Co-development is, indeed, the goal here. Imagine your products all being under continual development constantly, with multiple shared codebases....

Paul Nathan 2010-10-27 23:35:26

Paul, even in that case most folks consider having a continous integration server that's squeezing of a built/tagged release every day, hour or commit and building against that to be best practice. You always want to be able to say 'this binary was built against library version 2010.10.27.0029' not 'this binary was built against whatever was in my current working directory. If you set your workflow up like that you get all the flexibility concurrent development with all the rigor of building against identifiable releases.

Ry4an 2010-10-28 02:09:12

ansaurus

tags:

views:

answers:

Sharing files in a managed approach between hg repos.

related questions