Difference between revisions of "Managing Local Changes with Mercurial Queues"
From gem5
(→Repository Management Problem) |
|||
| Line 5: | Line 5: | ||
* If a useful change is added upstream, it's a long, tedious process to update. | * If a useful change is added upstream, it's a long, tedious process to update. | ||
| − | If a user chooses to keep their local repository up-to-date with the source tree they typically use [http://mercurial.selenic.com/wiki/NamedBranches named branches] and merge any upstream changes into their branches. | + | If a user chooses to keep their local repository up-to-date with the source tree they typically use [http://mercurial.selenic.com/wiki/NamedBranches named branches] and merge any upstream changes into their branches. This approach also has its downsides: |
| + | |||
| + | * If any local change needs to be updated, it requires a separate commit. | ||
== Mercurial Queues == | == Mercurial Queues == | ||
Revision as of 17:43, 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 approach has several downsides:
- It discourages users from contributing back any useful changes they may develop.
- If a useful change is added upstream, it's a long, tedious process to update.
If a user chooses to keep their local repository up-to-date with the source tree they typically use named branches and merge any upstream changes into their branches. This approach also has its downsides:
- If any local change needs to be updated, it requires a separate commit.
