Responses to CollabNet's pre-summit questionnaire are given below. The respondents are anonymous, but we indicate what business each is in.
What tools you have used previously had merge tracking features, and did you like them? Why or why not?
Perforce. Its "integration" feature works very well at tracking what has been merged between branches. It can merge portions, or entire changelists.
P4 branches suck, but the integrate between them works great because P4 remembers the associations between the trunk and the branch, so it knows how to pair up the files for merging.
What tasks did you use those features for? (Define "merge tracking" as broadly as you need to answer this -- we're more interested in the tasks and how to make them easier than in niceties of categorization.)
We use few development branches, but when we do: the integrate command keeps the branch up to date w.r.t the trunk. The integrate command is also how we bring stuff *back* to the trunk. Since the branch knows that revs N-M were merged onto the branch, it won't try to reapply them to the trunk. You just get your changes brought to trunk.
We also use branches for tracking releases. The integrations bring over all changes from trunk to the release branch. In many cases, we'll cherry pick specific changelists from trunk over to the release branch.
If you have used Subversion, what tasks do you feel would have been easier with merge tracking functionality? What were you trying to accomplish, and how would you have liked Subversion to behave to help you accomplish it?
My work with Subversion has never involved heavy branch work (and my company doesn't use svn).
What version control tools have you had experience with?
CVS, SVN, rcs, Perforce, VSS
What does your organization use branches for? Select all that apply: a) Maintenance/releases b) Experimental efforts c) Customized versions for customers d) Other (describe)
Maintenance/release, and some long-term dev branches. We don't use them for experimental or for customer-specific code.
What is the size of your organization's data set and what is the number of branches in your projects?
Big :-). I know svn can handle our size tho.
Summarize your general branch and development strategy.
See above.
What tools you have used previously had merge tracking features, and did you like them? Why or why not?
ClearCase: Likes: 3-way merge editor; merge info recorded in version tree; graphical display of version tree with merge "hyperlinks"; use labels to identify file sets. Dislikes: works only on single files, not on group of files. Impossible to know what changed between two releases (I needed to create my own tool that analyzed the output of "lsvtree" command).
Perforce: Still learning all the features. I cannot find an easy way to display the branch tree, when a branch was created, when files were merged. So far, I need to look at a lot of (text) history data and create a merge tracking graph by hand. I may need to write my own tool to do this analysis, similar to ClearCase.
What tasks did you use those features for? (Define "merge tracking" as broadly as you need to answer this -- we're more interested in the tasks and how to make them easier than in niceties of categorization.)
Basically I would like to know at a glace which features/fixes are left out of a certain version/subtree. Too many times in ClearCase we had a bug fixed on a branch but not in the main trunk because a merge policy was not enforced. After we started to merge all the hanging branches, the stability of the product improved considerably. We also prevented any engineers except the Architects from checking code into the main trunk, and have an e-mail sent if any non-authorized person attempted to check into the main trunk.
The same for merges from the main trunk to working branches, so that one can know how different is the branch from the main trunk (i.e. how much work it will be to merge it back).
If you have used Subversion, what tasks do you feel would have been easier with merge tracking functionality? What were you trying to accomplish, and how would you have liked Subversion to behave to help you accomplish it?
We used Subversion for a large C++ project with 3 branches alive at any given time. We mostly used the "update" command and automerge before a commit to the same branch. We never automatically merged across branches. All cross-merges were done by hand using a 3rd party tool (Araxis Merge).
I didn't like the graphical representation of the history of a file, which was confusing and almost never useful. Subversion does not record info about merges, so each engineer was forced to do double work: fix a bug on the release branch, and at the same time fix the same bug in the next release (development) branch. This was enforced in order to make sure that no bug fix was only done on the branch and never merged back to main. Because of all of this, we tried to keep the number of branches down to a minimum.
What version control tools have you had experience with?
ClearCase: see above
SourceSafe : Never used for branching/merging, because it was unreliable and sometimes it corrupted the source repository. After finding the corruption/inconsistent state problems we switched to Subversion.
Subversion: see above
CVS
What does your organization use branches for? Select all that apply: a) Maintenance/releases b) Experimental efforts c) Customized versions for customers d) Other (describe)
A,b,c
What is the size of your organization's data set and what is the number of branches in your projects?
Minimal data set is approx. 600Mb (core), but could be much bigger if other components are added (tools, tests etc.)
Summarize your general branch and development strategy.
One main branch tracks the official (public) development of new code. Personal branches are used to implement new features and are subject to periodical merges from the main trunk. When the new feature is ready, it is merged back to the main trunk or possibly to one active release branch.
[Release branches are created when the main trunk is ready for the next release. Release branches receive bug fixes and are these fixes are usually automatically merged to the main trunk.]
What tools you have used previously had merge tracking features, and did you like them? Why or why not?
We currently use ClearCase with UCM. Developers like the graph tool, the simple merging, the adding of merge arrows when an actual merge is not needed, the ability to see where items came from or where thy where merged, and the ability to trace who actually made the change.
It's dog slow and hard to script nicely in order to get a daily view if everything from one branch has been merged to another. Also it is not 100% reliable and has its share of problems.
What tasks did you use those features for? (Define "merge tracking" as broadly as you need to answer this -- we're more interested in the tasks and how to make them easier than in niceties of categorization.)
As a medical device company we have to provide trace-ability on a number of aspects, in order to prove that the final product has been made with consideration of prior products and in a good fashion. This is a lot easier with (almost requires) merge tracking, so that we can trace any change anywhere, know who did it, and when. We also have to maintain code for 10-12 years, which implies a lot of versions and thus a lot of merging, so having merging being as simple as possible is essential.
Merge tracking tasks are:
If you have used Subversion, what tasks do you feel would have been easier with merge tracking functionality? What were you trying to accomplish, and how would you have liked Subversion to behave to help you accomplish it?
What version control tools have you had experience with?
Mainly UCM and base ClearCase.
What does your organization use branches for? Select all that apply: a) Maintenance/releases b) Experimental efforts c) Customized versions for customers d) Other (describe)
A, B, C, and D. For D the main usage is developer branches used as a part of UCM.
What is the size of your organization's data set and what is the number of branches in your projects?
The current data set is about 800-1000 MB and we have about 12 project branches and about 100 developer branches.
Summarize your general branch and development strategy.
The current setup starts with a main archive from which each main project archive is created. The main archive (MIP) is only used to merge the latest project into when a new project needs to be created. The project archives (MIP ?.?V1) are created when the project starts (one new project every half year) and kept alive for as long as 10-12 years depending on customers usage and FDA regulations. On each project branch there are MultiSite ClearCase stream, from which each developer has one or more development streams. When a project decides to make release (first one after half a year and then based on customer demands) a release branch is created (MIP ?.?V1L?). New versions of the project archives (MIP ?.?V?) may be created if needed for customer specific bug fixing and isolation. This policy does not scale and is being avoided.
What tools you have used previously had merge tracking features, and did you like them? Why or why not?
Perforce. My memory is fuzzy, but I remember not being annoyed by it.
What tasks did you use those features for? (Define "merge tracking" as broadly as you need to answer this -- we're more interested in the tasks and how to make them easier than in niceties of categorization.)
Rolling changes from a branch into the mainline.
If you have used Subversion, what tasks do you feel would have been easier with merge tracking functionality? What were you trying to accomplish, and how would you have liked Subversion to behave to help you accomplish it?
I have a branch and a mainline. I want to roll all changes from the branch into the mainline- then I want to come back later and pick up more changes. I don't want to have to think about what I've already done. It would be ideal if I saw the history from the branch appear in the history for the mainline, but that's going over the top a bit. I'd be okay if I ended up with an automatically generated log message that tells me that the guy who did the merge isn't the guy who wrote the code and that I can find the real history for the changes on the branch...
What version control tools have you had experience with?
p4, cvs, vss (*sigh*)
What does your organization use branches for? Select all that apply: a) Maintenance/releases b) Experimental efforts c) Customized versions for customers d) Other (describe)
mostly a, occasionally b
What is the size of your organization's data set and what is the number of branches in your projects?
too many to count.
Summarize your general branch and development strategy.
Our branch strategy is minimize branches and their associated overhead. We create branches only when we have a past tag that needs work or if we really need it for parallel development. Branches are a sometimes neccessary evil. People always have a tendency to make a mess with them. If anything, the most important part of merge tracking is to protect people from themselves. Warn them when they're about to double merge or do something eqally inclined to cause pain.
What tools you have used previously had merge tracking features, and did you like them? Why or why not?
Pretty much just base Rational ClearCase - experimented with UCM a bit (didn't like the posted delivery bit)
Nearly all merge tracking done through the CC merge manager. Some tracking done by running findmerge commands and logging results.
Like the CC merge manager gui and the flexibility of choosing between branch, label or view configuration. Do not like the inability to export data from the merge manager into files (for example to export the list of files merged for a report)
What tasks did you use those features for? (Define "merge tracking" as broadly as you need to answer this -- we're more interested in the tasks and how to make them easier than in niceties of categorization.)
Used the features to first preview potential candidates that would merge between branches and then migrate code changes from branch to branch.
Previews used to:
1) Provide evidence of needed merges so that merge activities could be better planned.
Code migrations used to:
1) provide baselines for new development efforts.
2) Rebase existing development efforts with production changes
If you have used Subversion, what tasks do you feel would have been easier with merge tracking functionality? What were you trying to accomplish, and how would you have liked Subversion to behave to help you accomplish it?
I have not really used Subversion much at all. I did not find it very easy to figure out how to actually do a merge in Subversion - it seemed very cryptic in terms of trying to decide where the start and end points of a merge were. I would like it to be easier to merge from well defined points on a given branch (e.g. merge from a label) and I would like to have reports of everything that actually merged. I would also like the ability to preview a merge, getting a listing of potential merge candidates without having to actually perform a merge (note: CC does this in part but it requires merging of directory elements - this is acceptable to me as I can simply cancel the checkout of the directory elements once a preview has been generated)
What version control tools have you had experience with?
RCS
Rational ClearCase
What does your organization use branches for? Select all that apply: a) Maintenance/releases b) Experimental efforts c) Customized versions for customers d) Other (describe)
How about e) all of the above? We primarily uses branches for a) but we allow for local experiment branches and we reserve the right to branch for a variety of reasons. We look at branches as ways to isolate changes from one another and there are lots of reasons we might want to do that. Our projects and releases tend to be customer oriented so project requirements can differ significantly from one to another.
What is the size of your organization's data set and what is the number of branches in your projects?
Our data set currently consists of 23 ClearCase Vobs, the largest of these is around 15 G. Of these there are several that have multiple branches and are merged with regularity. The largest of these contains approximately 9000 elements and has as many as 4-5 project branches active at any one time (main is not considered a project branch). Each branch represents a single development effort (release) and the same branch type can exist in multiple Vobs. There can be multiple projects that encompass a development effort.
Summarize your general branch and development strategy.
Our general strategy is to have the main branch always represent production code and to branch as much as possible from stable baselines off the main branch. We do allow for cascading when the need arises but we prefer to not let branches get more than two levels deep. New development efforts are given a branch when needed. Once a branch goes into production it is merged to main and any other in-progress development efforts are rebased accordingly. The branch that has gone into production then becomes the "emergency fix" or "patch branch" so that emergency fixes can be made if necessary.