##// 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:

r8821:c66e324d default
r9115:b55d4471 default
Show More
test-convert-cvsnt-mergepoints.out
140 lines | 2.6 KiB | text/plain | TextLexer
/ tests / test-convert-cvsnt-mergepoints.out
% create cvs repository
cvs -f -Q -d *REPO* init
% checkout #1: add foo.txt
cvs -f -Q checkout -d cvsworktmp .
cvs -f -Q add foo
cvs -f -Q add foo.txt
cvs -f ci -f -m add foo.txt foo.txt
initial revision: 1.1
% checkout #2: create MYBRANCH1 and modify foo.txt on it
cvs -f -Q checkout -d cvswork foo
cvs -f -q rtag -b -R MYBRANCH1 foo
cvs -f -Q update -P -r MYBRANCH1
cvs -f ci -f -m bar foo.txt
new revision: 1.1.2.1; previous revision: 1.1
cvs -f ci -f -m baz foo.txt
new revision: 1.1.2.2; previous revision: 1.1.2.1
% create MYBRANCH1_2 and modify foo.txt some more
cvs -f -q rtag -b -R -r MYBRANCH1 MYBRANCH1_2 foo
cvs -f -Q update -P -r MYBRANCH1_2
cvs -f ci -f -m bazzie foo.txt
new revision: 1.1.2.2.2.1; previous revision: 1.1.2.2
% create MYBRANCH1_1 and modify foo.txt yet again
cvs -f -q rtag -b -R MYBRANCH1_1 foo
cvs -f -Q update -P -r MYBRANCH1_1
cvs -f ci -f -m quux foo.txt
new revision: 1.1.4.1; previous revision: 1.1
% merge MYBRANCH1 to MYBRANCH1_1
rcsmerge: warning: conflicts during merge
cvs -f -Q update -P -jMYBRANCH1
RCS file: *REPO*/foo/foo.txt,v
retrieving revision 1.1
retrieving revision 1.1.2.2
Merging differences between 1.1 and 1.1.2.2 into foo.txt
cvs -f ci -f -m merge1+clobber foo.txt
new revision: 1.1.4.2; previous revision: 1.1.4.1
% return to trunk and merge MYBRANCH1_2
cvs -f -Q update -P -A
cvs -f -Q update -P -jMYBRANCH1_2
RCS file: *REPO*/foo/foo.txt,v
retrieving revision 1.1
retrieving revision 1.1.2.2.2.1
Merging differences between 1.1 and 1.1.2.2.2.1 into foo.txt
cvs -f ci -f -m merge2 foo.txt
new revision: 1.2; previous revision: 1.1
collecting CVS rlog
7 log entries
creating changesets
7 changeset entries
---------------------
PatchSet 1
Date:
Author:
Branch: HEAD
Tag: (none)
Branchpoints: MYBRANCH1_1, MYBRANCH1
Log:
foo.txt
Members:
foo.txt:INITIAL->1.1
---------------------
PatchSet 2
Date:
Author:
Branch: MYBRANCH1
Tag: (none)
Parent: 1
Log:
bar
Members:
foo.txt:1.1->1.1.2.1
---------------------
PatchSet 3
Date:
Author:
Branch: MYBRANCH1
Tag: (none)
Branchpoints: MYBRANCH1_2
Parent: 2
Log:
baz
Members:
foo.txt:1.1.2.1->1.1.2.2
---------------------
PatchSet 4
Date:
Author:
Branch: MYBRANCH1_1
Tag: (none)
Parent: 1
Log:
quux
Members:
foo.txt:1.1->1.1.4.1
---------------------
PatchSet 5
Date:
Author:
Branch: MYBRANCH1_2
Tag: (none)
Parent: 3
Log:
bazzie
Members:
foo.txt:1.1.2.2->1.1.2.2.2.1
---------------------
PatchSet 6
Date:
Author:
Branch: HEAD
Tag: (none)
Parents: 1,5
Log:
merge
Members:
foo.txt:1.1->1.2
---------------------
PatchSet 7
Date:
Author:
Branch: MYBRANCH1_1
Tag: (none)
Parents: 4,3
Log:
merge
Members:
foo.txt:1.1.4.1->1.1.4.2