2

I have used ClearCase in the past, as well as subversion, bazaar, mercurial, git, and Team Foundation Server. When I used ClearCase, we used UCM, and one of the features that I really liked was the ability to break out software by components, and set and recommend baselines on those components.

I have a current need for similar functionality. We have a library used on multiple products, but when developers make changes, they are typically working on one product. They may change the interface or functionality that impacts other products, but it is not practical for one developer to integrate and test changes for all products. Rather, I'd like to have that developer do their work on their product, recommend a new baseline, and then when it is appropriate, other developers may pick up the work of integrating the changes to another product.

I would like the VCS to support that workflow. I would like to consider alternatives to ClearCase, if they exist. I'm quite familiar with the "challenges" of implementing ClearCase. I'm not trying to start an opinion piece -- I just want to know if any other VCS supports this functionality (or if anyone has developed their own tools or process to emulate this with another VCS), and how to implement it.

I don't think tags in svn (or equivalent in other VCS offerings) are the answer. In ClearCase, when you recommend a new baseline, it prevented developers from working on the old baseline -- they were forced to rebase, and continue work from the new baseline. I don't know how to force that rebase operation in any other VCS.

I could put the library in its own repo, but that causes other problems. I still need a way to specify (for builds, releases, developer "check outs"), which version/tag/baseline to use, and having this part of the VCS is very useful for tracking purposes.

Patrick
  • 2,243
  • 2
  • 23
  • 32
  • A "software product line management" tool may be able to do this. Also Perforce has a config file when you can ask for different a given verison of each folder and tools to share config file between team members. – Ian Ringrose Jan 14 '14 at 17:16

1 Answers1

2

If you were to implement that with git, you would use:

  • one repository per component
  • a submodule per sha1 you want to recommend, declared in a parent repo.
    The parent repo includes all the submodules you need to work, but it reference them at a precise sha1 (equivalent of the recommended baseline).

See:

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • I would use one repository per component and write a custom tool to setup a development system with the correct version of each component for a given project. I once worked with a system like this build on top of RCS and supported many different product built of about 300 components that were versioned independently of each other. – Ian Ringrose Jan 14 '14 at 17:41
  • @VonC Thanks, I didn't know about git's submodules. I'll do some experimenting, and if it works, I'll mark as the answer. – Patrick Jan 14 '14 at 18:03
  • @Patrick Ok. I have added a few links to my answer, for you to review. – VonC Jan 14 '14 at 20:36