comparison notes/metadata.txt @ 134:22248b34b15a

Add notes on how metadata is stored and recovered. Note that at this point, none of this has actually been implemented. This is documentation of the improved system to be used in the future.
author Augie Fackler <durin42@gmail.com>
date Mon, 01 Dec 2008 11:13:01 -0600
parents
children ba801f44d240
comparison
equal deleted inserted replaced
133:2242dd1163c6 134:22248b34b15a
1 Branches
2 --------
3 In order to handle branches that are not immediate children of /branches/, the
4 following information must be stored in the revmap:
5
6 revision path
7
8 Where path is the actual relative path of the branch in svn. An example, with
9 the previous format for clarification:
10 New | Old
11 3 <hash> trunk | 3 <hash>
12 4 <hash> branches/foo | 4 <hash> foo
13
14 Tags
15 ----
16 Note that if a tag is committed to, we can handle that case by making a branch
17 and then marking it as deleted. The revmap line would look something like this:
18 10 <hash> tags/the_tag
19 And the commit would be done on the hg branch 'modified-tag/the_tag'. Note that
20 if this was 'tags/releases/1.0.0', then the branch would be
21 'modified-tag/releases/1.0.0'.
22
23 Detecting Closing of Branches
24 -----------------------------
25 Subversion users typically remove branches when done with them. This means that
26 if a commit performs a delete operation on the '' path inside a branch, we can
27 be sure that the branch no longer exists. The branch should then be marked as
28 inactive.
29
30 Closing Branches
31 ----------------
32 As of this writing, Mercurial marks branches as inactive by merging them so they
33 have no active heads. In order to mark a branch as closed, the active head on
34 the branch will be used as the first parent of the new changeset, and the second
35 changeset will be either the active head on the hg branch 'closed-branches' or
36 be the nullrev. The commit to mark the branch as inactive will happen on the
37 'closed-branches' branch in Mercurial.
38
39 Recovery
40 --------
41 hgsubversion stores several pieces of essential metadata in .hg/svn/. In order
42 to rebuild this data, the key 'convert_revision' should be stored in the extra
43 dictionary of the converted revision. The key should contain data in the format:
44 'svn:<uuid>/abs/path@<rev>' where <uuid> is the repo UUID, /abs/path is the
45 absolute path to the location the edits were made in Subversion (that is, if it
46 was a trunk commit on /foo/trunk, then /foo/trunk is what gets stored here, even
47 though the project root does not equal the repo root), and <rev> is the revision
48 number of the change in Subversion. This key (and its contents) have been
49 chosen to be compatible with the convert extension so that repos originally
50 converted to hg using convert can be maintained using hgsubversion if desired.
51
52 Tags (tag_info) can be reconstructed by listing the tags directory and then
53 running log on each tag to determine its parent changeset.
54
55 The last revision converted (last_rev) can be converted simply by using the
56 highest revision number encountered while rebuilding the revision map.
57
58 The legacy tag_locations file does not need to be replaced - it will be
59 obsoleted as part of the long-term branch refactor.
60
61 The url will have to be provided by the user. The uuid can be re-requested from
62 the repository.
63
64 branch_info can be rebuilt during the rebuild of the revision map by recording
65 the revisions of all active heads of server-side branches.