/[meta-cvs]/meta-cvs/F-54B5FF01DC6392F28A104A8A58761CB6
ViewVC logotype

Diff of /meta-cvs/F-54B5FF01DC6392F28A104A8A58761CB6

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.10 by kaz, Tue Jun 25 05:26:03 2002 UTC revision 1.10.6.2 by kaz, Wed Feb 4 07:48:52 2004 UTC
# Line 1  Line 1 
1                    Meta-CVS --- A Directory Structure                         Meta-CVS --- A Directory Structure
2                           Versioning Layer Over                               Versioning Layer Over
3                       The Concurrent Versions System.                          The Concurrent Versions System.
4    
5                                Kaz Kylheku                                    Kaz Kylheku
6                              January 25, 2002                       Originally published January 25, 2002
7                          Edited and Revised February 3, 2004
8    
9    
10         "Directory versioning is a Hard Problem" -- Subversion FAQ             "Directory versioning is a Hard Problem" -- Subversion FAQ
11    
12            "Any problem in computer science can be solved with                "Any problem in computer science can be solved with
13               another layer of indirection" -- David Wheeler                   another layer of indirection" -- David Wheeler
14    
15    
16    Abstract    Abstract
# Line 31  Line 32 
32    
33      1. Introduction  . . . . . . . . . . . . . . . . . . . . . . Line 42      1. Introduction  . . . . . . . . . . . . . . . . . . . . . . Line 42
34      2. Data Representation Overview . . . . . . . . . . . . . . . . . 75      2. Data Representation Overview . . . . . . . . . . . . . . . . . 75
35          2.1 File Mapping Example . . . . . . . . . . . . . . . . . . 120          2.1 File Mapping Example . . . . . . . . . . . . . . . . . . 120
36          2.2 Synchronization . . . . . . . . . . . . . . . . . . . .  210          2.2 Symbolic links  . . . . . . . . . . . . . . . . . . . .  210
37            2.3 Synchronization  . . . . . . . . . . . . . . . . . . . . 210
38            2.4 Partial Sandboxes . . . . . . . . . . . . . . . . . . .  210
39      3. Surprising Advantages . . . . . . . . . . . . . . . . . . . . 247      3. Surprising Advantages . . . . . . . . . . . . . . . . . . . . 247
40          3.1 File Adding conflicts . . . . . . . . . . . . . . . . .  260          3.1 File Adding conflicts . . . . . . . . . . . . . . . . .  260
41          3.2 File Removal conflicts . . . . . . . . . . . . . . . . . 286          3.2 File Removal conflicts . . . . . . . . . . . . . . . . . 286
42          3.3 Diffing and Patching  . . . . . . . . . . . . . . . . .  320          3.3 Diffing and Patching  . . . . . . . . . . . . . . . . .  320
43    
44    
45    1. Introduction    1. Introduction
# Line 116  Line 119 
119        special care taken to print each element of the association on a        special care taken to print each element of the association on a
120        separate line of text, and maintaining a consistently sorted order.        separate line of text, and maintaining a consistently sorted order.
121    
122          The separation of the directory structure from a flat file database
123          is nothing new; separation of a directory service from a flat file
124          service is a common theme in the design of filesystems.
125    
126          Meta-CVS imitates the UNIX filesystem to the extent that a
127          restore command hunts down ``unlinked'' files and places them
128          into a lost+found directory under cryptic names derived from
129          their ID's, which behave analogously to inode numbers!
130          In UNIX, a file can remain in use while it is deleted from
131          the directory structure, and so it is in Meta-CVS. A file
132          removal in Meta-CVS is a non-destructive unlinking from the directory
133          structure.
134    
135    2.1 File Mapping Example    2.1 File Mapping Example
136    
137        Suppose that some project 'foo' consists of these files:        Suppose that some project 'foo' consists of these files:
138    
139          foo/README          foo/README
140          foo/inc/foo.h          foo/inc/foo.h
141          foo/src/Makefile          foo/src/Makefile
142          foo/src/foo.c          foo/src/foo.c
143    
144        what does a Meta-CVS representation look like? This is best        what does a Meta-CVS representation look like? This is best
145        understood in terms of the working copy checked out from CVS via        understood in terms of the working copy checked out from CVS via
146        Meta-CVS, which contains these things:        Meta-CVS, which contains these things:
147    
148          foo/MCVS/CVS/Entries          foo/MCVS/CVS/Entries
149          foo/MCVS/CVS/... other CVS metadata ...          foo/MCVS/CVS/... other CVS metadata ...
150    
151          foo/MCVS/F-123D61C8FE942733281D2B08C15CD438          foo/MCVS/F-123D61C8FE942733281D2B08C15CD438
152          foo/MCVS/F-156CAB88D4EEE703E8C4B4146B5094E2.h          foo/MCVS/F-156CAB88D4EEE703E8C4B4146B5094E2.h
153          foo/MCVS/F-15EA9689ACF749C314CE6FC5255DC4B0          foo/MCVS/F-15EA9689ACF749C314CE6FC5255DC4B0
154          foo/MCVS/F-1C43C940D8745CAA78752C1206316B55.c          foo/MCVS/F-1C43C940D8745CAA78752C1206316B55.c
155          foo/MCVS/MAP          foo/MCVS/MAP
156          foo/MCVS/MAP-LOCAL          foo/MCVS/MAP-LOCAL
157    
158          foo/README          foo/README
159          foo/inc/foo.h          foo/inc/foo.h
160          foo/src/Makefile          foo/src/Makefile
161          foo/src/foo.c          foo/src/foo.c
162    
163        There is a subdirectory called MCVS, which contains a CVS        There is a subdirectory called MCVS, which contains a CVS
164        subdirectory. This MCVS subdirectory is in fact the CVS        subdirectory. This MCVS subdirectory is in fact the CVS
# Line 164  Line 180 
180    
181        What establishes the relationship between the F- names and the        What establishes the relationship between the F- names and the
182        human readable paths is the association list in the MAP file,        human readable paths is the association list in the MAP file,
183        which looks something like this:        which, in the early versions of Meta-CVS looked like this:
184    
185          (("MCVS/F-123D61C8FE942733281D2B08C15CD438"          (("MCVS/F-123D61C8FE942733281D2B08C15CD438"
186            "README")            "README")
187           ("MCVS/F-156CAB88D4EEE703E8C4B4146B5094E2.h"           ("MCVS/F-156CAB88D4EEE703E8C4B4146B5094E2.h"
188           "inc/foo.h")           "inc/foo.h")
189           ("MCVS/F-15EA9689ACF749C314CE6FC5255DC4B0"           ("MCVS/F-15EA9689ACF749C314CE6FC5255DC4B0"
190            "src/Makefile")            "src/Makefile")
191           ("MCVS/F-1C43C940D8745CAA78752C1206316B55.c"           ("MCVS/F-1C43C940D8745CAA78752C1206316B55.c"
192            "src/foo.c"))            "src/foo.c"))
193    
194        The MAP-LOCAL file, upon checkout, is simply an exact copy of MAP.        The MAP-LOCAL file, upon checkout, is simply an exact copy of MAP.
195        The purpose of MAP-LOCAL is to keep track of the actual mapping        The purpose of MAP-LOCAL is to keep track of the actual mapping
# Line 206  Line 222 
222        running CVS also ensures that the F- files are properly        running CVS also ensures that the F- files are properly
223        synchronized with their unfolded counterparts.        synchronized with their unfolded counterparts.
224    
225    2.2 Synchronization  
226      2.2 Symbolic Links
227    
228          In August 2002, support for symbolic links was added to Meta-CVS,
229          and the format of the mapping became more complicated to reflect
230          that. The syntax was extended to allow for different kinds of
231          entries, as well as future extensibility. Each entry now has
232          a Lisp keyword symbol in its first position which identifies
233          its type. The rest of the list specifies the type-specific properties.
234          Currently, there are two types of entries :FILE and :SYMLINK.
235    
236          Right around that time, support for versioned property lists was
237          also added.
238    
239          The previous section's example now looks like this:
240    
241            ((:FILE
242              "MCVS/F-123D61C8FE942733281D2B08C15CD438"
243              "README")
244             (:FILE
245              "MCVS/F-156CAB88D4EEE703E8C4B4146B5094E2.h"
246              "inc/foo.h")
247             (:FILE
248              "MCVS/F-15EA9689ACF749C314CE6FC5255DC4B0"
249              "src/Makefile")
250             (:FILE
251              "MCVS/F-1C43C940D8745CAA78752C1206316B55.c"
252              "src/foo.c"))
253    
254           Executable files have additional material after the path name.
255           Symbolic links look like this:
256    
257             (:SYMLINK
258              "S-DF03GA1200347CF1935509371F8C1765"
259              "src/foo.c"
260              "../foo.c")
261    
262           which asserts the existence of a symbolic link called src/foo.c
263           whose target is ../foo.c.
264    
265           Both currently supported map entries have an ID string in the second
266           position, and an object path in the third position. The syntax
267           varies after that.
268    
269           Incidentally, Meta-CVS continues to recognize and parse the old
270           format. Once the mapping object is read from the MAP file, the
271           abstract syntax tree is examined to determine whether it conforms
272           to the old syntax or new. Nobody uses the old syntax; only old
273           versions stored in the repository of Meta-CVS itself.
274    
275    
276      2.3 Synchronization
277    
278        The next problem to tackle is how to establish the correspondence        The next problem to tackle is how to establish the correspondence
279        between the F- files and the working files. Meta-CVS does this in a        between the F- files and the working files. Meta-CVS does this in a
# Line 242  Line 309 
309        local changes; then after the CVS update to make sure that any        local changes; then after the CVS update to make sure that any
310        newly incorporated changes propagate back to the working copy.        newly incorporated changes propagate back to the working copy.
311    
312          The current behavior of Meta-CVS is more subtle than the above
313          description implies. The synchronization does not process the
314          entire MAP for commands that operate only on a subtree; instead,
315          entries corresponding to that subtree are filtered out of the
316          mapping. Secondly, the synchronization is direction-sensitive.
317          For instance, before a CVS commit, it makes sense to synchronize
318          from the tree to the CVS sandbox, not in the opposite direction.
319          Immediately after a commit, it makes sense to push in the opposite
320          direction, in case CVS modified the commited files (for instance
321          by altering keyword expansions).
322    
323      2.4 Partial Sandboxes
324    
325          Sometimes it is desirable to pull out just a subtree of a larger
326          project from a repository. How can this be done in a version
327          control system that represents the whole tree as a versioned object?
328          Wanting to check out part of the tree seems roughly equivalent to wanting
329          to check out half of a file.
330    
331          Meta-CVS solves this problem by supporting the concept of a partial
332          sandbox. This is a checkout that has the full mapping in the CVS
333          sandbox. A local file called DISPLACED is written which contains
334          the relative pathname of the root of the subtree that is checked out.
335          For example if the testcases/optimization subdirectory of
336          the x-compiler project is checked out, then the DISPLACED file
337          contains the path testcases/optimization.
338    
339          All of the algorithms in Meta-CVS are aware of the DISPLACED path,
340          and properly translate between the /abstract/ paths contained in
341          the mapping and the shorter, /real/ paths in the sandbox tree.
342          This translation is a no-op when there is no DISPLACED file---that
343          is, when the sandbox is a full one.
344    
345          Partial sandboxes behave robustly with respect to mapping changes
346          arriving from the repository. If another user commits a change
347          that moves a file from some currently invisible part of the tree
348          into the visible subtree, this works properly. The opposite direction
349          likewise.
350    
351          Partial sandboxes are used by the grab command to store a new
352          external drop into just a subtree of the project on a particular
353          branch or the trunk. To do this, the grab command's already
354          contorted algorithm had to be infused with translations between
355          abstract and real paths.
356    
357    
358    3. Surprising Advantages    3. Surprising Advantages
359    

Legend:
Removed from v.1.10  
changed lines
  Added in v.1.10.6.2

  ViewVC Help
Powered by ViewVC 1.1.5