Difference between revisions of "Managing Local Changes with Mercurial Queues"
From gem5
| Line 1: | Line 1: | ||
| + | == Repository Management Problem == | ||
gem5 users typically opt to freeze their repository at a particular changeset when starting a new research project. This is understandable because, oftentimes the changes they make for their project aren't likely to be contributed back to the main repository, and keeping the source tree up-to-date is tedious given the speed at which gem5 changes. However, this approach has several downsides: | gem5 users typically opt to freeze their repository at a particular changeset when starting a new research project. This is understandable because, oftentimes the changes they make for their project aren't likely to be contributed back to the main repository, and keeping the source tree up-to-date is tedious given the speed at which gem5 changes. However, this approach has several downsides: | ||
| + | |||
* It discourages users from contributing back useful changes. | * It discourages users from contributing back useful changes. | ||
* If a useful change is added, it's a long, tedious process to update. | * If a useful change is added, it's a long, tedious process to update. | ||
== Mercurial Queues == | == Mercurial Queues == | ||
Revision as of 17:33, 16 February 2013
Repository Management Problem
gem5 users typically opt to freeze their repository at a particular changeset when starting a new research project. This is understandable because, oftentimes the changes they make for their project aren't likely to be contributed back to the main repository, and keeping the source tree up-to-date is tedious given the speed at which gem5 changes. However, this approach has several downsides:
- It discourages users from contributing back useful changes.
- If a useful change is added, it's a long, tedious process to update.
