1SVK::XD(3) User Contributed Perl Documentation SVK::XD(3)
2
6 SVK::XD - svk depot and checkout handling.
7
9 use SVK::XD;
10 $xd = SVK::XD->new (depotmap => { '' => '/path/to/repos'});
11
13 depot
14 A repository referred by a name. The default depot is '' (the empty
15 string).
16 depotpath
18 A path referred by a depot name and the path inside the depot. For
19 example, //foo/bar means /foo/bar in the default depot '', and
20 /test/foo/bar means /foo/bar in the depot test.
21 copath
23 Checkout path. A path in the file system that has a checked out
24 version of a certain depotpath.
25
27 Options to "new":
28 depotmap
30 A hash reference for depot name and repository path mapping.
31 checkout
33 A Data::Hierarchy object for checkout paths mapping.
34 giantlock
36 A filename for global locking. This file protects all read and
37 write accesses to the "statefile".
38 When SVK begins to execute any command, it attempt to get a write
40 lock on this "giant lock" file. Once it gets the lock, it writes
41 its PID to the file, reads in its "statefile", and begins to exe‐
42 cute the command. Executing the command consists of a "lock" phase
43 and a "run" phase. During the lock phase, a command can do one of
44 three things: request to keep the giant lock for the entire execu‐
45 tion (for commands which modify large parts of the "statefile"),
46 request to lock individual checkout paths, or not request a lock.
47 In the first case, the command sets the "hold_giant" field on the
49 SVK::Command object (this should probably change to a real API),
50 and the command does not release the giant lock until it is fin‐
51 ished; it can rewrite the "statefile" at the end of its execution
52 without waiting on the lock, since it already holds it.
53 In the second case, the command calls "lock" on the SVK::XD object
55 one or more times; this places a "lock" entry inside the
56 Data::Hierarchy object in the statefile next to each locked path,
57 unless they are already locked by another process. Between its
58 lock phase and its run phase, the "statefile" is written to disk
59 (with the new "lock" entries) and the giant lock is dropped. After
60 the run phase, SVK acquires the giant lock again, reads in the
61 "statefile", copies all entries from the paths that it has locked
62 into the version it just read, clears the lock entries from the
63 hierarchy, writes the "statefile" to disk, and drops the giant
64 lock. Any changes to the hierarchy other than in the locked paths
65 will be ignored.
66 In the third case, SVK just drops the giant lock after the lock
68 phase and never tries to read or write the "statefile" again.
69 statefile
71 Filename for serializing "SVK::XD" object.
72 svkpath
74 Directory name of "giantlock" and "statefile".
75
77 Serialization and locking
78 load
80 Load the serialized "SVK::XD" data from statefile. Initialize $self
81 if there's nothing to load. The giant lock is acquired when calling
82 "load".
83 store
85 store
86 Serialize $self to the statefile. If giant lock is still ours,
87 overwrite the file directly. Otherwise load the file again and
88 merge the paths we locked into the new state file. After "store" is
89 called, giant is unlocked.
90 lock
92 Lock the given checkout path, store the state with the lock info to
93 prevent other instances from modifying locked paths.
94 unlock
96 Unlock all the checkout paths that were locked by this instance.
97 giant_lock
99 Lock the statefile globally. All other instances need to wait for
100 the lock before they can do anything.
101 giant_unlock
103 Release the giant lock.
104 Depot and path translation
106 find_repos
108 Given depotpath and an option about if the repository should be
109 opened. Returns an array of repository path, the path inside repos‐
110 itory, and the "SVN::Repos" object if caller wants the repository
111 to be opened.
112 find_repos_from_co
114 Given the checkout path and an option about if the repository
115 should be opened. Returns an array of repository path, the path
116 inside repository, the absolute checkout path, the checkout info,
117 and the "SVN::Repos" object if caller wants the repository to be
118 opened.
119 find_repos_from_co_maybe
121 Like "find_repos_from_co", but falls back to see if the given path
122 is a depotpath. In that case, the checkout paths returned will be
123 undef.
124 find_depotname
126 Checkout handling
128 auto_prop
130 Return a hash of properties that should attach to the file automat‐
131 ically when added.
132 depot_delta
134 Generate "SVN::Delta::Editor" calls to represent the changes
135 between "(oldroot, oldpath)" and "(newroot, newpath)". oldpath is a
136 array ref for anchor and target, newpath is just a string.
137 Options:
139 editor
141 The editor receiving delta calls.
142 no_textdelta
144 Don't generate text deltas in "apply_textdelta" calls.
145 no_recurse
147 notice_ancestry
148 checkout_delta
149 Generate "SVN::Delta::Editor" calls to represent the local changes
150 made to the checked out revision.
151 Options:
153 delete_verbose
155 Generate delete_entry calls for sub-entries within deleted
156 entry.
157 absent_verbose
159 Generate absent_* calls for sub-entries within absent entry.
160 unknown_verbose
162 generate cb_unknown calls for sub-entries within absent entry.
163 absent_ignore
165 Don't generate absent_* calls.
166 expand_copy
168 Mimic the behavior like SVN::Repos::dir_delta, lose copy infor‐
169 mation and treat all copied descendents as added too.
170 cb_ignored
172 Called for ignored items if defined.
173 cb_unchanged
175 Called for unchanged files if defined.
176 get_entry($copath)
178 Returns the Data::Hierarchy entry and the schedule of the entry.
179 get_fh
181 Returns a file handle with keyword translation and line-ending lay‐
182 ers attached.
183 get_props
185 Returns the properties associated with a node. Properties schedule
186 for commit are merged if $copath is given.
187perl v5.8.8 2006-12-28 SVK::XD(3)