Change tracking for Newmerge
Posted by Andy Singleton on 2011-10-03 02:16
Here are my notes about change tracking for newmerge. I believe that we should make a new file at the root of each branch to hold "merge_history". We should put enough information in this file to recreate
Users must commit before merging. This reduces the number of un-tracked changes in the merge.
Each newmerge command merges to the working copy, which matches a server revision, because it does not contain any uncommitted changes.
There are two forms of the command
1) newmerge <source branch >
2) newmerge <source branch +changeset list> (cherrypick)
We want to keep the complete graph of our merges. I think that we need a data structure that looks something like:
If we want a complete list of the changes in our branch, I think that we need to go to the source branch and get its history. Then, we can go recursively back through the destination and source UUID’s. If we have those UUID’s in our history file, we can stop. If we do not have them, then we need to add their parent nodes to the history file, and then recursively look at the parent nodes. The parent nodes are the nodes where “New revision ID” matches the “Previous revision ID” or “Source ID”.
The history should be in the merge_history file on the source branch, which we can request from the server and examine. This file can get big – it grows with an exponent between 1 and 2 – but I think it will stay small enough to scan in memory, and it can be truncated at at some plausible common ancestor.
TRACKING SPECIFIC COMMITS (CHANGESETS)
I also think that we will need to add commits to this history file. A commit has the same data structure, but without any Source ID, only the new and parent ID’s.
When we apply changes from source during our merge, we will want to commit each changeset separately. This will allow the next person who wants to merge from our branch to get specific changesets.
Yes, it will be slow. However, we can fix that later. We need to make it work, first. As I think about this, I realize that it will require offline commits - the ability to keep changesets in the working copy as we merge. So, we need shelving and offline commits.
This will have an effect on the way that Subversion tracks revisions. Each merged commit or changeset will make a new revision number, often with the same content as a previous revision on a different branch, and the same UUID. We should have a way of identifying these changesets that are the same. We need a field that identifies the revision number. And, the UUID will not always match the revision number.
Users must commit before merging. This reduces the number of un-tracked changes in the merge.
Each newmerge command merges to the working copy, which matches a server revision, because it does not contain any uncommitted changes.
There are two forms of the command
1) newmerge <source branch >
2) newmerge <source branch +changeset list> (cherrypick)
We want to keep the complete graph of our merges. I think that we need a data structure that looks something like:
- new revision UUID
- Previous revision UUID – this is what we just commited
- Source UUID
- Optionally: List of cherrypick changesets
- Optionally: List of tree changes found and used
If we want a complete list of the changes in our branch, I think that we need to go to the source branch and get its history. Then, we can go recursively back through the destination and source UUID’s. If we have those UUID’s in our history file, we can stop. If we do not have them, then we need to add their parent nodes to the history file, and then recursively look at the parent nodes. The parent nodes are the nodes where “New revision ID” matches the “Previous revision ID” or “Source ID”.
The history should be in the merge_history file on the source branch, which we can request from the server and examine. This file can get big – it grows with an exponent between 1 and 2 – but I think it will stay small enough to scan in memory, and it can be truncated at at some plausible common ancestor.
TRACKING SPECIFIC COMMITS (CHANGESETS)
I also think that we will need to add commits to this history file. A commit has the same data structure, but without any Source ID, only the new and parent ID’s.
When we apply changes from source during our merge, we will want to commit each changeset separately. This will allow the next person who wants to merge from our branch to get specific changesets.
Yes, it will be slow. However, we can fix that later. We need to make it work, first. As I think about this, I realize that it will require offline commits - the ability to keep changesets in the working copy as we merge. So, we need shelving and offline commits.
This will have an effect on the way that Subversion tracks revisions. Each merged commit or changeset will make a new revision number, often with the same content as a previous revision on a different branch, and the same UUID. We should have a way of identifying these changesets that are the same. We need a field that identifies the revision number. And, the UUID will not always match the revision number.
Home / Developer API / Tour / Get a Project - Solutions for Bug & Issue Tracking, Collaboration Tools, Subversion Hosting, Git Hosting
Subversion newmerge is powered by Assembla.
0 Comments