hgbook
annotate en/branch.tex @ 519:a529952fce96
changed "un tag" to "una etiqueta". Same thing for
"unos tags"
"un tag"
"el tag"
"los tags"
"de tag"
"de tags"
"unos tags"
"un tag"
"el tag"
"los tags"
"de tag"
"de tags"
author | Javier Rojas <jerojasro@devnull.li> |
---|---|
date | Sun Jan 18 22:21:43 2009 -0500 (2009-01-18) |
parents | 08ae82a18abd |
children |
rev | line source |
---|---|
bos@196 | 1 \chapter{Managing releases and branchy development} |
bos@187 | 2 \label{chap:branch} |
bos@187 | 3 |
bos@197 | 4 Mercurial provides several mechanisms for you to manage a project that |
bos@197 | 5 is making progress on multiple fronts at once. To understand these |
bos@197 | 6 mechanisms, let's first take a brief look at a fairly normal software |
bos@197 | 7 project structure. |
bos@187 | 8 |
bos@196 | 9 Many software projects issue periodic ``major'' releases that contain |
bos@196 | 10 substantial new features. In parallel, they may issue ``minor'' |
bos@196 | 11 releases. These are usually identical to the major releases off which |
bos@196 | 12 they're based, but with a few bugs fixed. |
bos@196 | 13 |
bos@197 | 14 In this chapter, we'll start by talking about how to keep records of |
bos@197 | 15 project milestones such as releases. We'll then continue on to talk |
bos@197 | 16 about the flow of work between different phases of a project, and how |
bos@197 | 17 Mercurial can help you to isolate and manage this work. |
bos@197 | 18 |
bos@196 | 19 \section{Giving a persistent name to a revision} |
bos@196 | 20 |
bos@196 | 21 Once you decide that you'd like to call a particular revision a |
bos@196 | 22 ``release'', it's a good idea to record the identity of that revision. |
bos@196 | 23 This will let you reproduce that release at a later date, for whatever |
bos@196 | 24 purpose you might need at the time (reproducing a bug, porting to a |
bos@196 | 25 new platform, etc). |
bos@196 | 26 \interaction{tag.init} |
bos@196 | 27 |
bos@196 | 28 Mercurial lets you give a permanent name to any revision using the |
bos@196 | 29 \hgcmd{tag} command. Not surprisingly, these names are called |
bos@196 | 30 ``tags''. |
bos@196 | 31 \interaction{tag.tag} |
bos@196 | 32 |
bos@196 | 33 A tag is nothing more than a ``symbolic name'' for a revision. Tags |
bos@196 | 34 exist purely for your convenience, so that you have a handy permanent |
bos@196 | 35 way to refer to a revision; Mercurial doesn't interpret the tag names |
bos@196 | 36 you use in any way. Neither does Mercurial place any restrictions on |
bos@196 | 37 the name of a tag, beyond a few that are necessary to ensure that a |
bos@196 | 38 tag can be parsed unambiguously. A tag name cannot contain any of the |
bos@196 | 39 following characters: |
bos@196 | 40 \begin{itemize} |
bos@196 | 41 \item Colon (ASCII 58, ``\texttt{:}'') |
bos@261 | 42 \item Carriage return (ASCII 13, ``\Verb+\r+'') |
bos@261 | 43 \item Newline (ASCII 10, ``\Verb+\n+'') |
bos@196 | 44 \end{itemize} |
bos@196 | 45 |
bos@196 | 46 You can use the \hgcmd{tags} command to display the tags present in |
bos@196 | 47 your repository. In the output, each tagged revision is identified |
bos@196 | 48 first by its name, then by revision number, and finally by the unique |
bos@196 | 49 hash of the revision. |
bos@196 | 50 \interaction{tag.tags} |
bos@196 | 51 Notice that \texttt{tip} is listed in the output of \hgcmd{tags}. The |
bos@196 | 52 \texttt{tip} tag is a special ``floating'' tag, which always |
bos@196 | 53 identifies the newest revision in the repository. |
bos@196 | 54 |
bos@196 | 55 In the output of the \hgcmd{tags} command, tags are listed in reverse |
bos@196 | 56 order, by revision number. This usually means that recent tags are |
bos@196 | 57 listed before older tags. It also means that \texttt{tip} is always |
bos@196 | 58 going to be the first tag listed in the output of \hgcmd{tags}. |
bos@196 | 59 |
bos@196 | 60 When you run \hgcmd{log}, if it displays a revision that has tags |
bos@196 | 61 associated with it, it will print those tags. |
bos@196 | 62 \interaction{tag.log} |
bos@196 | 63 |
bos@196 | 64 Any time you need to provide a revision~ID to a Mercurial command, the |
bos@196 | 65 command will accept a tag name in its place. Internally, Mercurial |
bos@196 | 66 will translate your tag name into the corresponding revision~ID, then |
bos@196 | 67 use that. |
bos@196 | 68 \interaction{tag.log.v1.0} |
bos@196 | 69 |
bos@196 | 70 There's no limit on the number of tags you can have in a repository, |
bos@196 | 71 or on the number of tags that a single revision can have. As a |
bos@196 | 72 practical matter, it's not a great idea to have ``too many'' (a number |
bos@196 | 73 which will vary from project to project), simply because tags are |
bos@196 | 74 supposed to help you to find revisions. If you have lots of tags, the |
bos@196 | 75 ease of using them to identify revisions diminishes rapidly. |
bos@196 | 76 |
bos@196 | 77 For example, if your project has milestones as frequent as every few |
bos@196 | 78 days, it's perfectly reasonable to tag each one of those. But if you |
bos@196 | 79 have a continuous build system that makes sure every revision can be |
bos@196 | 80 built cleanly, you'd be introducing a lot of noise if you were to tag |
bos@196 | 81 every clean build. Instead, you could tag failed builds (on the |
bos@196 | 82 assumption that they're rare!), or simply not use tags to track |
bos@196 | 83 buildability. |
bos@196 | 84 |
bos@196 | 85 If you want to remove a tag that you no longer want, use |
bos@196 | 86 \hgcmdargs{tag}{--remove}. |
bos@196 | 87 \interaction{tag.remove} |
bos@196 | 88 You can also modify a tag at any time, so that it identifies a |
bos@196 | 89 different revision, by simply issuing a new \hgcmd{tag} command. |
bos@196 | 90 You'll have to use the \hgopt{tag}{-f} option to tell Mercurial that |
bos@196 | 91 you \emph{really} want to update the tag. |
bos@196 | 92 \interaction{tag.replace} |
bos@196 | 93 There will still be a permanent record of the previous identity of the |
bos@197 | 94 tag, but Mercurial will no longer use it. There's thus no penalty to |
bos@197 | 95 tagging the wrong revision; all you have to do is turn around and tag |
bos@197 | 96 the correct revision once you discover your error. |
bos@196 | 97 |
bos@196 | 98 Mercurial stores tags in a normal revision-controlled file in your |
bos@196 | 99 repository. If you've created any tags, you'll find them in a file |
bos@196 | 100 named \sfilename{.hgtags}. When you run the \hgcmd{tag} command, |
bos@196 | 101 Mercurial modifies this file, then automatically commits the change to |
bos@196 | 102 it. This means that every time you run \hgcmd{tag}, you'll see a |
bos@196 | 103 corresponding changeset in the output of \hgcmd{log}. |
bos@196 | 104 \interaction{tag.tip} |
bos@196 | 105 |
bos@196 | 106 \subsection{Handling tag conflicts during a merge} |
bos@196 | 107 |
bos@196 | 108 You won't often need to care about the \sfilename{.hgtags} file, but |
bos@196 | 109 it sometimes makes its presence known during a merge. The format of |
bos@196 | 110 the file is simple: it consists of a series of lines. Each line |
bos@196 | 111 starts with a changeset hash, followed by a space, followed by the |
bos@196 | 112 name of a tag. |
bos@196 | 113 |
bos@196 | 114 If you're resolving a conflict in the \sfilename{.hgtags} file during |
bos@196 | 115 a merge, there's one twist to modifying the \sfilename{.hgtags} file: |
bos@196 | 116 when Mercurial is parsing the tags in a repository, it \emph{never} |
bos@196 | 117 reads the working copy of the \sfilename{.hgtags} file. Instead, it |
bos@196 | 118 reads the \emph{most recently committed} revision of the file. |
bos@196 | 119 |
bos@196 | 120 An unfortunate consequence of this design is that you can't actually |
bos@196 | 121 verify that your merged \sfilename{.hgtags} file is correct until |
bos@196 | 122 \emph{after} you've committed a change. So if you find yourself |
bos@196 | 123 resolving a conflict on \sfilename{.hgtags} during a merge, be sure to |
bos@196 | 124 run \hgcmd{tags} after you commit. If it finds an error in the |
bos@196 | 125 \sfilename{.hgtags} file, it will report the location of the error, |
bos@196 | 126 which you can then fix and commit. You should then run \hgcmd{tags} |
bos@196 | 127 again, just to be sure that your fix is correct. |
bos@187 | 128 |
bos@198 | 129 \subsection{Tags and cloning} |
bos@198 | 130 |
bos@198 | 131 You may have noticed that the \hgcmd{clone} command has a |
wbunaarfubss@259 | 132 \hgopt{clone}{-r} option that lets you clone an exact copy of the |
bos@198 | 133 repository as of a particular changeset. The new clone will not |
bos@198 | 134 contain any project history that comes after the revision you |
bos@198 | 135 specified. This has an interaction with tags that can surprise the |
bos@198 | 136 unwary. |
bos@198 | 137 |
bos@198 | 138 Recall that a tag is stored as a revision to the \sfilename{.hgtags} |
bos@198 | 139 file, so that when you create a tag, the changeset in which it's |
bos@198 | 140 recorded necessarily refers to an older changeset. When you run |
bos@198 | 141 \hgcmdargs{clone}{-r foo} to clone a repository as of tag |
bos@198 | 142 \texttt{foo}, the new clone \emph{will not contain the history that |
bos@198 | 143 created the tag} that you used to clone the repository. The result |
bos@198 | 144 is that you'll get exactly the right subset of the project's history |
bos@198 | 145 in the new repository, but \emph{not} the tag you might have expected. |
bos@198 | 146 |
bos@197 | 147 \subsection{When permanent tags are too much} |
bos@197 | 148 |
bos@197 | 149 Since Mercurial's tags are revision controlled and carried around with |
bos@197 | 150 a project's history, everyone you work with will see the tags you |
bos@197 | 151 create. But giving names to revisions has uses beyond simply noting |
bos@197 | 152 that revision \texttt{4237e45506ee} is really \texttt{v2.0.2}. If |
bos@197 | 153 you're trying to track down a subtle bug, you might want a tag to |
bos@197 | 154 remind you of something like ``Anne saw the symptoms with this |
bos@197 | 155 revision''. |
bos@197 | 156 |
bos@197 | 157 For cases like this, what you might want to use are \emph{local} tags. |
bos@197 | 158 You can create a local tag with the \hgopt{tag}{-l} option to the |
bos@197 | 159 \hgcmd{tag} command. This will store the tag in a file called |
bos@197 | 160 \sfilename{.hg/localtags}. Unlike \sfilename{.hgtags}, |
bos@197 | 161 \sfilename{.hg/localtags} is not revision controlled. Any tags you |
bos@197 | 162 create using \hgopt{tag}{-l} remain strictly local to the repository |
bos@197 | 163 you're currently working in. |
bos@197 | 164 |
bos@198 | 165 \section{The flow of changes---big picture vs. little} |
bos@198 | 166 |
bos@198 | 167 To return to the outline I sketched at the beginning of a chapter, |
bos@198 | 168 let's think about a project that has multiple concurrent pieces of |
bos@198 | 169 work under development at once. |
bos@198 | 170 |
bos@198 | 171 There might be a push for a new ``main'' release; a new minor bugfix |
bos@198 | 172 release to the last main release; and an unexpected ``hot fix'' to an |
bos@198 | 173 old release that is now in maintenance mode. |
bos@198 | 174 |
bos@198 | 175 The usual way people refer to these different concurrent directions of |
bos@198 | 176 development is as ``branches''. However, we've already seen numerous |
bos@198 | 177 times that Mercurial treats \emph{all of history} as a series of |
bos@198 | 178 branches and merges. Really, what we have here is two ideas that are |
bos@198 | 179 peripherally related, but which happen to share a name. |
bos@198 | 180 \begin{itemize} |
bos@198 | 181 \item ``Big picture'' branches represent the sweep of a project's |
bos@198 | 182 evolution; people give them names, and talk about them in |
bos@198 | 183 conversation. |
bos@198 | 184 \item ``Little picture'' branches are artefacts of the day-to-day |
bos@198 | 185 activity of developing and merging changes. They expose the |
bos@198 | 186 narrative of how the code was developed. |
bos@198 | 187 \end{itemize} |
bos@198 | 188 |
bos@198 | 189 \section{Managing big-picture branches in repositories} |
bos@198 | 190 |
bos@198 | 191 The easiest way to isolate a ``big picture'' branch in Mercurial is in |
bos@198 | 192 a dedicated repository. If you have an existing shared |
bos@198 | 193 repository---let's call it \texttt{myproject}---that reaches a ``1.0'' |
bos@198 | 194 milestone, you can start to prepare for future maintenance releases on |
bos@198 | 195 top of version~1.0 by tagging the revision from which you prepared |
bos@198 | 196 the~1.0 release. |
bos@198 | 197 \interaction{branch-repo.tag} |
bos@198 | 198 You can then clone a new shared \texttt{myproject-1.0.1} repository as |
bos@198 | 199 of that tag. |
bos@198 | 200 \interaction{branch-repo.clone} |
bos@198 | 201 |
bos@198 | 202 Afterwards, if someone needs to work on a bug fix that ought to go |
bos@198 | 203 into an upcoming~1.0.1 minor release, they clone the |
bos@198 | 204 \texttt{myproject-1.0.1} repository, make their changes, and push them |
bos@198 | 205 back. |
bos@198 | 206 \interaction{branch-repo.bugfix} |
bos@198 | 207 Meanwhile, development for the next major release can continue, |
bos@198 | 208 isolated and unabated, in the \texttt{myproject} repository. |
bos@198 | 209 \interaction{branch-repo.new} |
bos@198 | 210 |
bos@199 | 211 \section{Don't repeat yourself: merging across branches} |
bos@199 | 212 |
bos@199 | 213 In many cases, if you have a bug to fix on a maintenance branch, the |
bos@199 | 214 chances are good that the bug exists on your project's main branch |
bos@199 | 215 (and possibly other maintenance branches, too). It's a rare developer |
bos@199 | 216 who wants to fix the same bug multiple times, so let's look at a few |
bos@199 | 217 ways that Mercurial can help you to manage these bugfixes without |
bos@199 | 218 duplicating your work. |
bos@199 | 219 |
bos@199 | 220 In the simplest instance, all you need to do is pull changes from your |
bos@199 | 221 maintenance branch into your local clone of the target branch. |
bos@199 | 222 \interaction{branch-repo.pull} |
bos@199 | 223 You'll then need to merge the heads of the two branches, and push back |
bos@199 | 224 to the main branch. |
bos@199 | 225 \interaction{branch-repo.merge} |
bos@197 | 226 |
bos@202 | 227 \section{Naming branches within one repository} |
bos@202 | 228 |
bos@202 | 229 In most instances, isolating branches in repositories is the right |
bos@202 | 230 approach. Its simplicity makes it easy to understand; and so it's |
bos@202 | 231 hard to make mistakes. There's a one-to-one relationship between |
bos@202 | 232 branches you're working in and directories on your system. This lets |
bos@202 | 233 you use normal (non-Mercurial-aware) tools to work on files within a |
bos@202 | 234 branch/repository. |
bos@202 | 235 |
bos@202 | 236 If you're more in the ``power user'' category (\emph{and} your |
bos@202 | 237 collaborators are too), there is an alternative way of handling |
bos@202 | 238 branches that you can consider. I've already mentioned the |
bos@202 | 239 human-level distinction between ``small picture'' and ``big picture'' |
bos@202 | 240 branches. While Mercurial works with multiple ``small picture'' |
bos@202 | 241 branches in a repository all the time (for example after you pull |
bos@202 | 242 changes in, but before you merge them), it can \emph{also} work with |
bos@202 | 243 multiple ``big picture'' branches. |
bos@202 | 244 |
bos@202 | 245 The key to working this way is that Mercurial lets you assign a |
bos@202 | 246 persistent \emph{name} to a branch. There always exists a branch |
bos@202 | 247 named \texttt{default}. Even before you start naming branches |
bos@202 | 248 yourself, you can find traces of the \texttt{default} branch if you |
bos@202 | 249 look for them. |
bos@202 | 250 |
bos@202 | 251 As an example, when you run the \hgcmd{commit} command, and it pops up |
bos@202 | 252 your editor so that you can enter a commit message, look for a line |
bos@202 | 253 that contains the text ``\texttt{HG: branch default}'' at the bottom. |
bos@202 | 254 This is telling you that your commit will occur on the branch named |
bos@202 | 255 \texttt{default}. |
bos@202 | 256 |
bos@202 | 257 To start working with named branches, use the \hgcmd{branches} |
bos@202 | 258 command. This command lists the named branches already present in |
bos@203 | 259 your repository, telling you which changeset is the tip of each. |
bos@202 | 260 \interaction{branch-named.branches} |
bos@203 | 261 Since you haven't created any named branches yet, the only one that |
bos@203 | 262 exists is \texttt{default}. |
bos@203 | 263 |
bos@203 | 264 To find out what the ``current'' branch is, run the \hgcmd{branch} |
bos@203 | 265 command, giving it no arguments. This tells you what branch the |
bos@203 | 266 parent of the current changeset is on. |
bos@203 | 267 \interaction{branch-named.branch} |
bos@203 | 268 |
bos@203 | 269 To create a new branch, run the \hgcmd{branch} command again. This |
bos@203 | 270 time, give it one argument: the name of the branch you want to create. |
bos@203 | 271 \interaction{branch-named.create} |
bos@203 | 272 |
bos@203 | 273 After you've created a branch, you might wonder what effect the |
bos@203 | 274 \hgcmd{branch} command has had. What do the \hgcmd{status} and |
bos@203 | 275 \hgcmd{tip} commands report? |
bos@203 | 276 \interaction{branch-named.status} |
bos@203 | 277 Nothing has changed in the working directory, and there's been no new |
bos@203 | 278 history created. As this suggests, running the \hgcmd{branch} command |
bos@203 | 279 has no permanent effect; it only tells Mercurial what branch name to |
bos@203 | 280 use the \emph{next} time you commit a changeset. |
bos@203 | 281 |
bos@203 | 282 When you commit a change, Mercurial records the name of the branch on |
bos@203 | 283 which you committed. Once you've switched from the \texttt{default} |
bos@203 | 284 branch to another and committed, you'll see the name of the new branch |
bos@203 | 285 show up in the output of \hgcmd{log}, \hgcmd{tip}, and other commands |
bos@203 | 286 that display the same kind of output. |
bos@203 | 287 \interaction{branch-named.commit} |
bos@203 | 288 The \hgcmd{log}-like commands will print the branch name of every |
bos@205 | 289 changeset that's not on the \texttt{default} branch. As a result, if |
bos@205 | 290 you never use named branches, you'll never see this information. |
bos@205 | 291 |
bos@205 | 292 Once you've named a branch and committed a change with that name, |
bos@205 | 293 every subsequent commit that descends from that change will inherit |
bos@206 | 294 the same branch name. You can change the name of a branch at any |
bos@206 | 295 time, using the \hgcmd{branch} command. |
bos@206 | 296 \interaction{branch-named.rebranch} |
bos@206 | 297 In practice, this is something you won't do very often, as branch |
bos@206 | 298 names tend to have fairly long lifetimes. (This isn't a rule, just an |
bos@206 | 299 observation.) |
bos@206 | 300 |
bos@206 | 301 \section{Dealing with multiple named branches in a repository} |
bos@206 | 302 |
bos@206 | 303 If you have more than one named branch in a repository, Mercurial will |
bos@206 | 304 remember the branch that your working directory on when you start a |
bos@206 | 305 command like \hgcmd{update} or \hgcmdargs{pull}{-u}. It will update |
bos@206 | 306 the working directory to the tip of this branch, no matter what the |
bos@206 | 307 ``repo-wide'' tip is. To update to a revision that's on a different |
bos@206 | 308 named branch, you may need to use the \hgopt{update}{-C} option to |
bos@206 | 309 \hgcmd{update}. |
bos@206 | 310 |
bos@206 | 311 This behaviour is a little subtle, so let's see it in action. First, |
bos@206 | 312 let's remind ourselves what branch we're currently on, and what |
bos@206 | 313 branches are in our repository. |
bos@206 | 314 \interaction{branch-named.parents} |
bos@206 | 315 We're on the \texttt{bar} branch, but there also exists an older |
bos@206 | 316 \hgcmd{foo} branch. |
bos@206 | 317 |
bos@206 | 318 We can \hgcmd{update} back and forth between the tips of the |
bos@206 | 319 \texttt{foo} and \texttt{bar} branches without needing to use the |
bos@206 | 320 \hgopt{update}{-C} option, because this only involves going backwards |
bos@206 | 321 and forwards linearly through our change history. |
bos@206 | 322 \interaction{branch-named.update-switchy} |
bos@206 | 323 |
bos@206 | 324 If we go back to the \texttt{foo} branch and then run \hgcmd{update}, |
bos@206 | 325 it will keep us on \texttt{foo}, not move us to the tip of |
bos@206 | 326 \texttt{bar}. |
bos@206 | 327 \interaction{branch-named.update-nothing} |
bos@206 | 328 |
bos@206 | 329 Committing a new change on the \texttt{foo} branch introduces a new |
bos@206 | 330 head. |
bos@206 | 331 \interaction{branch-named.foo-commit} |
bos@205 | 332 |
bos@205 | 333 \section{Branch names and merging} |
bos@205 | 334 |
bos@205 | 335 As you've probably noticed, merges in Mercurial are not symmetrical. |
bos@205 | 336 Let's say our repository has two heads, 17 and 23. If I |
bos@205 | 337 \hgcmd{update} to 17 and then \hgcmd{merge} with 23, Mercurial records |
bos@205 | 338 17 as the first parent of the merge, and 23 as the second. Whereas if |
bos@205 | 339 I \hgcmd{update} to 23 and then \hgcmd{merge} with 17, it records 23 |
bos@205 | 340 as the first parent, and 17 as the second. |
bos@205 | 341 |
bos@206 | 342 This affects Mercurial's choice of branch name when you merge. After |
bos@206 | 343 a merge, Mercurial will retain the branch name of the first parent |
bos@206 | 344 when you commit the result of the merge. If your first parent's |
bos@206 | 345 branch name is \texttt{foo}, and you merge with \texttt{bar}, the |
bos@206 | 346 branch name will still be \texttt{foo} after you merge. |
bos@206 | 347 |
bos@206 | 348 It's not unusual for a repository to contain multiple heads, each with |
bos@206 | 349 the same branch name. Let's say I'm working on the \texttt{foo} |
bos@206 | 350 branch, and so are you. We commit different changes; I pull your |
bos@206 | 351 changes; I now have two heads, each claiming to be on the \texttt{foo} |
bos@206 | 352 branch. The result of a merge will be a single head on the |
bos@206 | 353 \texttt{foo} branch, as you might hope. |
bos@206 | 354 |
bos@206 | 355 But if I'm working on the \texttt{bar} branch, and I merge work from |
bos@206 | 356 the \texttt{foo} branch, the result will remain on the \texttt{bar} |
bos@206 | 357 branch. |
bos@206 | 358 \interaction{branch-named.merge} |
bos@206 | 359 |
bos@206 | 360 To give a more concrete example, if I'm working on the |
bos@206 | 361 \texttt{bleeding-edge} branch, and I want to bring in the latest fixes |
bos@206 | 362 from the \texttt{stable} branch, Mercurial will choose the ``right'' |
bos@206 | 363 (\texttt{bleeding-edge}) branch name when I pull and merge from |
bos@206 | 364 \texttt{stable}. |
bos@206 | 365 |
bos@206 | 366 \section{Branch naming is generally useful} |
bos@206 | 367 |
bos@206 | 368 You shouldn't think of named branches as applicable only to situations |
bos@206 | 369 where you have multiple long-lived branches cohabiting in a single |
bos@206 | 370 repository. They're very useful even in the one-branch-per-repository |
bos@206 | 371 case. |
bos@206 | 372 |
bos@206 | 373 In the simplest case, giving a name to each branch gives you a |
bos@206 | 374 permanent record of which branch a changeset originated on. This |
bab@266 | 375 gives you more context when you're trying to follow the history of a |
bos@206 | 376 long-lived branchy project. |
bos@206 | 377 |
bos@207 | 378 If you're working with shared repositories, you can set up a |
bos@207 | 379 \hook{pretxnchangegroup} hook on each that will block incoming changes |
bos@207 | 380 that have the ``wrong'' branch name. This provides a simple, but |
bos@207 | 381 effective, defence against people accidentally pushing changes from a |
bos@207 | 382 ``bleeding edge'' branch to a ``stable'' branch. Such a hook might |
bos@207 | 383 look like this inside the shared repo's \hgrc. |
bos@207 | 384 \begin{codesample2} |
bos@207 | 385 [hooks] |
bos@207 | 386 pretxnchangegroup.branch = hg heads --template '{branches} ' | grep mybranch |
bos@207 | 387 \end{codesample2} |
bos@202 | 388 |
bos@187 | 389 %%% Local Variables: |
bos@187 | 390 %%% mode: latex |
bos@187 | 391 %%% TeX-master: "00book" |
bos@187 | 392 %%% End: |