Question

How do you manage common library source in a DVCS?

Currently, my team uses Perforce to manage our software projects. Using Perforce’s “Workspace Mapping” feature, I am able to easily map common library source into dev application directories in a way that keeps the transformation between source management and dev project work transparent. For example, the Repository looks something like this:

---

SCM TREE STRUCTURE

• root
  • apps
    • ForumSite
    • AdminTool
  • common
    • event.logger
    • json.parser
  • db
    • Users
    • SiteConfiguration

Due to the nifty P4 mapping feature, our developers can pull a complete set of source for the projects they work on in the form that makes the most sense using a workspace map. A typical dev project folder might look something like this:

---

DEV PROJECT FOLDER

/projects
    /FALL-2009
        /ForumSite
            /deps
                /event.logger
                /json.parser
        /AdminTool
            /deps
                /event.logger
                /json.parser
        /Users-db
        /SiteConfiguration-db
    /FALL-2009-PATCH-01
        /json.parser
        /SiteConfiguration-db
    /FALL-2009-PATCH-02
        /AdminTool
            /deps
                /event.logger
                /json.parser
        /SiteConfiguration-db

When a dev edits source in any of his/her components or applications, the changes are mapped back to the right source control directory at the right version point. This is transparent to the dev, reducing the complexity of management and time to set up new projects.

I’m researching Git, Bazaar and Mercurial as potential alternatives to Perforce. Can anyone provide insight into how common component source is handled in the DVCS world?

Answer 1

In Git, you would use git submodule for this purpose.

Git submodules are stored as references to a revision from another repository, along with a file providing a URL to find the other repository. When you perform a git submodule update, Git will clone a copy of the referenced repository (or you can configure it to point to a different copy of the same repository at a different URL, as it is a DVCS and so any clone of a repository that contains the referenced revision will also work), and then check out the referenced revision.

Sadly, it is not as seamless as one might wish. Checking out a new revision in the parent repository does not actually check out the submodule; you need to do an explicit git submodule update to accomplish this. We have tried wrapping git pull; git submodule update as a single command, but there are a lot of other commands (such as git rebase) that involve checking out files which can get you into a confusing state because they don’t update the submodules as well. Once you get familiar with how submodules work, it will all work out, but it provides a bit of friction.