hgbook
view es/concepts.tex @ 404:1839fd383e50
translated a few subsections of intro
| author | Igor TAmara <igor@tamarapatino.org> |
|---|---|
| date | Sat Nov 08 21:47:35 2008 -0500 (2008-11-08) |
| parents | 149ea8ae39c4 |
| children | 446d1b4b7a71 |
line source
1 \chapter{Tras bambalinas}
2 \label{chap:concepts}
4 A diferencia de varios sistemas de control de revisiones, los
5 conceptos en los que se fundamenta Mercurial son lo suficientemente
6 simples como para entender fácilmente cómo funciona el software.
7 Saber esto no es necesario, pero considero útil tener un ``modelo
8 mental'' de qué es lo que sucede.
10 Comprender esto me da la confianza de que Mercurial ha sido
11 cuidadosamente diseñado para ser tanto \emph{seguro} como
12 \emph{eficiente}. Y tal vez con la misma importancia, si es fácil
13 para mí hacerme a una idea adecuada de qué está haciendo el software
14 cuando llevo a cabo una tarea relacionada con control de revisiones,
15 es menos probable que me sosprenda su comportamiento.
17 En este capítulo, cubriremos inicialmente los conceptos centrales
18 del diseño de Mercurial, y luego discutiremos algunos detalles
19 interesantes de su implementación.
21 \section{Registro del historial de Mercurial}
23 \subsection{Seguir el historial de un único fichero}
25 Cuando Mercurial sigue las modificaciones a un fichero, guarda el
26 historial de dicho fichero en un objeto de metadatos llamado
27 \emph{filelog}\ndt{Fichero de registro}. Cada entrada en el fichero
28 de registro contiene suficiente información para reconstruir una
29 revisión del fichero que se está siguiendo. Los ficheros de registro
30 son almacenados como ficheros el el directorio
31 \sdirname{.hg/store/data}. Un fichero de registro contiene dos tipos
32 de información: datos de revisiones, y un índice para ayudar a
33 Mercurial a buscar revisiones eficientemente.
35 El fichero de registro de un fichero grande, o con un historial muy
36 largo, es guardado como ficheros separados para datos (sufijo
37 ``\texttt{.d}'') y para el índice (sufijo ``\texttt{.i}''). Para
38 ficheros pequeños con un historial pequeño, los datos de revisiones y
39 el índice son combinados en un único fichero ``\texttt{.i}''. La
40 correspondencia entre un fichero en el directorio de trabajo y el
41 fichero de registro que hace seguimiento a su historial en el
42 repositorio se ilustra en la figura~\ref{fig:concepts:filelog}.
44 \begin{figure}[ht]
45 \centering
46 \grafix{filelog}
47 \caption{Relación entre ficheros en el directorio de trabajo y
48 ficheros de registro en el repositorio}
49 \label{fig:concepts:filelog}
50 \end{figure}
52 \subsection{Administración de ficheros monitoreados}
54 Mercurial usa una estructura llamada \emph{manifiesto} para
55 % TODO collect together => centralizar
56 centralizar la información que maneja acerca de los ficheros que
57 monitorea. Cada entrada en el manifiesto contiene información acerca
58 de los ficheros involucrados en un único conjunto de cambios. Una
59 entrada registra qué ficheros están presentes en el conjunto de
60 cambios, la revisión de cada fichero, y otros cuantos metadatos del
61 mismo.
63 \subsection{Registro de información del conjunto de cambios}
65 La \emph{bitácora de cambios} contiene información acerca de cada
66 conjunto de cambios. Cada revisión indica quién consignó un cambio, el
67 comentario para el conjunto de cambios, otros datos relacionados con
68 el conjunto de cambios, y la revisión del manifiesto a usar.
70 \subsection{Relaciones entre revisiones}
72 Dentro de una bitácora de cambios, un manifiesto, o un fichero de
73 registro, cada revisión conserva un apuntador a su padre inmediato
74 (o sus dos padres, si es la revisión de una fusión). Como menciońe
75 anteriormente, también hay relaciones entre revisiones \emph{a través}
76 de estas estructuras, y tienen naturaleza jerárquica.
78 Por cada conjunto de cambios en un repositorio, hay exactamente una
79 revisión almacenada en la bitácora de cambios. Cada revisión de la
80 bitácora de cambios contiene un apuntador a una única revisión del
81 manifiesto. Una revisión del manifiesto almacena un apuntador a una
82 única revisión de cada fichero de registro al que se le hacía
83 seguimiento cuando fue creado el conjunto de cambios. Estas relaciones
84 se ilustran en la figura~\ref{fig:concepts:metadata}.
86 \begin{figure}[ht]
87 \centering
88 \grafix{metadata}
89 \caption{Relaciones entre metadatos}
90 \label{fig:concepts:metadata}
91 \end{figure}
93 As the illustration shows, there is \emph{not} a ``one to one''
94 relationship between revisions in the changelog, manifest, or filelog.
95 If the manifest hasn't changed between two changesets, the changelog
96 entries for those changesets will point to the same revision of the
97 manifest. If a file that Mercurial tracks hasn't changed between two
98 changesets, the entry for that file in the two revisions of the
99 manifest will point to the same revision of its filelog.
101 \section{Safe, efficient storage}
103 The underpinnings of changelogs, manifests, and filelogs are provided
104 by a single structure called the \emph{revlog}.
106 \subsection{Efficient storage}
108 The revlog provides efficient storage of revisions using a
109 \emph{delta} mechanism. Instead of storing a complete copy of a file
110 for each revision, it stores the changes needed to transform an older
111 revision into the new revision. For many kinds of file data, these
112 deltas are typically a fraction of a percent of the size of a full
113 copy of a file.
115 Some obsolete revision control systems can only work with deltas of
116 text files. They must either store binary files as complete snapshots
117 or encoded into a text representation, both of which are wasteful
118 approaches. Mercurial can efficiently handle deltas of files with
119 arbitrary binary contents; it doesn't need to treat text as special.
121 \subsection{Safe operation}
122 \label{sec:concepts:txn}
124 Mercurial only ever \emph{appends} data to the end of a revlog file.
125 It never modifies a section of a file after it has written it. This
126 is both more robust and efficient than schemes that need to modify or
127 rewrite data.
129 In addition, Mercurial treats every write as part of a
130 \emph{transaction} that can span a number of files. A transaction is
131 \emph{atomic}: either the entire transaction succeeds and its effects
132 are all visible to readers in one go, or the whole thing is undone.
133 This guarantee of atomicity means that if you're running two copies of
134 Mercurial, where one is reading data and one is writing it, the reader
135 will never see a partially written result that might confuse it.
137 The fact that Mercurial only appends to files makes it easier to
138 provide this transactional guarantee. The easier it is to do stuff
139 like this, the more confident you should be that it's done correctly.
141 \subsection{Fast retrieval}
143 Mercurial cleverly avoids a pitfall common to all earlier
144 revision control systems: the problem of \emph{inefficient retrieval}.
145 Most revision control systems store the contents of a revision as an
146 incremental series of modifications against a ``snapshot''. To
147 reconstruct a specific revision, you must first read the snapshot, and
148 then every one of the revisions between the snapshot and your target
149 revision. The more history that a file accumulates, the more
150 revisions you must read, hence the longer it takes to reconstruct a
151 particular revision.
153 \begin{figure}[ht]
154 \centering
155 \grafix{snapshot}
156 \caption{Snapshot of a revlog, with incremental deltas}
157 \label{fig:concepts:snapshot}
158 \end{figure}
160 The innovation that Mercurial applies to this problem is simple but
161 effective. Once the cumulative amount of delta information stored
162 since the last snapshot exceeds a fixed threshold, it stores a new
163 snapshot (compressed, of course), instead of another delta. This
164 makes it possible to reconstruct \emph{any} revision of a file
165 quickly. This approach works so well that it has since been copied by
166 several other revision control systems.
168 Figure~\ref{fig:concepts:snapshot} illustrates the idea. In an entry
169 in a revlog's index file, Mercurial stores the range of entries from
170 the data file that it must read to reconstruct a particular revision.
172 \subsubsection{Aside: the influence of video compression}
174 If you're familiar with video compression or have ever watched a TV
175 feed through a digital cable or satellite service, you may know that
176 most video compression schemes store each frame of video as a delta
177 against its predecessor frame. In addition, these schemes use
178 ``lossy'' compression techniques to increase the compression ratio, so
179 visual errors accumulate over the course of a number of inter-frame
180 deltas.
182 Because it's possible for a video stream to ``drop out'' occasionally
183 due to signal glitches, and to limit the accumulation of artefacts
184 introduced by the lossy compression process, video encoders
185 periodically insert a complete frame (called a ``key frame'') into the
186 video stream; the next delta is generated against that frame. This
187 means that if the video signal gets interrupted, it will resume once
188 the next key frame is received. Also, the accumulation of encoding
189 errors restarts anew with each key frame.
191 \subsection{Identification and strong integrity}
193 Along with delta or snapshot information, a revlog entry contains a
194 cryptographic hash of the data that it represents. This makes it
195 difficult to forge the contents of a revision, and easy to detect
196 accidental corruption.
198 Hashes provide more than a mere check against corruption; they are
199 used as the identifiers for revisions. The changeset identification
200 hashes that you see as an end user are from revisions of the
201 changelog. Although filelogs and the manifest also use hashes,
202 Mercurial only uses these behind the scenes.
204 Mercurial verifies that hashes are correct when it retrieves file
205 revisions and when it pulls changes from another repository. If it
206 encounters an integrity problem, it will complain and stop whatever
207 it's doing.
209 In addition to the effect it has on retrieval efficiency, Mercurial's
210 use of periodic snapshots makes it more robust against partial data
211 corruption. If a revlog becomes partly corrupted due to a hardware
212 error or system bug, it's often possible to reconstruct some or most
213 revisions from the uncorrupted sections of the revlog, both before and
214 after the corrupted section. This would not be possible with a
215 delta-only storage model.
217 \section{Revision history, branching,
218 and merging}
220 Every entry in a Mercurial revlog knows the identity of its immediate
221 ancestor revision, usually referred to as its \emph{parent}. In fact,
222 a revision contains room for not one parent, but two. Mercurial uses
223 a special hash, called the ``null ID'', to represent the idea ``there
224 is no parent here''. This hash is simply a string of zeroes.
226 In figure~\ref{fig:concepts:revlog}, you can see an example of the
227 conceptual structure of a revlog. Filelogs, manifests, and changelogs
228 all have this same structure; they differ only in the kind of data
229 stored in each delta or snapshot.
231 The first revision in a revlog (at the bottom of the image) has the
232 null ID in both of its parent slots. For a ``normal'' revision, its
233 first parent slot contains the ID of its parent revision, and its
234 second contains the null ID, indicating that the revision has only one
235 real parent. Any two revisions that have the same parent ID are
236 branches. A revision that represents a merge between branches has two
237 normal revision IDs in its parent slots.
239 \begin{figure}[ht]
240 \centering
241 \grafix{revlog}
242 \caption{}
243 \label{fig:concepts:revlog}
244 \end{figure}
246 \section{The working directory}
248 In the working directory, Mercurial stores a snapshot of the files
249 from the repository as of a particular changeset.
251 The working directory ``knows'' which changeset it contains. When you
252 update the working directory to contain a particular changeset,
253 Mercurial looks up the appropriate revision of the manifest to find
254 out which files it was tracking at the time that changeset was
255 committed, and which revision of each file was then current. It then
256 recreates a copy of each of those files, with the same contents it had
257 when the changeset was committed.
259 The \emph{dirstate} contains Mercurial's knowledge of the working
260 directory. This details which changeset the working directory is
261 updated to, and all of the files that Mercurial is tracking in the
262 working directory.
264 Just as a revision of a revlog has room for two parents, so that it
265 can represent either a normal revision (with one parent) or a merge of
266 two earlier revisions, the dirstate has slots for two parents. When
267 you use the \hgcmd{update} command, the changeset that you update to
268 is stored in the ``first parent'' slot, and the null ID in the second.
269 When you \hgcmd{merge} with another changeset, the first parent
270 remains unchanged, and the second parent is filled in with the
271 changeset you're merging with. The \hgcmd{parents} command tells you
272 what the parents of the dirstate are.
274 \subsection{What happens when you commit}
276 The dirstate stores parent information for more than just book-keeping
277 purposes. Mercurial uses the parents of the dirstate as \emph{the
278 parents of a new changeset} when you perform a commit.
280 \begin{figure}[ht]
281 \centering
282 \grafix{wdir}
283 \caption{The working directory can have two parents}
284 \label{fig:concepts:wdir}
285 \end{figure}
287 Figure~\ref{fig:concepts:wdir} shows the normal state of the working
288 directory, where it has a single changeset as parent. That changeset
289 is the \emph{tip}, the newest changeset in the repository that has no
290 children.
292 \begin{figure}[ht]
293 \centering
294 \grafix{wdir-after-commit}
295 \caption{The working directory gains new parents after a commit}
296 \label{fig:concepts:wdir-after-commit}
297 \end{figure}
299 It's useful to think of the working directory as ``the changeset I'm
300 about to commit''. Any files that you tell Mercurial that you've
301 added, removed, renamed, or copied will be reflected in that
302 changeset, as will modifications to any files that Mercurial is
303 already tracking; the new changeset will have the parents of the
304 working directory as its parents.
306 After a commit, Mercurial will update the parents of the working
307 directory, so that the first parent is the ID of the new changeset,
308 and the second is the null ID. This is shown in
309 figure~\ref{fig:concepts:wdir-after-commit}. Mercurial doesn't touch
310 any of the files in the working directory when you commit; it just
311 modifies the dirstate to note its new parents.
313 \subsection{Creating a new head}
315 It's perfectly normal to update the working directory to a changeset
316 other than the current tip. For example, you might want to know what
317 your project looked like last Tuesday, or you could be looking through
318 changesets to see which one introduced a bug. In cases like this, the
319 natural thing to do is update the working directory to the changeset
320 you're interested in, and then examine the files in the working
321 directory directly to see their contents as they werea when you
322 committed that changeset. The effect of this is shown in
323 figure~\ref{fig:concepts:wdir-pre-branch}.
325 \begin{figure}[ht]
326 \centering
327 \grafix{wdir-pre-branch}
328 \caption{The working directory, updated to an older changeset}
329 \label{fig:concepts:wdir-pre-branch}
330 \end{figure}
332 Having updated the working directory to an older changeset, what
333 happens if you make some changes, and then commit? Mercurial behaves
334 in the same way as I outlined above. The parents of the working
335 directory become the parents of the new changeset. This new changeset
336 has no children, so it becomes the new tip. And the repository now
337 contains two changesets that have no children; we call these
338 \emph{heads}. You can see the structure that this creates in
339 figure~\ref{fig:concepts:wdir-branch}.
341 \begin{figure}[ht]
342 \centering
343 \grafix{wdir-branch}
344 \caption{After a commit made while synced to an older changeset}
345 \label{fig:concepts:wdir-branch}
346 \end{figure}
348 \begin{note}
349 If you're new to Mercurial, you should keep in mind a common
350 ``error'', which is to use the \hgcmd{pull} command without any
351 options. By default, the \hgcmd{pull} command \emph{does not}
352 update the working directory, so you'll bring new changesets into
353 your repository, but the working directory will stay synced at the
354 same changeset as before the pull. If you make some changes and
355 commit afterwards, you'll thus create a new head, because your
356 working directory isn't synced to whatever the current tip is.
358 I put the word ``error'' in quotes because all that you need to do
359 to rectify this situation is \hgcmd{merge}, then \hgcmd{commit}. In
360 other words, this almost never has negative consequences; it just
361 surprises people. I'll discuss other ways to avoid this behaviour,
362 and why Mercurial behaves in this initially surprising way, later
363 on.
364 \end{note}
366 \subsection{Merging heads}
368 When you run the \hgcmd{merge} command, Mercurial leaves the first
369 parent of the working directory unchanged, and sets the second parent
370 to the changeset you're merging with, as shown in
371 figure~\ref{fig:concepts:wdir-merge}.
373 \begin{figure}[ht]
374 \centering
375 \grafix{wdir-merge}
376 \caption{Merging two heads}
377 \label{fig:concepts:wdir-merge}
378 \end{figure}
380 Mercurial also has to modify the working directory, to merge the files
381 managed in the two changesets. Simplified a little, the merging
382 process goes like this, for every file in the manifests of both
383 changesets.
384 \begin{itemize}
385 \item If neither changeset has modified a file, do nothing with that
386 file.
387 \item If one changeset has modified a file, and the other hasn't,
388 create the modified copy of the file in the working directory.
389 \item If one changeset has removed a file, and the other hasn't (or
390 has also deleted it), delete the file from the working directory.
391 \item If one changeset has removed a file, but the other has modified
392 the file, ask the user what to do: keep the modified file, or remove
393 it?
394 \item If both changesets have modified a file, invoke an external
395 merge program to choose the new contents for the merged file. This
396 may require input from the user.
397 \item If one changeset has modified a file, and the other has renamed
398 or copied the file, make sure that the changes follow the new name
399 of the file.
400 \end{itemize}
401 There are more details---merging has plenty of corner cases---but
402 these are the most common choices that are involved in a merge. As
403 you can see, most cases are completely automatic, and indeed most
404 merges finish automatically, without requiring your input to resolve
405 any conflicts.
407 When you're thinking about what happens when you commit after a merge,
408 once again the working directory is ``the changeset I'm about to
409 commit''. After the \hgcmd{merge} command completes, the working
410 directory has two parents; these will become the parents of the new
411 changeset.
413 Mercurial lets you perform multiple merges, but you must commit the
414 results of each individual merge as you go. This is necessary because
415 Mercurial only tracks two parents for both revisions and the working
416 directory. While it would be technically possible to merge multiple
417 changesets at once, the prospect of user confusion and making a
418 terrible mess of a merge immediately becomes overwhelming.
420 \section{Other interesting design features}
422 In the sections above, I've tried to highlight some of the most
423 important aspects of Mercurial's design, to illustrate that it pays
424 careful attention to reliability and performance. However, the
425 attention to detail doesn't stop there. There are a number of other
426 aspects of Mercurial's construction that I personally find
427 interesting. I'll detail a few of them here, separate from the ``big
428 ticket'' items above, so that if you're interested, you can gain a
429 better idea of the amount of thinking that goes into a well-designed
430 system.
432 \subsection{Clever compression}
434 When appropriate, Mercurial will store both snapshots and deltas in
435 compressed form. It does this by always \emph{trying to} compress a
436 snapshot or delta, but only storing the compressed version if it's
437 smaller than the uncompressed version.
439 This means that Mercurial does ``the right thing'' when storing a file
440 whose native form is compressed, such as a \texttt{zip} archive or a
441 JPEG image. When these types of files are compressed a second time,
442 the resulting file is usually bigger than the once-compressed form,
443 and so Mercurial will store the plain \texttt{zip} or JPEG.
445 Deltas between revisions of a compressed file are usually larger than
446 snapshots of the file, and Mercurial again does ``the right thing'' in
447 these cases. It finds that such a delta exceeds the threshold at
448 which it should store a complete snapshot of the file, so it stores
449 the snapshot, again saving space compared to a naive delta-only
450 approach.
452 \subsubsection{Network recompression}
454 When storing revisions on disk, Mercurial uses the ``deflate''
455 compression algorithm (the same one used by the popular \texttt{zip}
456 archive format), which balances good speed with a respectable
457 compression ratio. However, when transmitting revision data over a
458 network connection, Mercurial uncompresses the compressed revision
459 data.
461 If the connection is over HTTP, Mercurial recompresses the entire
462 stream of data using a compression algorithm that gives a better
463 compression ratio (the Burrows-Wheeler algorithm from the widely used
464 \texttt{bzip2} compression package). This combination of algorithm
465 and compression of the entire stream (instead of a revision at a time)
466 substantially reduces the number of bytes to be transferred, yielding
467 better network performance over almost all kinds of network.
469 (If the connection is over \command{ssh}, Mercurial \emph{doesn't}
470 recompress the stream, because \command{ssh} can already do this
471 itself.)
473 \subsection{Read/write ordering and atomicity}
475 Appending to files isn't the whole story when it comes to guaranteeing
476 that a reader won't see a partial write. If you recall
477 figure~\ref{fig:concepts:metadata}, revisions in the changelog point to
478 revisions in the manifest, and revisions in the manifest point to
479 revisions in filelogs. This hierarchy is deliberate.
481 A writer starts a transaction by writing filelog and manifest data,
482 and doesn't write any changelog data until those are finished. A
483 reader starts by reading changelog data, then manifest data, followed
484 by filelog data.
486 Since the writer has always finished writing filelog and manifest data
487 before it writes to the changelog, a reader will never read a pointer
488 to a partially written manifest revision from the changelog, and it will
489 never read a pointer to a partially written filelog revision from the
490 manifest.
492 \subsection{Concurrent access}
494 The read/write ordering and atomicity guarantees mean that Mercurial
495 never needs to \emph{lock} a repository when it's reading data, even
496 if the repository is being written to while the read is occurring.
497 This has a big effect on scalability; you can have an arbitrary number
498 of Mercurial processes safely reading data from a repository safely
499 all at once, no matter whether it's being written to or not.
501 The lockless nature of reading means that if you're sharing a
502 repository on a multi-user system, you don't need to grant other local
503 users permission to \emph{write} to your repository in order for them
504 to be able to clone it or pull changes from it; they only need
505 \emph{read} permission. (This is \emph{not} a common feature among
506 revision control systems, so don't take it for granted! Most require
507 readers to be able to lock a repository to access it safely, and this
508 requires write permission on at least one directory, which of course
509 makes for all kinds of nasty and annoying security and administrative
510 problems.)
512 Mercurial uses locks to ensure that only one process can write to a
513 repository at a time (the locking mechanism is safe even over
514 filesystems that are notoriously hostile to locking, such as NFS). If
515 a repository is locked, a writer will wait for a while to retry if the
516 repository becomes unlocked, but if the repository remains locked for
517 too long, the process attempting to write will time out after a while.
518 This means that your daily automated scripts won't get stuck forever
519 and pile up if a system crashes unnoticed, for example. (Yes, the
520 timeout is configurable, from zero to infinity.)
522 \subsubsection{Safe dirstate access}
524 As with revision data, Mercurial doesn't take a lock to read the
525 dirstate file; it does acquire a lock to write it. To avoid the
526 possibility of reading a partially written copy of the dirstate file,
527 Mercurial writes to a file with a unique name in the same directory as
528 the dirstate file, then renames the temporary file atomically to
529 \filename{dirstate}. The file named \filename{dirstate} is thus
530 guaranteed to be complete, not partially written.
532 \subsection{Avoiding seeks}
534 Critical to Mercurial's performance is the avoidance of seeks of the
535 disk head, since any seek is far more expensive than even a
536 comparatively large read operation.
538 This is why, for example, the dirstate is stored in a single file. If
539 there were a dirstate file per directory that Mercurial tracked, the
540 disk would seek once per directory. Instead, Mercurial reads the
541 entire single dirstate file in one step.
543 Mercurial also uses a ``copy on write'' scheme when cloning a
544 repository on local storage. Instead of copying every revlog file
545 from the old repository into the new repository, it makes a ``hard
546 link'', which is a shorthand way to say ``these two names point to the
547 same file''. When Mercurial is about to write to one of a revlog's
548 files, it checks to see if the number of names pointing at the file is
549 greater than one. If it is, more than one repository is using the
550 file, so Mercurial makes a new copy of the file that is private to
551 this repository.
553 A few revision control developers have pointed out that this idea of
554 making a complete private copy of a file is not very efficient in its
555 use of storage. While this is true, storage is cheap, and this method
556 gives the highest performance while deferring most book-keeping to the
557 operating system. An alternative scheme would most likely reduce
558 performance and increase the complexity of the software, each of which
559 is much more important to the ``feel'' of day-to-day use.
561 \subsection{Other contents of the dirstate}
563 Because Mercurial doesn't force you to tell it when you're modifying a
564 file, it uses the dirstate to store some extra information so it can
565 determine efficiently whether you have modified a file. For each file
566 in the working directory, it stores the time that it last modified the
567 file itself, and the size of the file at that time.
569 When you explicitly \hgcmd{add}, \hgcmd{remove}, \hgcmd{rename} or
570 \hgcmd{copy} files, Mercurial updates the dirstate so that it knows
571 what to do with those files when you commit.
573 When Mercurial is checking the states of files in the working
574 directory, it first checks a file's modification time. If that has
575 not changed, the file must not have been modified. If the file's size
576 has changed, the file must have been modified. If the modification
577 time has changed, but the size has not, only then does Mercurial need
578 to read the actual contents of the file to see if they've changed.
579 Storing these few extra pieces of information dramatically reduces the
580 amount of data that Mercurial needs to read, which yields large
581 performance improvements compared to other revision control systems.
583 %%% Local Variables:
584 %%% mode: latex
585 %%% TeX-master: "00book"
586 %%% End: