hgbook

annotate es/filenames.tex @ 430:3afc654d70e5

translated some paragraphs. yawn sleepy
author jerojasro@localhost
date Sat Nov 29 23:48:11 2008 -0500 (2008-11-29)
parents b05e35d641e4
children f809de31887a
rev   line source
igor@402 1 \chapter{File names and pattern matching}
igor@402 2 \label{chap:names}
igor@402 3
jerojasro@430 4 Mercurial provee mecanismos que le permiten trabajar con nombres de
jerojasro@430 5 ficheros en una manera consistente y expresiva.
jerojasro@430 6
jerojasro@430 7 \section{Nombrado de ficheros simple}
jerojasro@430 8
jerojasro@430 9 % TODO traducción literal de "under the hood". revisar
jerojasro@430 10 Mercurial usa un mecanismo unificado ``bajo el capó'' para manejar
jerojasro@430 11 nombres de ficheros. Cada comando se comporta de manera uniforme con
jerojasro@430 12 respecto a los nombres de fichero. La manera en que los comandos
jerojasro@430 13 operan con nombres de fichero es la siguiente.
jerojasro@430 14
jerojasro@430 15 Si usted especifica explícitamente nombres reales de ficheros en la
jerojasro@430 16 línea de comandos, Mercurial opera únicamente sobre dichos ficheros,
jerojasro@430 17 como usted esperaría.
igor@402 18 \interaction{filenames.files}
igor@402 19
jerojasro@430 20 Cuando usted provee el nombre de un directorio, Mercurial interpreta
jerojasro@430 21 eso como ``opere en cada fichero en este directorio y sus
jerojasro@430 22 subdirectorios''. Mercurial va por todos los ficheros y subdirectorios
jerojasro@430 23 de un directorio en orden alfabético. Cuando encuentra un
jerojasro@430 24 subdirectorio, lo recorrerá antes de continuar con el directorio
jerojasro@430 25 actual.
igor@402 26 \interaction{filenames.dirs}
igor@402 27
jerojasro@430 28 \section{Ejecución de comandos sin ningún nombre de fichero}
jerojasro@430 29
jerojasro@430 30 Los comandos de Mercurial que trabajan con nombres de fichero tienen
jerojasro@430 31 comportamientos por defecto adecuados cuando son utilizados sin pasar
jerojasro@430 32 ningún patrón o nombre de fichero. El tipo de comportamiento depende
jerojasro@430 33 de lo que haga el comando. Aquí presento unas cuantas
igor@402 34 patterns. What kind of behaviour you should expect depends on what
igor@402 35 the command does. Here are a few rules of thumb you can use to
igor@402 36 predict what a command is likely to do if you don't give it any names
igor@402 37 to work with.
igor@402 38 \begin{itemize}
igor@402 39 \item Most commands will operate on the entire working directory.
igor@402 40 This is what the \hgcmd{add} command does, for example.
igor@402 41 \item If the command has effects that are difficult or impossible to
igor@402 42 reverse, it will force you to explicitly provide at least one name
igor@402 43 or pattern (see below). This protects you from accidentally
igor@402 44 deleting files by running \hgcmd{remove} with no arguments, for
igor@402 45 example.
igor@402 46 \end{itemize}
igor@402 47
igor@402 48 It's easy to work around these default behaviours if they don't suit
igor@402 49 you. If a command normally operates on the whole working directory,
igor@402 50 you can invoke it on just the current directory and its subdirectories
igor@402 51 by giving it the name ``\dirname{.}''.
igor@402 52 \interaction{filenames.wdir-subdir}
igor@402 53
igor@402 54 Along the same lines, some commands normally print file names relative
igor@402 55 to the root of the repository, even if you're invoking them from a
igor@402 56 subdirectory. Such a command will print file names relative to your
igor@402 57 subdirectory if you give it explicit names. Here, we're going to run
igor@402 58 \hgcmd{status} from a subdirectory, and get it to operate on the
igor@402 59 entire working directory while printing file names relative to our
igor@402 60 subdirectory, by passing it the output of the \hgcmd{root} command.
igor@402 61 \interaction{filenames.wdir-relname}
igor@402 62
igor@402 63 \section{Telling you what's going on}
igor@402 64
igor@402 65 The \hgcmd{add} example in the preceding section illustrates something
igor@402 66 else that's helpful about Mercurial commands. If a command operates
igor@402 67 on a file that you didn't name explicitly on the command line, it will
igor@402 68 usually print the name of the file, so that you will not be surprised
igor@402 69 what's going on.
igor@402 70
igor@402 71 The principle here is of \emph{least surprise}. If you've exactly
igor@402 72 named a file on the command line, there's no point in repeating it
igor@402 73 back at you. If Mercurial is acting on a file \emph{implicitly},
igor@402 74 because you provided no names, or a directory, or a pattern (see
igor@402 75 below), it's safest to tell you what it's doing.
igor@402 76
igor@402 77 For commands that behave this way, you can silence them using the
igor@402 78 \hggopt{-q} option. You can also get them to print the name of every
igor@402 79 file, even those you've named explicitly, using the \hggopt{-v}
igor@402 80 option.
igor@402 81
igor@402 82 \section{Using patterns to identify files}
igor@402 83
igor@402 84 In addition to working with file and directory names, Mercurial lets
igor@402 85 you use \emph{patterns} to identify files. Mercurial's pattern
igor@402 86 handling is expressive.
igor@402 87
igor@402 88 On Unix-like systems (Linux, MacOS, etc.), the job of matching file
igor@402 89 names to patterns normally falls to the shell. On these systems, you
igor@402 90 must explicitly tell Mercurial that a name is a pattern. On Windows,
igor@402 91 the shell does not expand patterns, so Mercurial will automatically
igor@402 92 identify names that are patterns, and expand them for you.
igor@402 93
igor@402 94 To provide a pattern in place of a regular name on the command line,
igor@402 95 the mechanism is simple:
igor@402 96 \begin{codesample2}
igor@402 97 syntax:patternbody
igor@402 98 \end{codesample2}
igor@402 99 That is, a pattern is identified by a short text string that says what
igor@402 100 kind of pattern this is, followed by a colon, followed by the actual
igor@402 101 pattern.
igor@402 102
igor@402 103 Mercurial supports two kinds of pattern syntax. The most frequently
igor@402 104 used is called \texttt{glob}; this is the same kind of pattern
igor@402 105 matching used by the Unix shell, and should be familiar to Windows
igor@402 106 command prompt users, too.
igor@402 107
igor@402 108 When Mercurial does automatic pattern matching on Windows, it uses
igor@402 109 \texttt{glob} syntax. You can thus omit the ``\texttt{glob:}'' prefix
igor@402 110 on Windows, but it's safe to use it, too.
igor@402 111
igor@402 112 The \texttt{re} syntax is more powerful; it lets you specify patterns
igor@402 113 using regular expressions, also known as regexps.
igor@402 114
igor@402 115 By the way, in the examples that follow, notice that I'm careful to
igor@402 116 wrap all of my patterns in quote characters, so that they won't get
igor@402 117 expanded by the shell before Mercurial sees them.
igor@402 118
igor@402 119 \subsection{Shell-style \texttt{glob} patterns}
igor@402 120
igor@402 121 This is an overview of the kinds of patterns you can use when you're
igor@402 122 matching on glob patterns.
igor@402 123
igor@402 124 The ``\texttt{*}'' character matches any string, within a single
igor@402 125 directory.
igor@402 126 \interaction{filenames.glob.star}
igor@402 127
igor@402 128 The ``\texttt{**}'' pattern matches any string, and crosses directory
igor@402 129 boundaries. It's not a standard Unix glob token, but it's accepted by
igor@402 130 several popular Unix shells, and is very useful.
igor@402 131 \interaction{filenames.glob.starstar}
igor@402 132
igor@402 133 The ``\texttt{?}'' pattern matches any single character.
igor@402 134 \interaction{filenames.glob.question}
igor@402 135
igor@402 136 The ``\texttt{[}'' character begins a \emph{character class}. This
igor@402 137 matches any single character within the class. The class ends with a
igor@402 138 ``\texttt{]}'' character. A class may contain multiple \emph{range}s
igor@402 139 of the form ``\texttt{a-f}'', which is shorthand for
igor@402 140 ``\texttt{abcdef}''.
igor@402 141 \interaction{filenames.glob.range}
igor@402 142 If the first character after the ``\texttt{[}'' in a character class
igor@402 143 is a ``\texttt{!}'', it \emph{negates} the class, making it match any
igor@402 144 single character not in the class.
igor@402 145
igor@402 146 A ``\texttt{\{}'' begins a group of subpatterns, where the whole group
igor@402 147 matches if any subpattern in the group matches. The ``\texttt{,}''
igor@402 148 character separates subpatterns, and ``\texttt{\}}'' ends the group.
igor@402 149 \interaction{filenames.glob.group}
igor@402 150
igor@402 151 \subsubsection{Watch out!}
igor@402 152
igor@402 153 Don't forget that if you want to match a pattern in any directory, you
igor@402 154 should not be using the ``\texttt{*}'' match-any token, as this will
igor@402 155 only match within one directory. Instead, use the ``\texttt{**}''
igor@402 156 token. This small example illustrates the difference between the two.
igor@402 157 \interaction{filenames.glob.star-starstar}
igor@402 158
igor@402 159 \subsection{Regular expression matching with \texttt{re} patterns}
igor@402 160
igor@402 161 Mercurial accepts the same regular expression syntax as the Python
igor@402 162 programming language (it uses Python's regexp engine internally).
igor@402 163 This is based on the Perl language's regexp syntax, which is the most
igor@402 164 popular dialect in use (it's also used in Java, for example).
igor@402 165
igor@402 166 I won't discuss Mercurial's regexp dialect in any detail here, as
igor@402 167 regexps are not often used. Perl-style regexps are in any case
igor@402 168 already exhaustively documented on a multitude of web sites, and in
igor@402 169 many books. Instead, I will focus here on a few things you should
igor@402 170 know if you find yourself needing to use regexps with Mercurial.
igor@402 171
igor@402 172 A regexp is matched against an entire file name, relative to the root
igor@402 173 of the repository. In other words, even if you're already in
igor@402 174 subbdirectory \dirname{foo}, if you want to match files under this
igor@402 175 directory, your pattern must start with ``\texttt{foo/}''.
igor@402 176
igor@402 177 One thing to note, if you're familiar with Perl-style regexps, is that
igor@402 178 Mercurial's are \emph{rooted}. That is, a regexp starts matching
igor@402 179 against the beginning of a string; it doesn't look for a match
igor@402 180 anywhere within the string. To match anywhere in a string, start
igor@402 181 your pattern with ``\texttt{.*}''.
igor@402 182
igor@402 183 \section{Filtering files}
igor@402 184
igor@402 185 Not only does Mercurial give you a variety of ways to specify files;
igor@402 186 it lets you further winnow those files using \emph{filters}. Commands
igor@402 187 that work with file names accept two filtering options.
igor@402 188 \begin{itemize}
igor@402 189 \item \hggopt{-I}, or \hggopt{--include}, lets you specify a pattern
igor@402 190 that file names must match in order to be processed.
igor@402 191 \item \hggopt{-X}, or \hggopt{--exclude}, gives you a way to
igor@402 192 \emph{avoid} processing files, if they match this pattern.
igor@402 193 \end{itemize}
igor@402 194 You can provide multiple \hggopt{-I} and \hggopt{-X} options on the
igor@402 195 command line, and intermix them as you please. Mercurial interprets
igor@402 196 the patterns you provide using glob syntax by default (but you can use
igor@402 197 regexps if you need to).
igor@402 198
igor@402 199 You can read a \hggopt{-I} filter as ``process only the files that
igor@402 200 match this filter''.
igor@402 201 \interaction{filenames.filter.include}
igor@402 202 The \hggopt{-X} filter is best read as ``process only the files that
igor@402 203 don't match this pattern''.
igor@402 204 \interaction{filenames.filter.exclude}
igor@402 205
igor@402 206 \section{Ignoring unwanted files and directories}
igor@402 207
igor@402 208 XXX.
igor@402 209
igor@402 210 \section{Case sensitivity}
igor@402 211 \label{sec:names:case}
igor@402 212
igor@402 213 If you're working in a mixed development environment that contains
igor@402 214 both Linux (or other Unix) systems and Macs or Windows systems, you
igor@402 215 should keep in the back of your mind the knowledge that they treat the
igor@402 216 case (``N'' versus ``n'') of file names in incompatible ways. This is
igor@402 217 not very likely to affect you, and it's easy to deal with if it does,
igor@402 218 but it could surprise you if you don't know about it.
igor@402 219
igor@402 220 Operating systems and filesystems differ in the way they handle the
igor@402 221 \emph{case} of characters in file and directory names. There are
igor@402 222 three common ways to handle case in names.
igor@402 223 \begin{itemize}
igor@402 224 \item Completely case insensitive. Uppercase and lowercase versions
igor@402 225 of a letter are treated as identical, both when creating a file and
igor@402 226 during subsequent accesses. This is common on older DOS-based
igor@402 227 systems.
igor@402 228 \item Case preserving, but insensitive. When a file or directory is
igor@402 229 created, the case of its name is stored, and can be retrieved and
igor@402 230 displayed by the operating system. When an existing file is being
igor@402 231 looked up, its case is ignored. This is the standard arrangement on
igor@402 232 Windows and MacOS. The names \filename{foo} and \filename{FoO}
igor@402 233 identify the same file. This treatment of uppercase and lowercase
igor@402 234 letters as interchangeable is also referred to as \emph{case
igor@402 235 folding}.
igor@402 236 \item Case sensitive. The case of a name is significant at all times.
igor@402 237 The names \filename{foo} and {FoO} identify different files. This
igor@402 238 is the way Linux and Unix systems normally work.
igor@402 239 \end{itemize}
igor@402 240
igor@402 241 On Unix-like systems, it is possible to have any or all of the above
igor@402 242 ways of handling case in action at once. For example, if you use a
igor@402 243 USB thumb drive formatted with a FAT32 filesystem on a Linux system,
igor@402 244 Linux will handle names on that filesystem in a case preserving, but
igor@402 245 insensitive, way.
igor@402 246
igor@402 247 \subsection{Safe, portable repository storage}
igor@402 248
igor@402 249 Mercurial's repository storage mechanism is \emph{case safe}. It
igor@402 250 translates file names so that they can be safely stored on both case
igor@402 251 sensitive and case insensitive filesystems. This means that you can
igor@402 252 use normal file copying tools to transfer a Mercurial repository onto,
igor@402 253 for example, a USB thumb drive, and safely move that drive and
igor@402 254 repository back and forth between a Mac, a PC running Windows, and a
igor@402 255 Linux box.
igor@402 256
igor@402 257 \subsection{Detecting case conflicts}
igor@402 258
igor@402 259 When operating in the working directory, Mercurial honours the naming
igor@402 260 policy of the filesystem where the working directory is located. If
igor@402 261 the filesystem is case preserving, but insensitive, Mercurial will
igor@402 262 treat names that differ only in case as the same.
igor@402 263
igor@402 264 An important aspect of this approach is that it is possible to commit
igor@402 265 a changeset on a case sensitive (typically Linux or Unix) filesystem
igor@402 266 that will cause trouble for users on case insensitive (usually Windows
igor@402 267 and MacOS) users. If a Linux user commits changes to two files, one
igor@402 268 named \filename{myfile.c} and the other named \filename{MyFile.C},
igor@402 269 they will be stored correctly in the repository. And in the working
igor@402 270 directories of other Linux users, they will be correctly represented
igor@402 271 as separate files.
igor@402 272
igor@402 273 If a Windows or Mac user pulls this change, they will not initially
igor@402 274 have a problem, because Mercurial's repository storage mechanism is
igor@402 275 case safe. However, once they try to \hgcmd{update} the working
igor@402 276 directory to that changeset, or \hgcmd{merge} with that changeset,
igor@402 277 Mercurial will spot the conflict between the two file names that the
igor@402 278 filesystem would treat as the same, and forbid the update or merge
igor@402 279 from occurring.
igor@402 280
igor@402 281 \subsection{Fixing a case conflict}
igor@402 282
igor@402 283 If you are using Windows or a Mac in a mixed environment where some of
igor@402 284 your collaborators are using Linux or Unix, and Mercurial reports a
igor@402 285 case folding conflict when you try to \hgcmd{update} or \hgcmd{merge},
igor@402 286 the procedure to fix the problem is simple.
igor@402 287
igor@402 288 Just find a nearby Linux or Unix box, clone the problem repository
igor@402 289 onto it, and use Mercurial's \hgcmd{rename} command to change the
igor@402 290 names of any offending files or directories so that they will no
igor@402 291 longer cause case folding conflicts. Commit this change, \hgcmd{pull}
igor@402 292 or \hgcmd{push} it across to your Windows or MacOS system, and
igor@402 293 \hgcmd{update} to the revision with the non-conflicting names.
igor@402 294
igor@402 295 The changeset with case-conflicting names will remain in your
igor@402 296 project's history, and you still won't be able to \hgcmd{update} your
igor@402 297 working directory to that changeset on a Windows or MacOS system, but
igor@402 298 you can continue development unimpeded.
igor@402 299
igor@402 300 \begin{note}
igor@402 301 Prior to version~0.9.3, Mercurial did not use a case safe repository
igor@402 302 storage mechanism, and did not detect case folding conflicts. If
igor@402 303 you are using an older version of Mercurial on Windows or MacOS, I
igor@402 304 strongly recommend that you upgrade.
igor@402 305 \end{note}
igor@402 306
igor@402 307 %%% Local Variables:
igor@402 308 %%% mode: latex
igor@402 309 %%% TeX-master: "00book"
igor@402 310 %%% End: