##// END OF EJS Templates
inotify: server: new data structure to keep track of changes....
inotify: server: new data structure to keep track of changes. == Rationale for the new structure == Current structure was a dictionary tree. One directory was tracked as a dictionary: - keys: file/subdir name - values: - for a file, the status (a/r/m/...) - for a subdir, the directory representing the subdir It allowed efficient lookups, no matter of the type of the terminal leaf: for part in path.split('/'): tree = tree[part] However, there is no way to represent a directory and a file with the same name because keys are conflicting in the dictionary. Concrete example: Initial state: root dir |- foo (file) |- bar (file) # data state is: {'foo': 'n', 'bar': 'n'} Remove foo: root dir |- bar (file) # Data becomes {'foo': 'r'} until next commit. Add foo, as a directory, and foo/barbar file: root dir |- bar (file) |-> foo (dir) |- barbar (file) # New state should be represented as: {'foo': {'barbar': 'a'}, 'bar': 'n'} however, the key "foo" is already used and represents the old file. The dirstate: D foo A foo/barbar cannot be represented, hence the need for a new structure. == The new structure == 'directory' class. Represents one directory level. * Notable attributes: Two dictionaries: - 'files' Maps filename -> status for the current dir. - 'dirs' Maps subdir's name -> directory object representing the subdir * methods - walk(), formerly server.walk - lookup(), old server.lookup - dir(), old server.dir This new class allows embedding all the tree walks/lookups in its own class, instead of having everything mixed together in server. Incidently, since files and directories are not stored in the same dictionaries, we are solving the previous key conflict problem. The small drawback is that lookup operation is a bit more complex: for a path a/b/c/d/e we have to check twice the leaf, if e is a directory or a file.

File last commit:

r8249:2c7c973c default
r9115:b55d4471 default
Show More
test-convert-cvs-synthetic.out
136 lines | 2.9 KiB | text/plain | TextLexer
/ tests / test-convert-cvs-synthetic.out
% create cvs repository with one project
cvs -f -d *REPO* init
cvs -f -q co proj
% create file1 on the trunk
cvs -f -Q add file1
cvs -f ci -madd file1 on trunk file1
% create two branches
cvs -f -q tag -b v1_0
T file1
cvs -f -q tag -b v1_1
T file1
% create file2 on branch v1_0
cvs -f -Q up -rv1_0
cvs -f -Q add file2
cvs -f ci -madd file2 file2
% create file3, file4 on branch v1_1
cvs -f -Q up -rv1_1
cvs -f -Q add file3 file4
cvs -f ci -madd file3, file4 on branch v1_1 file3 file4
% merge file2 from v1_0 to v1_1
cvs -f -Q up -jv1_0
cvs -f ci -mMERGE from v1_0: add file2
% create branch v1_2
cvs -f -Q up -A
cvs -f -q tag -b v1_2
T file1
% create file5 on branch v1_2
cvs -f -Q up -rv1_2
cvs -f ci -madd file5 on v1_2
% create file6 on trunk post-v1_2
cvs -f -Q up -A
cvs -f -Q add file6
cvs -f ci -madd file6 on trunk post-v1_2
% merge file5 from v1_2 to trunk
cvs -f -Q up -A
cvs -f -Q up -jv1_2 file5
cvs -f ci -mMERGE from v1_2: add file5
% merge file6 from trunk to v1_2
cvs -f -Q up -rv1_2
cvs -f up -jHEAD file6
U file6
cvs -f ci -mMERGE from HEAD: add file6
% cvs rlog output
RCS file: *REPO*/proj/file1,v
revision 1.1
RCS file: *REPO*/proj/Attic/file2,v
revision 1.1
revision 1.1.4.2
revision 1.1.4.1
revision 1.1.2.1
RCS file: *REPO*/proj/Attic/file3,v
revision 1.1
revision 1.1.2.1
RCS file: *REPO*/proj/Attic/file4,v
revision 1.1
revision 1.1.2.1
RCS file: *REPO*/proj/file5,v
revision 1.2
revision 1.1
revision 1.1.2.1
RCS file: *REPO*/proj/file6,v
revision 1.1
revision 1.1.2.2
revision 1.1.2.1
% convert to hg (#1)
initializing destination proj.hg repository
connecting to *REPO*
scanning source...
using builtin cvsps
collecting CVS rlog
15 log entries
creating changesets
8 changeset entries
sorting...
converting...
7 add file1 on trunk
6 add file2
5 add file3, file4 on branch v1_1
4 MERGE from v1_0: add file2
3 add file5 on v1_2
2 add file6 on trunk post-v1_2
1 MERGE from v1_2: add file5
0 MERGE from HEAD: add file6
% hg glog output (#1)
o 7 MERGE from HEAD: add file6
|
| o 6 MERGE from v1_2: add file5
| |
| o 5 add file6 on trunk post-v1_2
| |
o | 4 add file5 on v1_2
|/
| o 3 MERGE from v1_0: add file2
| |
| o 2 add file3, file4 on branch v1_1
|/
| o 1 add file2
|/
o 0 add file1 on trunk
% convert to hg (#2: with merge detection)
initializing destination proj.hg2 repository
connecting to *REPO*
scanning source...
using builtin cvsps
collecting CVS rlog
15 log entries
creating changesets
8 changeset entries
sorting...
converting...
7 add file1 on trunk
6 add file2
5 add file3, file4 on branch v1_1
4 MERGE from v1_0: add file2
3 add file5 on v1_2
2 add file6 on trunk post-v1_2
1 MERGE from v1_2: add file5
0 MERGE from HEAD: add file6
% hg glog output (#2)
o 7 MERGE from HEAD: add file6
|\
| o 6 MERGE from v1_2: add file5
| |
| o 5 add file6 on trunk post-v1_2
| |
o | 4 add file5 on v1_2
|/
| o 3 MERGE from v1_0: add file2
| |\
+---o 2 add file3, file4 on branch v1_1
| |
| o 1 add file2
|/
o 0 add file1 on trunk