Mercurial and a sort of Continuous Integration workflow for Java project

Question

There is a project in Java where I work.

To have the project in Mercurial I know that I have to make a repository for all the classes.

As there is a lot of classes I think if maybe I can have a copy of a jar made of a copy of the repository plus the modifications I have to do.

So in Mercurial terms there is:

1. A main repo with all the classes
2. A litle repo with modifications and new classes

I want to do merge from B repo to A repo. And then I want to pull and update only the classes (*.java) that exists in my B repo.

I have tried unsuccessfully this:

1. To create B repo I clone A repo and I delete all the files.
2. When I have to modify a .java I do a wget of the particular file the mercurial server in my local machine. When the file is new I just run hg add.
3. To do the commits I do hg commit -I file1 -i file2 ... -i fileN for all the files existing in the working folder of B repo.

Then the unsuccessful part:

1. I can´t do a hg update only of the existing files.
2. When the B repo is merged in A repo it's all ok. But I can't run hg commit of a merged state with -I parameter. Its all or nothing.
3. When I pull from A repo and I try to update I have the same issue 4.

I am aware of hg pull -f for start with a unrelated repo for B repo instead of a clone. But it has the same issue of the update. And it looks pretty ugly.

I think that transplant plugin it may help. I also read this http://stackoverflow.com/questions/12843/how-to-combine-two-projects-in-mercurial.

Preserving the history of files in A Repo is a must, even if this history was generated in B Repo.

Do you know the best way to achieve this?

thanks

Answer 1

What you're looking for is called a Partial Clone and it isn't supported in mercurial.

Honestly, your workflow sounds pretty broken -- creating a subset repo and trying to keep it in sync is fighting against how the tools were intended to be used. Why not just build the jar you need from the full-repo but including only specific classes in the ant (I hope) <jar> tag. We have a repository with thousands of classes and the build all outputs many different jars each of which is a subset of the whole universe of classes.

That said, if you must stick with your current workflow you should modify it. Do not clone the full repository and then delete the files you don't want, because you're still including their full history.

Instead, use hg convert (the Convert Extension) to build your sub-set repository using a filemap and the --filemap option. Using both a source repository type of hg and destination type of hg you can use the filemap to include only the files you want. You'll end up not with a clone, but with a completely new repository, with all the original changesets, but only for the files you've specified. Using convert's built-in incremental mode would make converting only new changes from the full repo possible as a sort of update.