Question

I've been doing quite a bit of experimenting with the best way to import our Subversion repository into Kiln.

Let's use an example simplified SVN repository structure:

/trunk
    /Core
    /Project1
    /Project2

The goal, from how I understand it, should be for trunk, Core, Project1, and Project2 to all be their own repositories. So I do lots of painstaking work with hg convert, and I end up with a directory structure that matches my Subversion HEAD revision, except there's now a '.hg' folder in the root of all four new repositories.

I push all these into Kiln, 4 different repositories in a single Repository Group. Then I create my .hgsub file for the root of the trunk repository:

Core = https://myhosted.kilnhg.com/Repo/Project/Group/Core
Project1 = https://myhosted.kilnhg.com/Repo/Project/Group/Project1
Project2 = https://myhosted.kilnhg.com/Repo/Project/Group/Project1

Once I add and commit that, and then push it to Kiln, I can do a new clone of the trunk repository and it gets the directory structure of all four repositories in one action. Sweet!

Now comes the problem. I want to make a developer branch repository for me. The way I understand it, if I branch trunk, creating trunk-David, that only branches that repository, and the .hgsub still points to the original Core, Project1, and Project2. If I want to branch globally, I have to branch all four repositories (and in real life, this is more than 4, and there's more than one level of subrepositories desired), then modify the .hgsub file to point to the new urls, and then commit that, just to get started.

That sounds like a LOT of work for something that should conceptually be easy.

So my questions:

• Is there a better way?
• Does my desire to globally branch suggest that I actually shouldn't be using subrepositories at all?
  • It's worth noting that in our shop, everyone edits everything. It's not like there's a Core team who does stuff, and I use the Core library without ever contributing to it. A more accurate description would be that if I'm working on Project1, then I'm going to be making lots of edits to Core and Project1, but probably not modifying anything in Project2, although that's not impossible either.
• Does the Kiln team have anything on the roadmap to support easier handling of branching a subrepository?

Answer 1

You are running into the fact that there is no UI-level support for subrepos, so this is going to be somewhat manual for the time being. The good news is that if you are really just creating developer branches, then this work only needs to be done once for each developer.

Our setup is a bit different than yours. Instead of using developer branches for everything, we have our projects broken out into repository groups (in Kiln's case that's things like backend, website, client tools, Mercurial extensions). In each of those groups we have a Stable, QA, and Devel repository. In general, new features go in Devel (more than one developer might be working out of here at a time) and get pushed to QA when they are ready for testing. QA get's bug fixes and feature tweaks, and Stable basically only gets emergency bug fixes. This works because we have an agile-like development process where we work for some period of time on stuff (features/bugs) and then deploy everything. If something isn't finished, and we simply don't have the time to wait, we might decide to back it out, but that happens pretty infrequently in reality. That's partly because we've gotten good at figuring out when a branch is really needed for something, and partly because our schedules have a good amount of flex if required. In other words, your mileage may vary.

In one case, however, we did have an intern that decided he would rather have all of his stuff in branches, and he went ahead and created branches in each of the repositories that he worked on and created a setup similar to yours. Again, he only really had to do this once.

We don't have a roadmap for supporting sub-repos right now, but it is certainly something worth considering. I will open a case so that we can discuss it.

Answer 2

I recommend that you import into a single repository and use named branches instead of branch repositories. (That's what we did, and it's working well.)

I am in the minority here, but I decided not to drink the branch repository kool-aid, preferring instead to use a single core repository with named branches. While my reasoning was related primarily to the branching model, I feel the sub-repository model has all the same drawbacks and some additional problems of its own. I think breaking an interrelated group of projects into separate repositories destroys much of the benefit of source code control. You no longer have a single, consistent view of the world at any given time. Instead, you have a bunch of independently varying code islands which have to be linked together with manual bubble gum and baling wire (aka tags).

(My other issue with branched repositories is that each one is effectively a hidden head: so all the complexity of branched development still exists, it is simply hidden from you depending on which branch repository you are currently looking at. I prefer to be able to see and manipulate everything in one view. Most groups prefer the simplicity, apparently.)

We have a similar situation to yours, with a fairly large set of interrelated projects being worked on by several developers, without any well-bounded areas of responsibility. Our solution is to use a single core repository and create a new named branch for every feature or bug fix. The developer always leaves the head unmerged. Someone else does a code-review and testing on the new feature, but only merges it back into our default branch once it passes QA. From my perspective, this gives us all the benefits of branch repositories but none of the pain. We don't have to manually manage dependencies outside of the system and broken feature X never prevents us from shipping working feature Y.

Answer 3

Steve,

I'm intrigued with your approach to this issue. Even when using svn externals, I got hit by the kool-aid fairly often: I would make a change to an external library, for Project A, and Project B would break the next time it was updated.

That being said, I don't quite understand your solution. Can you give a concrete, simple example of how you set up the trunks/branches, for, say, 2 projects?

Thank you! Emily

Answer 4

See this other thread - it can be done with relative rather than absolute URLs in your .hgsub (e.g. ../../Libraries/LibraryName).

http://kiln.stackexchange.com/questions/1565/how-do-subrepos-work-with-stable-devel-repositories