| blob | 966d2609b1c3061f9f8612fa0cdeb316771d0464 |
1 <?xml version="1.0" encoding="UTF-8"?>\r
2 <!DOCTYPE glossary SYSTEM "../dtd/dblite.dtd">\r
3 <!--\r
4 Enter Glossary definitions in alphabetical Order! \r
5 DocBook doesn't sort them automatically.\r
6 -->\r
7 <glossary id="tsvn-glossary">\r
8 <title>Glossary</title>\r
9 <glossentry>\r
10 <glossterm>Add</glossterm>\r
11 <glossdef>\r
12 <para>\r
13 A Git command that is used to add a\r
14 file or directory to your working copy.\r
15 The new items are added to the repository when you commit.\r
16 </para>\r
17 </glossdef>\r
18 </glossentry>\r
19 <glossentry>\r
20 <glossterm>BASE revision</glossterm>\r
21 <glossdef>\r
22 <para>\r
23 The current base revision of a file or folder in your <emphasis>working copy</emphasis>. \r
24 This is the revision the file or folder was in, when the last checkout,\r
25 update or commit was run. The BASE revision is normally not equal to the\r
26 HEAD revision.\r
27 </para>\r
28 </glossdef>\r
29 </glossentry>\r
30 <glossentry>\r
31 <glossterm>Blame</glossterm>\r
32 <glossdef>\r
33 <para>\r
34 This command is for text files only, and it annotates every line to\r
35 show the repository revision in which it was last changed, and the\r
36 author who made that change. Our GUI implementation is called\r
37 TortoiseBlame and it also shows the commit date/time and the\r
38 log message when you hover the mouse of the revision number.\r
39 </para>\r
40 </glossdef>\r
41 </glossentry>\r
42 <glossentry>\r
43 <glossterm>BDB</glossterm>\r
44 <glossdef>\r
45 <para>\r
46 Berkeley DB. A well tested database backend for repositories, that\r
47 cannot be used on network shares. Default for pre 1.2 repositories.\r
48 </para>\r
49 </glossdef>\r
50 </glossentry>\r
51 <glossentry>\r
52 <glossterm>Branch</glossterm>\r
53 <glossdef>\r
54 <para>\r
55 A term frequently used in revision control systems to describe\r
56 what happens when development forks at a particular point and\r
57 follows 2 separate paths. You can create a branch off the main\r
58 development line so as to develop a new feature without rendering\r
59 the main line unstable. Or you can branch a stable release to which\r
60 you make only bug fixes, while new developments take place on the\r
61 unstable trunk. In Git a branch is implemented as a\r
62 <quote>cheap copy</quote>.\r
63 </para>\r
64 </glossdef>\r
65 </glossentry>\r
66 <glossentry>\r
67 <glossterm>Checkout</glossterm>\r
68 <glossdef>\r
69 <para>\r
70 A Git command which creates a local working copy in an empty\r
71 directory by downloading versioned files from the repository.\r
72 </para>\r
73 </glossdef>\r
74 </glossentry>\r
75 <glossentry>\r
76 <glossterm>Cleanup</glossterm>\r
77 <glossdef>\r
78 <para>\r
79 Remove untracked files from the working tree.\r
80 </para>\r
81 <para>\r
82 <emphasis>It is difference with tortoisesvn cleanup</emphasis>\r
83 </para>\r
84 </glossdef>\r
85 </glossentry>\r
86 <glossentry>\r
87 <glossterm>Commit</glossterm>\r
88 <glossdef>\r
89 <para>\r
90 This Git command is used to pass the changes in your local\r
91 working copy back into the repository, creating a new repository\r
92 revision.\r
93 </para>\r
94 </glossdef>\r
95 </glossentry>\r
96 <glossentry>\r
97 <glossterm>Conflict</glossterm>\r
98 <glossdef>\r
99 <para>\r
100 When changes from the repository are merged with local changes, \r
101 sometimes those changes occur on the same lines. In this case\r
102 Git cannot automatically decide which version to use and\r
103 the file is said to be in conflict. You have to edit the file manually\r
104 and resolve the conflict before you can commit any further changes.\r
105 </para>\r
106 </glossdef>\r
107 </glossentry>\r
108 <glossentry>\r
109 <glossterm>Copy</glossterm>\r
110 <glossdef>\r
111 <para>\r
112 In a Git repository you can create a copy of a single file\r
113 or an entire tree. These are implemented as <quote>cheap copies</quote>\r
114 which act a bit like a link to the original in that they take up\r
115 almost no space. Making a copy preserves the history of the item\r
116 in the copy, so you can trace changes made before the copy was made.\r
117 </para>\r
118 </glossdef>\r
119 </glossentry>\r
120 <glossentry>\r
121 <glossterm>Delete</glossterm>\r
122 <glossdef>\r
123 <para>\r
124 When you delete a versioned item (and commit the change) the item\r
125 no longer exists in the repository after the committed revision.\r
126 But of course it still exists in earlier repository revisions,\r
127 so you can still access it. If necessary, you can copy a deleted\r
128 item and <quote>resurrect</quote> it complete with history.\r
129 </para>\r
130 </glossdef>\r
131 </glossentry>\r
132 <glossentry>\r
133 <glossterm>Diff</glossterm>\r
134 <glossdef>\r
135 <para>\r
136 Shorthand for <quote>Show Differences</quote>. Very useful when\r
137 you want to see exactly what changes have been made.\r
138 </para>\r
139 </glossdef>\r
140 </glossentry>\r
141 <glossentry>\r
142 <glossterm>Export</glossterm>\r
143 <glossdef>\r
144 <para>\r
145 This command produces a copy of a versioned folder,\r
146 just like a working copy, but without the local\r
147 <literal>.svn</literal> folders.\r
148 </para>\r
149 </glossdef>\r
150 </glossentry>\r
151 <glossentry>\r
152 <glossterm>FSFS</glossterm>\r
153 <glossdef>\r
154 <para>\r
155 A proprietary Git filesystem backend for repositories.\r
156 Can be used on network shares. Default for 1.2 and newer repositories.\r
157 </para>\r
158 </glossdef>\r
159 </glossentry>\r
160 <glossentry>\r
161 <glossterm>GPO</glossterm>\r
162 <glossdef>\r
163 <para>\r
164 Group policy object\r
165 </para>\r
166 </glossdef>\r
167 </glossentry>\r
168 <glossentry>\r
169 <glossterm>HEAD revision</glossterm>\r
170 <glossdef>\r
171 <para>\r
172 The latest revision of a file or folder in the <emphasis>repository</emphasis>.\r
173 </para>\r
174 </glossdef>\r
175 </glossentry>\r
176 <glossentry>\r
177 <glossterm>Import</glossterm>\r
178 <glossdef>\r
179 <para>\r
180 Git command to import an entire folder hierarchy into the repository\r
181 in a single revision.\r
182 </para>\r
183 </glossdef>\r
184 </glossentry>\r
185 <glossentry>\r
186 <glossterm>Lock</glossterm>\r
187 <glossdef>\r
188 <para>\r
189 When you take out a lock on a versioned item, you mark it in\r
190 the repository as non-committable, except from the working copy\r
191 where the lock was taken out.\r
192 </para>\r
193 </glossdef>\r
194 </glossentry>\r
195 <glossentry>\r
196 <glossterm>Log</glossterm>\r
197 <glossdef>\r
198 <para>\r
199 Show the revision history of a file or folder.\r
200 Also known as <quote>History</quote>.\r
201 </para>\r
202 </glossdef>\r
203 </glossentry>\r
204 <glossentry>\r
205 <glossterm>History</glossterm>\r
206 <glossdef>\r
207 <para>\r
208 Show the revision history of a file or folder.\r
209 Also known as <quote>Log</quote>.\r
210 </para>\r
211 </glossdef>\r
212 </glossentry>\r
213 <glossentry>\r
214 <glossterm>Merge</glossterm>\r
215 <glossdef>\r
216 <para>\r
217 The process by which changes from the repository are added to your\r
218 working copy without disrupting any changes you have already made\r
219 locally. Sometimes these changes cannot be reconciled automatically\r
220 and the working copy is said to be in conflict.\r
221 </para>\r
222 <para>\r
223 Merging happens automatically when you update your working copy.\r
224 You can also merge specific changes from another branch using\r
225 TortoiseGit's Merge command.\r
226 </para>\r
227 </glossdef>\r
228 </glossentry>\r
229 <glossentry>\r
230 <glossterm>Patch</glossterm>\r
231 <glossdef>\r
232 <para>\r
233 If a working copy has changes to text files only, it is possible\r
234 to use Git's Diff command to generate a single file summary\r
235 of those changes in Unified Diff format. A file of this type is often\r
236 referred to as a <quote>Patch</quote>, and it can be emailed to someone\r
237 else (or to a mailing list) and applied to another working copy.\r
238 Someone without commit access can make changes and submit a patch\r
239 file for an authorized committer to apply. Or if you are unsure about\r
240 a change you can submit a patch for others to review.\r
241 </para>\r
242 </glossdef>\r
243 </glossentry>\r
244 <glossentry>\r
245 <glossterm>Property</glossterm>\r
246 <glossdef>\r
247 <para>\r
248 In addition to versioning your directories and files, Git allows\r
249 you to add versioned metadata - referred to as <quote>properties</quote>\r
250 to each of your versioned directories and files. Each property has a\r
251 name and a value, rather like a registry key. Git has some\r
252 special properties which it uses internally, such as\r
253 <literal>svn:eol-style</literal>. TortoiseGit has some too, such as\r
254 <literal>tsvn:logminsize</literal>. You can add your own properties\r
255 with any name and value you choose.\r
256 </para>\r
257 </glossdef>\r
258 </glossentry>\r
259 <glossentry>\r
260 <glossterm>Relocate</glossterm>\r
261 <glossdef>\r
262 <para>\r
263 If your repository moves, perhaps because you have moved it to\r
264 a different directory on your server, or the server domain name\r
265 has changed, you need to <quote>relocate</quote> your working copy\r
266 so that its repository URLs point to the new location.\r
267 </para>\r
268 <para>\r
269 Note: you should only use this command if your working copy is\r
270 referring to the same location in the same repository, but the\r
271 repository itself has moved. In any other circumstance you\r
272 probably need the <quote>Switch</quote> command instead.\r
273 </para>\r
274 </glossdef>\r
275 </glossentry>\r
276 <glossentry>\r
277 <glossterm>Repository</glossterm>\r
278 <glossdef>\r
279 <para>\r
280 A repository is a central place where data is stored and maintained. \r
281 A repository can be a place where multiple databases or files are located for \r
282 distribution over a network, or a repository can be a location that is \r
283 directly accessible to the user without having to travel across a network.\r
284 </para>\r
285 </glossdef>\r
286 </glossentry>\r
287 <glossentry>\r
288 <glossterm>Resolve</glossterm>\r
289 <glossdef>\r
290 <para>\r
291 When files in a working copy are left in a conflicted state following\r
292 a merge, those conflicts must be sorted out by a human using an editor\r
293 (or perhaps TortoiseMerge). This process is referred to as\r
294 <quote>Resolving Conflicts</quote>. When this is complete you can mark\r
295 the conflicted files as being resolved, which allows them to be committed.\r
296 </para>\r
297 </glossdef>\r
298 </glossentry>\r
299 <glossentry>\r
300 <glossterm>Revert</glossterm>\r
301 <glossdef>\r
302 <para>\r
303 Git keeps a local <quote>pristine</quote> copy of each file as\r
304 it was when you last updated your working copy. If you have made changes\r
305 and decide you want to undo them, you can use the <quote>revert</quote>\r
306 command to go back to the pristine copy.\r
307 </para>\r
308 </glossdef>\r
309 </glossentry>\r
310 <glossentry>\r
311 <glossterm>Revision</glossterm>\r
312 <glossdef>\r
313 <para>\r
314 Every time you commit a set of changes, you create one new\r
315 <quote>revision</quote> in the repository. Each revision represents\r
316 the state of the repository tree at a certain point in its history.\r
317 If you want to go back in time you can examine the repository as\r
318 it was at revision N.\r
319 </para>\r
320 <para>\r
321 In another sense, a revision can refer to the set of changes that\r
322 were made when that revision was created.\r
323 </para>\r
324 </glossdef>\r
325 </glossentry>\r
326 <glossentry>\r
327 <glossterm>Revision Property (revprop)</glossterm>\r
328 <glossdef>\r
329 <para>\r
330 Just as files can have properties, so can each revision in the\r
331 repository. Some special revprops are added automatically\r
332 when the revision is created, namely:\r
333 <literal>svn:date svn:author svn:log</literal> which represent\r
334 the commit date/time, the committer and the log message\r
335 respectively. These properties can be edited, but they are not\r
336 versioned, so any change is permanent and cannot be undone.\r
337 </para>\r
338 </glossdef>\r
339 </glossentry>\r
340 <glossentry>\r
341 <glossterm>SVN</glossterm>\r
342 <glossdef>\r
343 <para>\r
344 A frequently-used abbreviation for Git.\r
345 </para>\r
346 <para>\r
347 The name of the Git custom protocol used by the\r
348 <quote>svnserve</quote> repository server.\r
349 </para>\r
350 </glossdef>\r
351 </glossentry>\r
352 <glossentry>\r
353 <glossterm>Switch</glossterm>\r
354 <glossdef>\r
355 <para>\r
356 Just as <quote>Update-to-revision</quote> changes the time\r
357 window of a working copy to look at a different point in history,\r
358 so <quote>Switch</quote> changes the space window of a working copy\r
359 so that it points to a different part of the repository.\r
360 It is particularly useful when working on trunk and branches where\r
361 only a few files differ. You can switch your working copy between\r
362 the two and only the changed files will be transferred.\r
363 </para>\r
364 </glossdef>\r
365 </glossentry>\r
366 <glossentry>\r
367 <glossterm>Update</glossterm>\r
368 <glossdef>\r
369 <para>\r
370 This Git command pulls down the latest changes from the\r
371 repository into your working copy, merging any changes made by\r
372 others with local changes in the working copy.\r
373 </para>\r
374 </glossdef>\r
375 </glossentry>\r
376 <glossentry>\r
377 <glossterm>Working Copy</glossterm>\r
378 <glossdef>\r
379 <para>\r
380 This is your local <quote>sandbox</quote>, the area where you\r
381 work on the versioned files, and it normally resides on your\r
382 local hard disk. You create a working copy by doing a\r
383 <quote>Checkout</quote> from a repository, and you feed your\r
384 changes back into the repository using <quote>Commit</quote>.\r
385 </para>\r
386 </glossdef>\r
387 </glossentry>\r
388 </glossary>\r
389 <!--\r
390 local variables: \r
391 sgml-parent-document: ("book.xml" "glossary")\r
392 end:\r
393 -->\r