Bazaar

Strategies for managing history

Asked by Gareth White

Suppose we have a "mainline" branch and a number of development/feature branches that developers do the majority of their work on. As changes are merged to the mainline over time, a lot of revisions will be generated. After a certain amount of time the individual revisions on the dev branches may not really be all that useful - e.g. if a developer committed 20 times to implement a new feature, after a few months all we really care about are the actual changes merged to the mainline. Also, after a year or so we may not even care about some of the revisions on the mainline (unless they went into a release).

Is there some way we could remove these revisions from the repository? The real motivation here is to reduce the time it takes to perform operations which are affected by the repository size, as well as de-cluttering the log (especially qlog).

Alternatively, is there a different workflow we could use that would allow us to better control the amount of history we generate over time? Note that this is within a corporate environment with a requirement that changes are backed up automatically, so we'd probably be using a shared repository on a central server with checkouts on developer machines.

Question information

Language:
English Edit question
Status:
Solved
For:
Bazaar Edit question
Assignee:
No assignee Edit question
Solved by:
Gareth White
Solved:
Last query:
Last reply:
Revision history for this message
Martin Pool (mbp) said : 		#1

Generally speaking we would recommend that you just keep all the history, and rely on bzr's behaviour of showing the mainline as primary and the merged-in revisions as secondary. For example with -n to 'bzr log' you can hide or show the merges; with qbzr you can fold them up (iirc).

If you really want to remove them you can look at bzr-rebase but I wouldn't really recommend that based on what you've said.

This is an interesting case but we don't have any specific plans yet. You're welcome to discuss it on the list.

Revision history for this message
Gareth White (gwhite-deactivatedaccount) said : 		#2

Thanks for the info. I was mainly asking to find out what options were available if we started to find the performance was suffering with lots of history. But based on the testing we've done so far that doesn't look like it'll happen for several years at least, by which time Bazaar will no doubt be faster anyway ;)

qlog does default to showing the merged revisions unexpanded, which makes it a lot more readable than ClearCase's version tree. It might be faster if it didn't fetch all the merged revisions until you expanded one of the nodes but it's not a major problem.