11

6

There is plenty on this site advocating the use of subrepos to organize your shared libraries. Also, the prevailing advice is to maintain devel/stable copies (and possibly QA) for your repositories. I see the merits for both ideas, especially in our workflow.

How do these two concepts interact? For example, if I have this:

Application
    .hg/
    .hgsub : Library = http://.../Repo/Library/Stable
    ...

Then both my stable and devel versions of Application would be using the stable library. This makes sense, because when I'm making my application I don't want to be bothered by people making breaking changes to the Library, so I won't see new risky changes being made in Library-Devel until they are tested and pushed to Library-Stable (and someone updates the Application to be using that newer version).

However, what if I'm working on a feature in my App that also requires new development in the Library?

If I change my .hgsub temporarily to point to Library-Devel, then everyone else gets that too. Plus I need to remember to change it back when I push my Library changes to stable.

If I make a feature branch repo off App-Devel then I can change the .hgsub in there without impacting anyone working directly on App-Devel, but I still need to make sure I clean up my .hgsub before pushing back from App-FeatureA to App-Devel.

The other idea I had was to just develop the Library aspect of the new feature in isolation of the App and ensure the tests in the Library repo were sufficient that I could trust them to make my push to Stable safe. However, this isn't reality for a number of our projects and while desirable this change would not happen overnight so isn't an immediate option.

How do other people handle the interaction between the devel/stable paradigm, and subrepos?

flag

3 Answers

6

If I understand your question correctly, we solved this problem by using a relative URL. We use group for develop and a group for stable, so by using ../Library as the URL to the library then the development repo uses the development library and the stable repo uses the stable library.

link|flag
So thinking this through a little more, if I push from my App-Devel to App-Stable, then would I automatically be pushing from Library-Devel to Library-Stable, I guess I would, right? – David Mitchell Jun 10 2010 at 20:01
Yes, however, be aware that when you have a shared library, if you commit from one consumer of the library, the other library consumers do not immediately see those changesets. You have to explicitly pull the changes on the library repo in other consumers. – Darrel Miller Jun 12 2010 at 0:06
0

We handle this issue by using a branch-per-feature development model. We create a separate named branch for each fogbugz case. Only stable tested features are merged back into our default branch. If you require a feature that is not yet verified, you can simply merge that "risky" branch into your new feature branch, without ever disturbing the stable branch or any of your fellow developers.

link|flag
This doesn't really address how the branches interact with subrepos. My understanding of your setup is that you only have a single repo for everything so this wouldn't be a factor for you, correct? – David Mitchell Jun 13 2010 at 4:03
That's correct. We use named branches in situations where most others use separate repositories. We don't have any branch or sub repositories. I was attempting to answer what I interpreted as the root question: "However, what if I'm working on a feature in my App that also requires new development in the Library?" I just wanted to point out for you and others reading this that their is an alternative that, at least in our case, works much better than the repository multiplication approach. – Steve Coffee Jun 13 2010 at 14:49
0

I think Kiln needs to accept relative sub-repo paths, upvote my feature request if you agree: http://kiln.stackexchange.com/questions/3709/relative-subrepo-paths-in-kiln

link|flag

Your Answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.