Mon Apr 13 21:51:59 CEST 2009 [email protected] * Rev #1: Front page.
Mon Apr 13 22:49:30 CEST 2009 [email protected] * Rev #1: Patch Theory Index page. Mon Apr 13 23:24:51 CEST 2009 [email protected] * Rev #1: Patch Theory Answers page. Mon Apr 13 23:36:12 CEST 2009 [email protected] * Rev #1: Patch Reordering page. Mon Apr 13 23:53:35 CEST 2009 [email protected] * Rev #1: Patch Theory Intro page. Tue Apr 14 00:16:17 CEST 2009 [email protected] * Rev #1: Patch Theory Examples Revisited page.
New patches: [Rev #1: Front page. [email protected]**20090413195159] hunk ./Front\32\Page.page 3 -Darcs is a free, open source, source code management system with many -fabulous features: +Darcs is a free, open source, version control system (VCS). Darcs stands out +for its ability to [reorder patches](Patch Reordering) in a repository. This +gives darcs several valuable features: + +- **Flexible** - With darcs, you can apply patches in any order. If Jane +implements feature A and then feaure B, Dick can apply the patches for feature +B only, and later decide if he wants A or not. With darcs you can cherry pick, +branch, merge changes in any order you like and Darcs will always know how to +do it. *With Darcs, if you apply the same patches in a different order you will +always get the same result*. + + +- **Distributed** - You don't need a central server. You can save, commit, branch +and merge entirely offline. Alice and Bob can work on feature X and then Y while +Charlie and Denise work on feature Z. Then Ellen can merge Y and Z and ignore X. + +- **Human Friendly** - Most VCSs impose a historical orer on changes. But humans +don't work like that. We don't think of two different changes that implement +different features as having a particular order. Well, neither does Darcs. In +Darcs, you give a name to each patch (e.g. 'feature X') and you tell Darcs which +set of patches you want (e.g. "I'd like feature Y and Z but not X"). Darcs will +know what to do with this. This makes some "complicated" mergers not complicated +at all in Darcs. + +- **Smart** - Darcs understands dependencies between patches. You can't delete +a file before you add it. You can't rename a function before you write it. The +rules Darcs uses are simple but powerful. Darcs understands when two patches +can be reordered and when they can't. Darcs uses dependencies to know when there +is a conflict (e.g. Bob can't rename file foo.txt to bar.txt if Alice already +renamed it to something else). This means that when Darcs finds a conflict, it +is likely to be a genuine conflict that requires a human to resolve (Alice and +Bob must settle on a name for the file). hunk ./Front\32\Page.page 36 -- **[Distributed]()** - Every user has access to the full command set. You can -save, commit, branch and merge without ever connecting to a central server. hunk ./Front\32\Page.page 37 -- **[Smart](Smart Patches)** - **Smart Patches** is what makes darcs stand out -above the rest. You can cherrypick, merge, apply patches in different orders, -modify patches and Darcs will know how to do it. With darcs, you can apply patches -in any order and you will always get the same result. [Rev #1: Patch Theory Index page. [email protected]**20090413204930] hunk ./Patch\32\Theory/Index.page 1 -You don't need to know Patch Theory to use darcs. Patch Theory is just for geeks -who want to know the theory behind darcs amazing Smart Patches. If you just want -to use darcs, just read [Smart Patches](../Smart Patches). +You don't need to know Patch Theory to use Darcs. As a user, everything you +need to know is in the [Patch Reordering](../Patch Reordering) page. That said, +if you are keen to know more about the theory behind Darcs, we are more than +happy to tell you all about it. hunk ./Patch\32\Theory/Index.page 8 -You should read the [Smart Patches](../Smart Patches) page before reading about -Patch theory. It would help if you also have a little experience using darcs in -a real project. +Before you tackle patch theory, you should be familiar with the +[patch reordering](../Patch Reordering) feature. It would also help if you +have a little experience kusing Darcs in a real project. hunk ./Patch\32\Theory/Index.page 15 -- [Examples Revisited]() - A second look at the examples in the [Smart Patches](../Smart Patches) page. +- [Examples Revisited]() - A second look at the examples in the [Patch Reordering](../Patch Reordering) page. +- [Answers]() - Answers to exercise problems. [Rev #1: Patch Theory Answers page. [email protected]**20090413212451] addfile ./Patch\32\Theory/Answers.page hunk ./Patch\32\Theory/Answers.page 1 +<table> + <tr> + <td>Prev:[Examples Revisited]()</td><td>Up:[Index]()</td><td>Next:[]()</td> + </tr> +</table> + +This page contains answers to the exercises in the Patch Theory section. + +1 Intro +======= + +Exercise 1-1 +------------ +We can prove this just by evaluation: +<table> + <tr> + <td>$(AB) (B^{-1}A{-1})$</td><td>$= (AB) (B^{-1}A^{-1})$</td> + </tr> + <tr> + <td></td><td>$= A B B^{-1} A^{-1}$</td> + </tr> + <tr> + <td></td><td>$= A \varepsilon A^{-1}$</td> + </tr> + <tr> + <td></td><td>$= A A^{-1}$</td> + </tr> + <tr> + <td></td><td>$=\varepsilon$</td> + </tr> +</table> + +Where $\varepsilon$ denotes the empty patch. + +Therefore, $B^{-1}A{-1}$ must be the inverse of $AB$. + +Exercise 1-2 +------------ +Let H(X) be a `Hunk` that modifies file X. Let M(X,Y) be the `Move` that +moves file X to Y. In the following rules X, Y and Z all denote different +file names: + +* `M(X,Y) H(Z) = H(Z) M(X,Y)` +* `M(X,Y) H(Y) = H(X) M(X,Y)` + +And the case `M(X,Y) H(X)` is an error because you cannot edit the old file +name after the file is reamed. + +Exercise 1-3 +------------ +How to write the inverse of a `Hunk`: Given a Hunk patch, you produce its +inverse just by swapping the `delete` and `add` instructions. For example: + +<blockquote> +<table> + <tr> + <td>`Foo.txt 42`<br/>`- Daniel likes Bananas.`<br/>`- Daniel likes Mangoes.`<br/>`+ Daniel likes fruits.`</td> + <td> -> </td> + <td>`Foo.txt 42`<br/>`- Daniel likes fruits.`<br/>`+ Daniel likes Bananas.`<br/>`+ Daniel likes Mangoes.`</td> + </tr> +</table> +</blockquote> + [Rev #1: Patch Reordering page. [email protected]**20090413213612] move ./Smart\32\Patches.page ./Patch\32\Reordering.page hunk ./Patch\32\Reordering.page 3 -Smart Patches are coolest feature that darcs has to offer. They are key to -Darcs' ease of use, easy branching and easy merging. +**Patch Reorering** is the central feature of darcs. It is the key to its ease +of use, flexibility and over-all human friendliness. hunk ./Patch\32\Reordering.page 8 -If you just want to use darcs, this is all you need to know about Smart Patches. hunk ./Patch\32\Reordering.page 16 -Now you notice that F is an important bugfix that should go into the next stable -release. But maybe F depends on some stuff you added with D, or with E? Darcs -can figure out if a patch depends on another, and it can figure out how to -adapt F to a branch without the other patches. - -<center>*Darcs will **always** find the smallest set of patches needed to -satisfy dependencies.*</center> -<center>*Darcs does not need to ask you what other patches it needs.*</center> -<br/> -Darcs may need to make changes to F to make it fit in the stable branch (e.g. -change line numbers). We call the new patch F' because it does the -same thing as F but in the context of a different tree: +But F is an important bugfix that should go into the next stable release. Darcs +can figure out if F depends on any changes you made in D or E, and it knows how +to adapt F to work in a branch with a different set of patches (e.g. Darcs +might have to change line numbers). We call this modified patch F' because it +does the same thing as F but in the context of a different tree: hunk ./Patch\32\Reordering.page 24 -<center>*The idea of transforming patches (e.g. F to F') depending on context<br/> -is the key idea behind darcs' Smart Patches.*</center> +Later on, when patches D and E are fully tested, they can be pulled into the +stable branch. Again, Darcs may need to make adjustments (e.g. change line +numbers) so we call the new patches D' and E'. + +> Stable: A B C F' D' E' hunk ./Patch\32\Reordering.page 30 +The key feature here is that Darcs knows how to transform a specific patch so +that it applies to a different tree, allowing you to pick and choose patches +and to apply patches in any order you like. + +A key thing to remember is that **if you apply the same patches in a different +order you will always get the same result.** hunk ./Patch\32\Reordering.page 113 -to modify B a little to make it work for Alice. We call the new patch B': +to modify B to make it work for Alice. We call the new patch B'. hunk ./Patch\32\Reordering.page 144 -feature of darcs' Smart Patches*</center> +feature of Patch Reordering*</center> hunk ./Patch\32\Reordering.page 146 -Darcs' Smart Patches are built upon a solid mathematical foundation called -[Patch Theory](Patch Theory/Index). But you don't need to know Patch Theory to use -darcs. You only need to know that darcs will be reliable and predictable. +Patch Reordering is built on a strong mathematical foundation called +[Patch Theory](Patch Theory/Index). But you don't need to know Patch Theory to +use Darcs. You only need to know that Darcs is reliable and predictable. hunk ./Patch\32\Reordering.page 150 -Example 2: Where other SCMs fear to thread -========================================== -This patch-oriented view is unique to darcs. The ability to transform patches -to apply to a different source tree allows darcs to correctly deal with some -situations which other SCMs would get wrong. Consider the following example -using `git` (nothing against Git): +Example 2: A "complex" merge +============================ +With most traditional version control systems, a lot of mergers that a human +would consider quite simple, are made less simple and often even require human +intervention. Here is one example: hunk ./Patch\32\Reordering.page 156 -<table> - <tr> - <th>Git</th><th>Darcs</th><th>Notes</th> - </tr> -<tr> -<td> -<blockquote> -<pre> -mkdir b1 -cd b1 -git init -echo 1 > num_file -git add num_files -git commit -cd .. -</pre> -</blockquote> -</td> <!-- --> <td> -<blockquote> -<pre> -mkdir d1 -cd d1 -darcs init -echo 1 > num_files -darcs add num_files -darcs record -cd .. -</pre> -</blockquote> -</td> <!-- --> <td> -Create a new project.<br/> -`num_files` says how many<br/>files exist in the project. -</td> -</tr> -<!-- / / / / / / / / --> -<tr> -<td> -<blockquote> -<pre> -git clone b1 b2 -cd b2 -echo 'hi' > foo -echo 2 > num_files -git add foo num_files -git commit -cd .. -</pre> -</blockquote> -</td> <!-- --> <td> -<blockquote> -<pre> -cp -r d1 d2 -cd d2 -echo 'hi' > foo -echo 2 > num_files -darcs add foo -darcs record -cd .. -</pre> -</blockquote> -</td> <!-- --> <td> -Create a new branch.<br/> -Add file `foo`<br/> -Update `num_files`<br/> -</td> -</tr> -<!-- / / / / / / / / --> -<tr> -<td> -<blockquote> -<pre> -cd b1 -echo 'hi' > bar -echo 2 > num_files -git add bar num_files -git commit -git pull ../b2 -</pre> -</blockquote> -</td> <!-- --> <td> -<blockquote> -<pre> -cd d1 -echo 'hi' > bar -echo 2 > num_files -darcs add bar -darcs record -darcs pull ../d2 -</pre> -</blockquote> -</td> <!-- --> <td> -Back in the first branch.<br/> -Add file `bar`<br/> -Update `num_files`<br/> -Merge with branch 2. -</td> -</tr> -</table> +1) Alice creates a new repository which creates a new file called Foo.txt hunk ./Patch\32\Reordering.page 158 +2) Bob pulls from Alice and he renames Foo.txt to Bar.txt hunk ./Patch\32\Reordering.page 160 -Git happily merges the branches, creating a broken repository (num_files has the -value 2 but there are 3 files). On the other hand, Darcs correctly detects the -potential conflict in having two patches tht make the same change. +3) Meanwhile, Alice adds content to Foo.txt hunk ./Patch\32\Reordering.page 162 -Most SCMs would get this wrong because they work by looking at differences -between branches. The only difference between these branches is the files `foo` -and `bar`, so the SCM happily merges. Darcs keeps track of individual patches. -When merging, Darcs tries to apply the same patches to the new branch. This way, -darcs can see that two patches are making the same change and issue a warning. +What happens if Bob wants Alice's changes? Sounds straight forward, right? Well, +in Darcs it *IS*. But in a different VCS (e.g. Mercurial) you have "a branch +with two heads" and you have to make a specific merge operation, and that +operation becomes part of the repository's "history". These concepts are not +intuitive to the human developer. A human simply says "I want feature X". hunk ./Patch\32\Reordering.page 168 +As you can see, there is a mismatch between how the traditional VCS thinks +about your work and how you think aobut our work. In contrast, Darcs thinks +the way you do. You think in terms of "I want feature X" and so does Darcs. hunk ./Patch\32\Reordering.page 174 -You don't need to know anything else about Smart Patches to use darcs. -However, if you would like to dig deeper into the theory behind Smart Patches, -you are welcome to read about [Patch Theory](Patch Theory/Index). +You don't need to know anything else about Patch Reordering to use darcs. +However, if you would like to dig deeper into the theory behind Darcs, you are +invited to read about [Patch Theory](Patch Theory/Index). [Rev #1: Patch Theory Intro page. [email protected]**20090413215335] hunk ./Patch\32\Theory/Intro.page 9 -Remember matrices from school? -============================== -Did you learn matrix algebra in school? If you liked it, you can think of patch -theory as being similar to matrix algebra. If you didn't like it, don't read -this paragraph. :-) +In this page we introduce the core concepts of Patch Theory. If you learned +matrix algebra in school and you enjoyed it, it might help you to think of +patch theory as being similar (but simpler). hunk ./Patch\32\Theory/Intro.page 77 -**Exercise**: Prove theorem 1. +**Exercise 1-1**: Prove theorem 1. \[[Answer](Answers#exercise-1-1)\] hunk ./Patch\32\Theory/Intro.page 135 -**Exercise**: Write down the commutation rules for a Hunk and a Move. +**Exercise 1-2**: Write down the commutation rules for a Hunk and a Move. \[[Answer](Answers#exercise-1-2)\] hunk ./Patch\32\Theory/Intro.page 156 -**Exercise**: How would you write the invest of a Hunk? +**Exercise 1-3**: How would you write the inverse of a Hunk? \[[Answer](Answers#exercise-1-3)\] [Rev #1: Patch Theory Examples Revisited page. [email protected]**20090413221617] hunk ./Patch\32\Theory/Examples\32\Revisited.page 5 - <td>Prev:[Intro]()</td><td>Up:[Index]()</td><td>Next:[]()</td> + <td>Prev:[Intro]()</td><td>Up:[Index]()</td><td>Next:[Answers]()</td> hunk ./Patch\32\Theory/Examples\32\Revisited.page 10 -saw in the [Smart Patches](../Smart Patches) page and figure out why darcs +saw in the [Patch Reordering](../Patch Reordering) page and figure out why darcs hunk ./Patch\32\Theory/Examples\32\Revisited.page 17 -introductory page [Smart Patches](../Smart Patches). In this example, we are +introductory page [Patch Reordering](../Patch Reordering). In this example, we are hunk ./Patch\32\Theory/Examples\32\Revisited.page 135 -in the page on [Smart Patches](../Smart Patches). +in the page on [Patch Reordering](../Patch Reordering). hunk ./Patch\32\Theory/Examples\32\Revisited.page 139 -Example 2 is interesting because we want to figure out, not why a merge suceeds -but why it it fails. We have two branches, and in each branch we make different -changes: +Take a second look at example 2 in the [Patch Reordering](../Patch Reordering) +page. This time we write the patches explicitly. hunk ./Patch\32\Theory/Examples\32\Revisited.page 142 +1) Alice creates a new repository (patch X) which creates a new file called Foo.txt + +`Alice: X` + +2) Bob pulls from Alice and he renames Foo.txt to Bar.txt + hunk ./Patch\32\Theory/Examples\32\Revisited.page 150 - <th colspan="2">Patch A</th><th colspan="2">Patch B</th> - </tr> - <tr> - <td>Patch A1:</td> - <td><blockquote><pre>`Add File` bar</pre></blockquote></td> - <td>Patch B1:</td> - <td><blockquote><pre>`Add File` foo</pre></blockquote></td> - </tr> - <tr> - <td>Patch A2:</td> - <td><blockquote><pre>bar 1<br/>+ hi</pre></blockquote></td> - <td>Patch B2:</td> - <td><blockquote><pre>foo 1<br/>+ hi</pre></blockquote></td> - </tr> - <tr> - <td>Patch A3:</td> - <td><blockquote><pre>num_files 1<br/>- 1<br/>+ 2</pre></blockquote></td> - <td>Patch B3:</td> - <td><blockquote><pre>num_files 1<br/>- 1<br/>+ 2</pre></blockquote></td> + <td>`Bob: X B`</td><td> -> </td> + <td>`Move Foo.txt Bar.txt`</td> hunk ./Patch\32\Theory/Examples\32\Revisited.page 155 -We try to appply patch B on top of patch A. (1) Calculate $B^{-1}$, -(2) Commute $B^{-1}$ and $A$. (3) Use $B^{-1} A = A' B'^{-1}$. - -**Calculate** $B^{-1}$ using theorem 1: -$B^{-1} = (B1 B2 B3)^{-1} = B3^{-1} B2^{-1} B1^{-1}$ +3) Meanwhile, Alice adds content to Foo.txt hunk ./Patch\32\Theory/Examples\32\Revisited.page 159 - <th colspan="2">Patch B</th><th colspan="2">Patch $B^{-1}$</th> - </tr> - <tr> - <td>Patch B1:</td> - <td><blockquote><pre>`Add File` foo</pre></blockquote></td> - <td>Patch $B3^{-1}$:</td> - <td><blockquote><pre>num_files 1<br/>- 2<br/>+ 1</pre></blockquote></td> - </tr> - <tr> - <td>Patch B2:</td> - <td><blockquote><pre>foo 1<br/>+ hi</pre></blockquote></td> - <td>Patch $B2^{-1}$:</td> - <td><blockquote><pre>foo 1<br/>- hi</pre></blockquote></td> - </tr> - <tr> - <td>Patch B3:</td> - <td><blockquote><pre>num_files 1<br/>- 1<br/>+ 2</pre></blockquote></td> - <td>Patch $B1^{-1}$:</td> - <td><blockquote><pre>`Remove File` foo</pre></blockquote></td> + <td>`Alice: X A`</td><td> -> </td> + <td>`Foo.txt 1`<br/>`+ Hello`</td> hunk ./Patch\32\Theory/Examples\32\Revisited.page 163 + +The process to merge these is the same as in example 1: (1) Calculate $B^{-1}$, +(2) Commute $B^{-1}$ and $A$. (3) Use $B^{-1} A = A'B'^{-1}$. To get Alice's +changes into Bob's tree we just apply $A'$. + +<table> + <tr><th>Patch $B$</th><th>Patch $B^{-1}$</th><th>Patch $B^{-1}A$</th></tr> + <tr> + <td>`Move Foo.txt Bar.txt`</td> + <td>`Move Bar.txt Foo.txt`</td> + <td>`Move Bar.txt Foo.txt`<br/>-----------------<br/>`Foo.txt 1`<br/>`+ Hello`</td> + </tr> +</table> + +In exercise 1-2 you learned how to commute a `Move` and a `Hunk` +[Exercise Answer](Answers#exercise-1-2). + + +<table> + <tr><th>$B^{-1}A$</th><th>$A'$$B'^{-1}$</th><th>$A'$</th></tr> + <tr> + <td>`Move Bar.txt Foo.txt`<br/>-----------------<br/>`Foo.txt 1`<br/>`+ Hello`</td> + <td>`Bar.txt 1`<br/>`+ Hello`<br/>-----------------<br/>`Move Bar.txt Foo.txt`</td> + <td>`Bar.txt 1`<br/>`+ Hello`</td> + </tr> +</table> + +Now we have the $A'$ that Bob's computer needs to apply in order to obtain +Alice's changes. hunk ./Patch\32\Theory/Examples\32\Revisited.page 193 -Then we try to commute $B^{-1} A = B3^{-1} B2^{-1} B1^{-1} A1 A2 A3$. We -quickly run into a problem when we get to the step where we have to commute -$B3^{-1}$ and $A3$ as they are boht Hunks that affect the same file and the -same line. Therefore, the commutation fails and so the merge fails. Context: [Add Patch Theory Examples Revisited page. [email protected]**20090412120342] [Add Patch Theory Intro page. [email protected]**20090412120322] [Add Path Theory Index page. [email protected]**20090412120235] [Add Patch Theory directory. [email protected]**20090412120200] [Addd Smart Patches page. [email protected]**20090412120127] [Add Download page. [email protected]**20090412120055] [Add Easy page. [email protected]**20090412120023] [Add Editing page [email protected]**20090412120000] [Add Contribute page [email protected]**20090412115853] [Edit Front Page [email protected]**20090412115810] [Tweak darcs send instructions and give away the access code. Eric Kow <[email protected]>**20090410234827 Ignore-this: ad930f4ee744eec54b9896761db1e517 ] [Fix conflict between changes from gwern and me. Eric Kow <[email protected]>**20090410233856 Ignore-this: e9556bd0cb1cf93b5e52b641e34f4775 ] [2009-04-05 Guillaume Hoffmann <[email protected]>**20090405201241 Ignore-this: ea1286d07db1353871f3d02f2c4dce38 ] [use real name instead of email address Guillaume Hoffmann <[email protected]>**20090329190624 Ignore-this: 1b02353ef73bd9344a1a8d1fe37fbeb7 ] [2009-03-29 Guillaume Hoffmann <[email protected]>**20090329185900 Ignore-this: 6b958e329253b3ff6c56f2f47b6e1716 ] [entries/2009-03-22 Guillaume Hoffmann <[email protected]>**20090322115706 Ignore-this: 1e592b94017b87fd7035d89f2c2c8402 ] [entries/2009-03-15 Guillaume Hoffmann <[email protected]>**20090315204111 Ignore-this: 1bfba012e4be8159fd98ad36fae152ad ] [entries/2009-03-08 Guillaume Hoffmann <[email protected]>**20090308125015 Ignore-this: 1bb10ed850704b8df46d59a785de171f ] [Rename FrontPage to 'Front Page' Eric Kow <[email protected]>**20090215192824 Ignore-this: 2afa590c5f49f7bec96a4a6dce576cc7 ] [Front page for gitit Eric Kow <[email protected]>**20090215192528 Ignore-this: f99e5ccb2d39f2438d6dfbe05c99b01b ] [Rename all entries so far with a .page extension (for gitit) Eric Kow <[email protected]>**20090215191108 Ignore-this: 84c3f234fea46c2f89652dd8c761c2e8 ] [entries/2009-03-01 Guillaume Hoffmann <[email protected]>**20090301205408 Ignore-this: f29fffefb2a1bea4d773558abfcb6575 ] [2009-02-23 oops, forgot the fundraising Guillaume Hoffmann <[email protected]>**20090223083329 Ignore-this: a3ce15cbda599ae79d0a0cb32a298043 ] [2009-02-23 Guillaume Hoffmann <[email protected]>**20090223082118 Ignore-this: a8bd3b10b22e39f936ccdd0f9fdf7fc9 ] [entry 2009-02-13 Guillaume Hoffmann <[email protected]>**20090213160528 Ignore-this: 585544e7ff0010890c1b577d6d153763 ] [entry 2009-02-07 Guillaume Hoffmann <[email protected]>**20090207141152 Ignore-this: d688bffee8f7074de755997050f55539 ] [dwn #15 Guillaume Hoffmann <[email protected]>**20090131104509 Ignore-this: be71c4b3912a3c83f80f41ea8e1220d3 ] [Add the template (oops) Eric Kow <[email protected]>**20090126120412 Ignore-this: cb5bf57b0709d2c652000748b2a54ae2 ] [Wibble Eric Kow <[email protected]>**20090123180218 Ignore-this: 37023dad89e48081351456cb5b373f02 ] [Get rid of excess space in blog output Eric Kow <[email protected]>**20090123180205 Ignore-this: 3250a70a1c893c9ce30da4678199e853 ] [dwn #14 - catch up edition Eric Kow <[email protected]>**20090123175514 Ignore-this: a047fcf79e7ed5140eb92fb571626d58 ] [Tweak instructions for generating lastchanges Eric Kow <[email protected]>**20090123175452 Ignore-this: 1538782e03c013d88b74f5ea4607945c ] [foo [email protected]**20090117190300 Ignore-this: 6bdd0aa849634c8cd35c28d8e5e8d18a ] [foo [email protected]**20090117190001 Ignore-this: 92a1e811555a2aa1d25da0eec910c071 ] [foo [email protected]**20090117175048 Ignore-this: b808d126678bddd2a85546636e16aa54 ] [Make it a tad easier to get started Eric Kow <[email protected]>**20090117141833 Ignore-this: 85b84bd6769f90c6aec1c33957080c27 ] [More thoughts on workflow (collecting news items) Eric Kow <[email protected]>**20090117141607 Ignore-this: 914ca360336fa1a3aa368996d3ed8a8d ] [Clarify README Eric Kow <[email protected]>**20090116182254 Ignore-this: 8fdec1d728dd29332b83232a19e93c7c ] [Tweak workflow Eric Kow <[email protected]>**20090116182210 Ignore-this: 3afd500fec18d7692295646a12d0530a ] [Rename getchanges to createstub Eric Kow <[email protected]>**20090116182156 Ignore-this: cfa24b2158a7cc3cf664daa4a4672ee2 ] [getchanges.sh should only focus on getting the most recent changes Eric Kow <[email protected]>**20090116175945 Ignore-this: 1b7d7acc2704fe2e943f458b57a23da1 ] [add automated bits to 2008-11-22 Jason Dagit <[email protected]>**20081123051747 Ignore-this: b85341a4e17abb2f00cf52ab81e1436b ] [add entry for 2008-11-22 Jason Dagit <[email protected]>**20081123051516 Ignore-this: 798ff5a9ae859da9f1696adb6597eb74 ] [typo Jason Dagit <[email protected]>**20081117081447] [formatting fixes for 2008-11-16 Jason Dagit <[email protected]>**20081117081123] [add 2008-11-16 Jason Dagit <[email protected]>**20081117013638] [update README Jason Dagit <[email protected]>**20081117013624] [added note to readme Jason Dagit <[email protected]>**20081111181725] [add a simple README Jason Dagit <[email protected]>**20081111181546] [Actuaually, we have resolved an issue Eric Kow <[email protected]>**20081107101233 Ignore-this: 1a73cdfa52495e3bc4907a5666d0d274 ] [dwn #11 Eric Kow <[email protected]>**20081107101043 Ignore-this: 6dc4955b35c99c9b50f95181be84876 ] [DWN #11 beginning Eric Kow <[email protected]>**20081107085702] [dwn #10 Eric Kow <[email protected]>**20081030143039] [Whoops! URL paste-o in dwn #9 Eric Kow <[email protected]>**20081023101542] [oops! missed a new contributor Eric Kow <[email protected]>**20081023095750] [dwn #9 Eric Kow <[email protected]>**20081023095547] [wibble Eric Kow <[email protected]>**20081016220550] [Improve dwn #8 Eric Kow <[email protected]>**20081016215534] [tweak to lastentry obtention Eric Kow <[email protected]>**20081016190236] [dwn #8? Eric Kow <[email protected]>**20081016190228] [dww #7 tweaks Eric Kow <[email protected]>**20081016190218] [Tweak dwn #7 Eric Kow <[email protected]>**20081009222635] [dacrs weekly news #7 Eric Kow <[email protected]>**20081009221031] [Tweak the blog entry creation. Eric Kow <[email protected]>**20081002163152] [More suggestions from Florent. Eric Kow <[email protected]>**20081002160715] [Tweak #6 again (with Florent's ideas) Eric Kow <[email protected]>**20081002160321] [Tweaks to dwn #6 Eric Kow <[email protected]>**20081002155841] [darcs weekly news #6 Eric Kow <[email protected]>**20081002155304] [Use a dumb perl script to help tweak the entry for my blog. Eric Kow <[email protected]>**20080925103115] [Credit Vlad for the issue1041 fix Eric Kow <[email protected]>**20080925094506] [wibble Eric Kow <[email protected]>**20080925094255] [Add dwn #5 Eric Kow <[email protected]>**20080925094158] [Add one more news item for DWN #4 Eric Kow <[email protected]>**20080918102258] [DWN #4 Eric Kow <[email protected]>**20080918101757] [Call pandoc automatically with the right options. Eric Kow <[email protected]>**20080918101732] [Drop last patch in parsechanges (redundant with last week). Eric Kow <[email protected]>**20080918101651] [Whoops, misplaced links in dwn #3 Eric Kow <[email protected]>**20080910092207] [Use ReStructured Text in parsechanges.hs Eric Kow <[email protected]>**20080910091524] [Add issue/patch entries for dwn #3 Eric Kow <[email protected]>**20080910091457] [dwn #3 progress Eric Kow <[email protected]>**20080910090801] [News for dwn #3 Eric Kow <[email protected]>**20080910085713] [dwn #2 first draft Eric Kow <[email protected]>**20080903082538] [Get changes from a named patch; not trusting dates. Eric Kow <[email protected]>**20080903081219 Patch date does not have any relation with push date. ] [Use reStructured text markup for dwn #2 Eric Kow <[email protected]>**20080903081033] [Reviewers for 2008-09-03 Eric Kow <[email protected]>**20080902220359] [Entry for dwn #2 Eric Kow <[email protected]>**20080901215747] [Use official http://darcs.net for changes. Eric Kow <[email protected]>**20080827105314 Avoid the mistake of grabbing anybody's draft code. ] [Avoid showing email address in output. Eric Kow <[email protected]>**20080827104110] [Don't show email addresses in darcs news. Eric Kow <[email protected]>**20080827104040 Not a question of privacy, just prettiness ] [finish a sentence Eric Kow <[email protected]>**20080827103734] [Integrate fancier issue output into first entry Eric Kow <[email protected]>**20080827103525] [Fancier still. Eric Kow <[email protected]>**20080827103451] [Fancier issue printing Eric Kow <[email protected]>**20080827103233] [Bullets Eric Kow <[email protected]>**20080827102231] [Wibble Eric Kow <[email protected]>**20080827102159] [Wibble Eric Kow <[email protected]>**20080827101930] [Fix script and pipe to parsechanges Eric Kow <[email protected]>**20080827101915] [First week's entry Eric Kow <[email protected]>**20080827101904] [Wibble Eric Kow <[email protected]>**20080827100315] [Tweak first entry Eric Kow <[email protected]>**20080827100206] [Case Eric Kow <[email protected]>**20080827100202] [Begin entry for first darcs weekly news. Eric Kow <[email protected]>**20080827100056] [Add archive of entries. Eric Kow <[email protected]>**20080827095945] [Also print issues resolved. Eric Kow <[email protected]>**20080827095922] [Initial version. Eric Kow <[email protected]>**20080827094739] Patch bundle hash: d5411a623b38e38604f036e396ea24275a9d4742
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
