planet

News and discussions

1. Darcs has received two grants from the Google Summer of Code program, as part of the umbrella organization Haskell.org. Alejandro Gadea will work on history reordering:
   
   • http://alegdarcs.blogspot.com.ar/2014/05/google-summer-of-code-2014-darcs.html
2. Marcio Diaz will work on the cache system:
   
   • http://marcioodiaz.blogspot.com.ar/2014/04/gsoc-project-accepted.html
   • http://marcioodiaz.blogspot.com.ar/2014/04/gsoc-progress-report-1-complete.html
3. Repository cloning to remote ssh hosts has been present for years as darcs put. This feature has now a more efficient implementation:
   
   • http://hub.darcs.net/darcs/darcs-reviewed/patch/20140425060647-5ef8f

Issues resolved (11)

issue851 Dan Frumin

• interactive mode for whatsnew
• http://bugs.darcs.net/issue851

issue1066 Guillaume Hoffmann

• clone to ssh URL by locally cloning then copying by scp
• http://bugs.darcs.net/issue1066

issue1268 Guillaume Hoffmann

• enable to write darcs init x
• http://bugs.darcs.net/issue1268

issue1416 Ale Gadea

• put log files in tempdir instead of in working dir.
• http://bugs.darcs.net/issue1416

issue1987 Marcio Diaz

• Garbage collection for inventories and patches.
• http://bugs.darcs.net/issue1987

issue2263 Ale Gadea

• Option --set-scripts-executable is not properly documented
• http://bugs.darcs.net/issue2263

issue2345 Dan Frumin

• solution using cabal's checkForeignDeps
• http://bugs.darcs.net/issue2345

issue2357 Dan Frumin

• switching to regex-compat-tdfa for unicode support
• http://bugs.darcs.net/issue2357

issue2365 Guillaume Hoffmann

• correctly copy pristine in no-working-dir clones
• http://bugs.darcs.net/issue2365

issue2367 Guillaume Hoffmann

• rename amend-record to amend, make --unrecord more visible
• http://bugs.darcs.net/issue2367

issue2379 Guillaume Hoffmann

• only use packs to copy pristine when up-to-date
• http://bugs.darcs.net/issue2379

Patches applied (41)

See darcs wiki entry for details.

News and discussions

1. We are in the feature freeze period of darcs 2.10:

• http://lists.osuosl.org/pipermail/darcs-users/2014-November/027056.html

2. Our two Summer of Code projects ended up two months ago. Marcio and Ale's code will be part of the upcoming new stable version of darcs. In case you missed them, here are the latest posts of Marcio for his project:

• http://marcioodiaz.blogspot.com.ar/2014/07/gsoc-progress-report-3-bucketed-global_23.html
• http://marcioodiaz.blogspot.com.ar/2014/07/gsoc-progress-report-4-garbage.html
• http://marcioodiaz.blogspot.com.ar/2014/07/gsoc-progress-report-5-starting.html

3. Ale's posts:

• http://alegdarcs.blogspot.com.ar/2014/07/month-of-june.html
• http://alegdarcs.blogspot.com.ar/2014/07/some-week-14-19-july.html
• http://alegdarcs.blogspot.com.ar/2014/07/other-week-21-26-july.html
• http://alegdarcs.blogspot.com.ar/2014/08/last-few-weeks.html

Issues resolved (7)

issue1514 Guillaume Hoffmann

• send --minimize-context flag for send
• http://bugs.darcs.net/issue1514

issue1624 Marcio Diaz

• bucketed cache.
• http://bugs.darcs.net/issue1624

issue2153 Andreas Brandt

• allow skipping backwards through depended-upon patches
• http://bugs.darcs.net/issue2153

issue2249 Mateusz Lenik

• Rename isFile to isValidLocalPath and WorkRepoURL to WorkRepoPossibleURL
• http://bugs.darcs.net/issue2249

issue2380 Owen Stephens

• allow darcs mv into known, but deleted in working, file
• http://bugs.darcs.net/issue2380

issue2403 Ganesh Sittampalam

• need to avoid moving the rebase patch to the end
• http://bugs.darcs.net/issue2403

issue2409 Ganesh Sittampalam

• implement darcs rebase apply
• http://bugs.darcs.net/issue2409

Patches applied (118)

See darcs wiki entry for details.

In the last three weeks I was working in a couple of things, unfortunately I couldn't complete any to 100% :

- Finishing the command minimize-context.
- Implement the "show dependencies" for darcsden.
- Solve the issue2405.

Finish the command minimize-context

I can start telling that the command itself is implemented, but making tests I find out a case when making minimize-context fails to update correctly the files of repository. I comment the problem in here, however here goes a little summary.

Some "preconditions" to take into account:
1. If exist a tag, I search for dependencies in the patchs after the tag.
2. If happends that not exist dependencies after the tag, the only patch in the context of the bundle to send is the tag. This helps the command darcs apply to merge the patches and seems good to have at least a "tag patch" dependency.
3. (In relation with 1) If not exist a tag, the search is made in all the repository. One problem here is that with repositories that have huge amount of patches (darcs for example with 11000~ patches) the command maybe not finish of calculate the dependencies. Hopefully, having so many patches without tags seems a little odd. Nevertheless, I suppose that even the search in 700~ patches of 10~ patches to send should have a decent performance.

Well, passing to comment the problem. In some older post I mention the way we calculate the dependencies, so with that in mind, suppose we have to repositories $r_1$, $r_2$ with the following patches, where $m_x$ and $a_x$ represents the $x$-th modification and adding respectively.

$r_1$,$r_2$ = $m_2$ $tag$ $m_1$ $a_1$

suppose now that $r_2$ makes a third modification $m_3$ that adds lines without touch any existing line in the only file adding for $a_1$ and sequentially modified for $m_x$. With the idea of send a bundle to $r_1$. Now if we compute the dependencies to find out what is the context to send. For (1) we need to try to commute $m_2$ with $m_3$, which success but of course the end result is a $m'_3$ and a $m'_2$ because the lines which modifies every one now are different. But beyond that for our definition of dependency we can throw $m_2$, so the final context of the bundle with minimize context is the patch $tag$.
The problem now is that if we make darcs apply of the minimized bundle the merge is made not considering $m_2$ and the final state of the file isn't right. For example, if we are talking about that $m_3$ adds a function in some empty place, this could end in $m_3$ adding the function in the middle of an existing function.

My, more or less, mature thought is something like have Direct Dependency and  Indirect Dependency (the names could be differents $\smile$). The Direct Dependency is a dependency as already we know it and the Indirect Dependency is that if we have,
$p_1$ and $p_2$ patches, and $p'_1$ and $p'_2$  are the results of commute the patches, then if $p_1 \ne p'_1$ we conclude that $p_1$ indirectly depends of $p_2$.

I have almost implemented this idea, but I change task and still missing a couple of details. In particular, I'm not so sure of a couple of things,
- How to correctly compare the patches ($p_1 \ne p'_1$)
- In my unclean implementation I have to carry on $MyEq$ for all over the code and it's very ugly I think.

Finishing with this topic, here is a script (improved by Guillaume) that shows the problem:

Link: http://hub.darcs.net/alegadea/ExamplesRepos
SH: getDepsDoesntAlwaysWork.sh

Implement the "show dependencies" for darcsden

An idea that quickly comes up to my mind is that, considering the last part of the previous topic, since we have two types of dependencies it would be nice generate the graph of dependencies with two types of arrows to differentiate the type of dependency between patches. Talking about the implementation itself, I advanced in the drawing of the graph and some different presentations, but very little about the integration with darcsden, which I think is more or less direct having implemented the $js$ that draw the graph. Would have been nice have more time for finish this but I swap to the task of the following topic.

I hope be able to work in the last two topics in the next few months outside of the GSoC.

Solve the issue2405

I would like to start saying, "what a shame...". I can't solve the issue, I improve a little bit the memory but nothing too much significant. Maybe the good news is that, more o less, I found the "place" in the code where the memory triggers "to the sky" :)
Now, the reality is that I tried so many things that I'm a little bit confused about everything. So, I gonna comment the last feelings and tests that I make and, any question(or idea) for the future person (maybe me) that would try to solve the issue, it would well received.
So things that I tried to change:

- Strict version of Map, Monad, etc.
- More strict version of mapM_, gets and modify.
- Some partials changes in the data type PatchIndex.
- Using darcs as library; differents uses of the functions...

The "place" that I suspect the code has the memory glitch is in $applyPatchMods \rightarrow go (pid, PTouch fn)$. I think that my lack of experience dealing with this kind of problem comes to light :) the
bright side is that I learn many things on the way of understand the problem and try different solutions.

Closing, maybe this could be my last post in a long time. I would like to thanks Guillaume and the darcs community in general. It was great to contribute to the development of darcs!

Again, I hope be able to work a little outside the GSoC, in particular in the "dependency problems and tasks".

Thanks!

Good news!

I almost finish to implement the option minimize-context for the command darcs send, I say almost because making some examples I find out that somethings could go wrong. But before entering in that, I will comment a little the main the test that without minimize-context doesn't work and with the option passes(when the implementation is ready the most likely is I will upload the example and some more in ExamplesRepos), and some "tentatives options" for darcs send that I think could be useful.

So, the minimal example:

Suppose we have repositories $r_1$, $r_2$ and $r_3$; $r_2$ a direct clone of $r_1$ where
originally $r_1$ has only one patch, 

$r_1$,$r_2$ $=$ $p_0$

now, we add a patch with a new file in $r_1$ and make a clone, $r_3$ which leave the repositories like this,

$r_1$,$r_3$ $=$ $p_0$ $p_1$

Suppose that we make a modification in the file that add $p_0$ and make a patch $p'_0$ in $r_1$ and we send a bundle (with darcs send) to $r_2$ and $r_3$. What ends up happening is what one imagine,
the bundle can be applied to $r_3$ but not to $r_2$, this because the bundle has de following "shape":

Some message

patch [Some hash]
Author: ...
Date: ...
  * [The modification to $p_0$]

New patches:

$p'_0$

Context:

$p_1$
$p_0$

Patch bundle hash: [Some hash]

Hi all!

I was finishing understanding and implementing the command darcs send --minimize-context using "optimize reorder" when I begin to suspect that doesn't solve the problem described in here. The thing is, despite the fact that the context in the bundle to send is reduced if before we send we make "optimize reorder", this doesn't solve the problem of dependencies. Guillaume finished of evacuate my doubts, and so after read:

- [darcs-users] darcs cannot apply some patch bundles
- irclog
- issue1514 (which is the issue which "replace" issue2044 darcs send should do optimize --reorder)

I convince myself of what needs to be done, and it's calculate the "exact" dependencies of the patches to send so such dependencies be the context in the bundle to send. "Exact" because for big repositories can be very costly and calculate till certain tag seem appropriate.

Now, one concern is the cost of doing the search of dependencies. About this I can first comment some of the things I was doing during the week and later show, what I think are, encouraging examples. So first, maybe the most relevant thing of the week it's the implementation of the command darcs show dependencies with the following "description":

Usage: darcs show dependencies [OPTION]... 
Generate the graph of dependencies.


Options:
              --from-match=PATTERN  select changes starting with a patch matching PATTERN
              --from-patch=REGEXP   select changes starting with a patch matching REGEXP
              --from-tag=REGEXP     select changes starting with a tag matching REGEXP
              --last=NUMBER         select the last NUMBER patches
              --matches=PATTERN     select patches matching PATTERN
  -p REGEXP   --patches=REGEXP      select patches matching REGEXP
  -t REGEXP   --tags=REGEXP         select tags matching REGEXP
              --disable             disable this command
  -h          --help                shows brief description of command and its arguments

till the moment the command returns a graph described in dot language, this can eventually change. But with the current returned value one can do:

$\$$ darcs show dep | dot -Tpdf -o deps.pdf

to draw the graph in a pdf. Finally, in summary to calculate the dependencies I use more or less the idea which describes Ganesh in here.

Moving to the examples is interesting, thinking in the performance of the implementation of darcs send --minimize-context using this approach, to see the followings results:

1. Show the dependencies after the tag 2.9.9 (75 patches)
$ time darcs show dep --from-tag=2.9.9
real 0m0.397s
user 0m0.373s
sys 0m0.026s
darcsDesps299.pdf
real 0m2.951s
user 0m2.865s
sys 0m0.082s
darcsDesps298.pdf

3. Show the dependencies after the tag 2.9.7 (288 patches)
$ time darcs show dep --from-tag=2.9.7
real 0m26.654s
user 0m26.003s
sys 0m0.511s
darcsDesps297.pdf

4. Show the dependencies after the tag 2.9.6 (358 patches)
$ time darcs show dep --from-tag=2.9.6
real 0m39.019s
user 0m38.302s
sys 0m0.666s
darcsDesps296.pdf
5. Show the dependencies after the tag 2.9.5 (533 patches)
$ time darcs show dep --from-tag=2.9.5
real 1m53.730s
user 1m51.343s
sys 0m1.939s
darcsDesps295.pdf

I'm starting with the implementation of the command darcs undo.
For now it's quite simple, it just use a copy of the previous hashed_inventory.

But, for example, with the current implementation we can undo amend-record:

$ mkdir test
$ cd test/
$ darcs init
Repository initialized.

$ touch f g; darcs add f g
Adding 'f'
Adding 'g'

$ darcs record
addfile ./f
Shall I record this change? (1/2)  [ynW...], or ? for more options: y
addfile ./g
Shall I record this change? (2/2)  [ynW...], or ? for more options: n
Do you want to record these changes? [Yglqk...], or ? for more options: y
Finished recording patch 'add f'

$ darcs whatsnew
addfile ./g

$ darcs amend-record
Thu Jul 24 00:07:53 ART 2014  Marcio Diaz <***>
  * add f
Shall I amend this patch? [yNjk...], or ? for more options: y
addfile ./g
Shall I record this change? (1/1)  [ynW...], or ? for more options: y
Do you want to record these changes? [Yglqk...], or ? for more options: y
Finished amending patch:
Thu Jul 24 00:08:17 ART 2014  Marcio Diaz <***>
  * add f

$ darcs whatsnew
No changes!

$ darcs undo

$ darcs whatsnew
addfile ./g

$ darcs changes
Thu Jul 24 00:07:53 ART 2014  Marcio Diaz <***>
  * add f 

http://bugs.darcs.net/patch1182.
 

The implementation of the command darcs optimize global-cache is almost finished.

This command can reduce the size of the global cache and at the same time we can select which files we want to keep in the cache.

The command darcs optimize global-cache takes directories as arguments, search repositories within them and delete all files in the global cache that are not being used by these repositories.

$ time darcs clone http://darcs.net
Welcome to the darcs screened repository.
...
Finished cloning.

real    8m16.042s
user    0m36.568s
sys    0m9.807s
  
The second time, because it use the global cache, it takes only 26 seconds:

$ time darcs clone http://darcs.net
Welcome to the darcs screened repository.
...
Finished cloning.

real    0m26.230s
user    0m15.293s
sys    0m2.891s
 
But we have a pretty heavy cache (we have other repositories besides darcs.net):

$ du -sh ~/.cache/darcs/inventories/
277M    /home/marcio/.cache/darcs/inventories
$ du -sh ~/.cache/darcs/patches/
325M    /home/marcio/.cache/darcs/patches/
$ du -sh ~/.cache/darcs/pristine.hashed/
279M    /home/marcio/.cache/darcs/pristine.hashed/

If we need to free memory, we can delete the entire cache using:

rm -rf ~/.cache/darcs/ 

but the next time we make a clone of http://darcs.net it'll take again 8 minutes.

So, how can we liberate memory from the global cache and at the same time make darcs clones of http://darcs.net that only take 26 seconds?

Using darcs optimize global-cache:

$ time darcs optimize global-cache darcs.net 
Done cleaning global cache!

real    0m36.668s
user    0m15.492s
sys    0m7.932s

It takes 36 seconds to clean the cache, leaving only the necessary files for the repository darcs.net:

$ du -sh ~/.cache/darcs/inventories
21M    /home/marcio/.cache/darcs/inventories
$ du -sh ~/.cache/darcs/patches/
69M    /home/marcio/.cache/darcs/patches/
$ du -sh ~/.cache/darcs/pristine.hashed/
23M    /home/marcio/.cache/darcs/pristine.hashed/ 
 
$ time darcs clone http://darcs.net
Welcome to the darcs screened repository.
...
Finished cloning.

real    0m26.173s
user    0m15.164s
sys    0m2.905s

I finished the implementation of the bucketed cache.
Now users can run darcs optimize cache and migrate the old cache to the new bucketed cache.

For example, if we have a cache like in the next figure:  
 

 Running darcs optimize cache makes the cache as follows:

After my trip to France I'm back working on the Google Summer of Code for darcs.

My goals this week are to finish my patches for bucketed cache and garbage collection of the global cache.

Bucketed Cache

Some programs have problems with directories with a lot of files, for example the ls command in linux. In order to reduce the number of files in a folder in the global cache (which can grow considerably), we decided to implement a bucketed global cache.

The patch for the bucketed cache is this: http://bugs.darcs.net/patch1162.
This patch transforms the global cache into a bucketed global cache.
That is, instead of having all the cache files in a single folder, divided them into sub-folders according to the file name.
 
For example, using the first two digits of the hash, we put the patch named:

0000008516-0048abbb8a2b11870fe24fef48bc2ebb49cbd818a633b8250dc2023e4f6267c9

in the sub-folder /00/, i.e., in ~/.cache/darcs/patches/00/. The same with the inventories and pristine files.

However there are several ways to implement this patch:

1. We can forget the old cache (which is located in ~/.darcs/cache/).  
• The advantage of this approach is that the code is more cleaner and faster (not sure if significantly faster), because we don't need to look for patches at multiple locations.
• The disadvantage is that the user will start with an empty cache again.
  Although we can create a command that is responsible for moving the old cache files to the new format.
2. The other way is to read always both caches. The code of this version a little more complicated because it need to read in several locations. But the user cache remains intact.

Different versions of darcs use different global caches:

• 2.9.9 (+45 patches) (last development version): this version can read the caches in ~/.darcs/cache/ and ~/.cache/darcs/ (new cache). In addition, each time the old cache is used, the files are linked with the new cache. However this new cache is not bucketed.
• 2.8.4 (the latest stable release): used by end users, only uses the cache in ~/.darcs/cache/.

The patch in http://bugs.darcs.net/msg17565 change the code of the version 2.9.9 so that, when the old cache is used, darcs link the files read to the new bucketed cache in ~/.cache/darcs/. Also it provides a new command (darcs optimize cache) responsible for moving the files from old caches to the new bucketed cache.

Test were performed to see if the bucketed version of the cache improved the performance in darcs commands like clone, but no significant difference was found.

Global Garbage Collection

This patch should grant mechanisms to the user in order to reduce the size of the global cache according to its needs.

By now this patch only count the number of hard links of the files in the global cache. If a file has only one link, it's deleted.

This patch hasn't been sent to screened yet.

Patch-tag users:

I have made the decision to shut down patch tag.

I’ve taken this step because I have stopped developing on patch tag, the site has a material time and money cost, and the technical aspects that made it a valuable learning experience have decreased to the point that I have hit diminishing returns.

The suggested continuity path is to move repos to Simon Michaels’s excellent hub.darcs.net.

To end on a positive note, I would like to say: no regrets! Creating patch tag was a definite high point of my career, opened valuable doors, and engendered even more valuable partnerships and collaborations. To my users and everyone who has helped, you are awesome and it was a lot of fun seeing the repos come online.

I may write a more in depth post mortem at a later time, but for now I just wanted to make a public statement and nudge remaining users to take appropriate action.

If there is anybody that would like to take over patch tag operations to keep the site going, I am open to handing over the reins so don’t be shy. I floated this offer among some private channels in the darcs community a while back, and the response then was… not overwhelming. But maybe the public announcement will bring in some new blood.

Thanks for using patch tag.

Happy tagging,

Thomas Hartman

News and discussions

1. Google Summer of Code 2013 has begun! BSRK and José will post updates on their blogs:
   
   • http://bsrkaditya.blogspot.com/search/label/darcs
   • http://blog.jlneder.com.ar/search/label/darcs

Issues resolved (8)

issue2163 Radoslav Dorcik

• new option for amend, select author for patch stealing.
• http://bugs.darcs.net/issue2163

issue2227 Ganesh Sittampalam

• move the rebase patch to the end before an amend-record
• http://bugs.darcs.net/issue2227

issue2248 Ganesh Sittampalam

• always clean up rebase-in-progress state
• http://bugs.darcs.net/issue2248

issue2250 BSRK Aditya

• tabbing in usageHelper - pad by max length of command name
• http://bugs.darcs.net/issue2250

issue2311 Sebastian Fischer

• posthook for 'get' should run in created repo
• http://bugs.darcs.net/issue2311

issue2312 Sebastian Fischer

• posthooks for 'record' and 'amend-record' should receive DARCS_PATCHES
• http://bugs.darcs.net/issue2312

issue2320 Jose Luis Neder

• save prompted author name in ~/.darcs/author instead of ./_darcs/prefs/author
• http://bugs.darcs.net/issue2320

issue2321 Jose Luis Neder

• when no patch name given, directly invoke text editor
• http://bugs.darcs.net/issue2321

Patches applied (20)

See darcs wiki entry for details.

News and discussions

1. This year's Google Summer of Code projects brought a lot of improvements to darcs and its ecosystem!
   
   • BSRK Aditya: Darcsden improvements:
     
     • http://joyful.com/blog/2013-09-26-darcsden-darcs-hub-gsoc-complete.html
     • http://bsrkaditya.blogspot.com.ar/2013/09/darcsden-gsoc-final-blog-post.html
   • José Neder: patience diff, file move detection, token replace detection:
     
     • http://lists.osuosl.org/pipermail/darcs-users/2013-October/026945.html
     • http://blog.jlneder.com.ar/search/label/darcs
2. Gian Piero Carrubba asked why adjacent hunks could not commute:
   
   • http://lists.osuosl.org/pipermail/darcs-users/2013-November/026958.html
3. We listed the changes that occurred between version 2.8.4 and the current development branch into a 2.10 release page:
   
   • http://darcs.net/Releases/2.10?revision=20131028184855-5ef8f-ba33870773ad9ee010a470ac8536b5c7ae331b50

Issues resolved (8)

issue346 Jose Luis Neder

• implement "patience diff" from bzr
• http://bugs.darcs.net/issue346

issue1828 Guillaume Hoffmann

• file listing and working --dry-run for mark-conflicts
• http://bugs.darcs.net/issue1828

issue2181 Guillaume Hoffmann

• put cache in $XDG_CACHE_HOME (~/.cache by default)
• http://bugs.darcs.net/issue2181

issue2309 Owen Stephens

• annotate includes line numbers
• http://bugs.darcs.net/issue2309

issue2313 Jose Luis Neder

• whatsnew -l: Stack space overflow
• http://bugs.darcs.net/issue2313

issue2334 Guillaume Hoffmann

• fix win32 build removing file permission functions
• http://bugs.darcs.net/issue2334

issue2343 Jose Luis Neder

• darcs amend-record does not record my change
• http://bugs.darcs.net/issue2343

issue2347 Guillaume Hoffmann

• fix amend-record --prompt-long-comment
• http://bugs.darcs.net/issue2347

Patches applied (39)

See darcs wiki entry for details.

News and discussions

1. Darcs is participating once again to the Google Summer of Code, through the umbrella organization Haskell.org. Deadline for student application is Friday 21st:
   
   • http://darcs.net/GSoC
   • https://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2014/help_page
2. It is now possible to donate stock to darcs through the Software Freedom Conservancy organization. Donations by Paypal, Flattr, checks and wire transfer are still possible:
   
   • http://lists.osuosl.org/pipermail/darcs-users/2013-December/026977.html
   • http://darcs.net/Donations
3. Dan Licata wrote a presentation about Darcs as a higher inductive type:
   
   • http://lists.osuosl.org/pipermail/darcs-users/2014-January/026985.html
4. Darcs now directly provides import and export commands with Git. This code was adapted from Petr Rockai's darcs-fastconvert, with some changes by Owen Stephen from his Summer of Code project "darcs-bridge":
   
   • http://hub.darcs.net/darcs/darcs-screened/patch/20140125154537-5ef8f

Issues resolved (6)

issue642 Jose Luis Neder

• Automatic detection of file renames
• http://bugs.darcs.net/issue642

issue2209 Jose Luis Neder

• Automatically detect replace
• http://bugs.darcs.net/issue2209

issue2319 Guillaume Hoffmann

• make changes non-interactive if fed to a pipe
• http://bugs.darcs.net/issue2319

issue2332 Guillaume Hoffmann

• ignore case of characters in prompt
• http://bugs.darcs.net/issue2332

issue2335 Guillaume Hoffmann

• one liner when adding tracked files if not verbose
• http://bugs.darcs.net/issue2335

issue2348 Ryan

• switch to cabal's test framework
• http://bugs.darcs.net/issue2348

Patches applied (34)

See darcs wiki entry for details.

News and discussions

1. We have a few updates from the Google Summer of Code projects. Alejandro Gadea about history reordering:
   
   • http://alegdarcs.blogspot.com.ar/2014/05/first-week-19-23-may.html
   • http://alegdarcs.blogspot.com.ar/2014/06/second-week-26-30-may.html
   • http://alegdarcs.blogspot.com.ar/2014/06/third-week-02-06-june.html
2. Marcio Diaz about the cache system:
   
   • http://marcioodiaz.blogspot.com.ar/2014/06/gsoc-progress-report-2-bucketed-global.html
3. Incremental fast-export is now provided to ease maintenance of git mirrors:
   
   • http://hub.darcs.net/darcs/darcs-screened/patch/20140609190214-5ef8f

Issues resolved (8)

issue2244 Ale Gadea

• darcs tag should warn about duplicate tags
• http://bugs.darcs.net/issue2244

issue2314 Benjamin Franksen

• output-auto-name in defaults file
• http://bugs.darcs.net/issue2314

issue2361 Ale Gadea

• optimize --reorder runs forever with one repository
• http://bugs.darcs.net/issue2361

issue2364 Sergei Trofimovich

• fix file corruption on double fetch
• http://bugs.darcs.net/issue2364

issue2364 Sergei Trofimovich

• don't break list of 'bad sources'
• http://bugs.darcs.net/issue2364

issue2388 Owen Stephens

• check if inventories dir has been created
• http://bugs.darcs.net/issue2388

issue2394 Guillaume Hoffmann

• make optimize a supercommand
• http://bugs.darcs.net/issue2394

issue2396 Guillaume Hoffmann

• make convert a supercommand and enhance help strings
• http://bugs.darcs.net/issue2396

Patches applied (39)

See darcs wiki entry for details.

Well, well... Now with the solution already implemented here are a couple of time tests that show the improvement.

For the repository of the issue2361:

For the repository generated by forever.sh, that in summarize has 12600~ patches, a bundle unrevert and doing reorden implies move 1100~ patches forward passing by 11500~ patches.


The repository generated by bigRepo.sh has 600~ patches, with only one tag and a very small bundle unrevert.

One last repository generated by bigUnrevert.sh, has 13 patches and a really big bundle unrevert (~10MB).

Luckily, this week with Guillaume we found a "solution" for the issue 2361. But before of entering in details, let's review how the command darcs optimize --reorder does for reorder the patches.

So, suppose we have the following repositories than, reading it from left to right we have the first patch till the last patch, besides with $p_{i,j}$ we denote the $i$-th patch who belongs to the $j$-th repository, and when we want to specify that a patch $p_{i,j}$ is a tag we write $t_{i,j}$.

$r_1$ $=$ $p_{1,1}$ $p_{2,1}$ $\ldots$ $p_{n,1}$ $p_{n+1,1}$ $\ldots$ $p_{m,1}$

$r_2$ $=$ $p_{1,1}$ $p_{2,1}$ $\ldots$ $p_{n,1}$ $p_{1,2}$ $\ldots$ $p_{k,2}$ $t_{1,2}$ $p_{k+1,2}$ $\ldots$ $p_{l,2}$

where the red part represent when $r_2$ was cloned from $r_1$, and the rest is how each repository was evolved. Now, suppose we make a merge of $r_1$ and $r_2$ in $r_1$ making a bundle of the patches of $r_2$ and appling it in $r_1$. Thus, after the merge we have that

$r_1$ $=$ $p_{1,1}$ $p_{2,1}$ $\ldots$ $p_{n,1}$ $p_{n+1,1}$ $\ldots$ $p_{m,1}$ $p_{1,2}$ $\ldots$ $p_{k,2}$ $t_{1,2}$ $p_{k+1,2}$ $\ldots$ $p_{l,2}$

and we found the situation where the tag $t_{1,2}$ is dirty because the green part is in the middle. And now we are in conditions of finding out how darcs does the reorder of patches.
So, the first task is to select the first tag seeing $r_1$ in the reverse way, suppose $t_{1,2}$ is the first (ie, $p_{k+1,2}$ $\ldots$ $p_{l,2}$ are not tags), and split the set of patches (the repository) in

$ps_{t_{1,2}}$ $=$ $p_{1,1}$ $p_{2,1}$ $\ldots$ $p_{n,1}$ $p_{1,2}$ $\ldots$ $p_{k,2}$ $t_{1,2}$

and the rest of the patch set,

$rest$ $=$ $p_{n+1,1}$ $\ldots$ $p_{m,1}$ $p_{k+1,2}$ $\ldots$ $p_{l,2}$

this is done by splitOnTag, which I don't totally understand yet, so for the moment... simply do the above :) Then, the part that interest us now is $rest$, we want to delete all the patches of $rest$ that exist in $r_1$ and then add them again, causing that they show up to the right. This job is done by tentativelyReplacePatches, which first calls tentativelyRemovePatches and then calls tentativelyAddPatches.

So, tentativelyRemovePatches of $r_1$ and $rest$ makes,

$r_{1}'$ $=$ $p_{1,1}$ $p_{2,1}$ $\ldots$ $p_{n,1}$ $p_{1,2}$ $\ldots$ $p_{k,2}$ $t_{1,2}$

and, tentativelyAddPatches of $r_{1}'$ and $rest$,

$r_{1}''$ $=$ $p_{1,1}$ $p_{2,1}$ $\ldots$ $p_{n,1}$ $p_{1,2}$ $\ldots$ $p_{k,2}$ $t_{1,2}$ $p_{n+1,1}$ $\ldots$ $p_{m,1}$  $p_{k+1,2}$ $\ldots$ $p_{l,2}$

leaving $t_{1,2}$ clean.

Well, all of this was for understanding the "solution" for the issue, we are almost there but before let's look at the function tentativelyRemovePatches. It attempts to remove patches with one special care: when one does darcs revert, a special file is generated, called unrevert in _darcs/patches, which is used for darcs unrevert in case that one makes a mistake with darcs revert. One important difference with unrevert is that unlike all the other files in _darcs/patches, unrevert in not a patch but a bundle, that contains a patch and a context. This context allows to know if the patch is applicable. So when one removes a patch (running for example oblitarete, unrecord or amend) that patch has to be removed from the bundle-revert (bundle of the file _darcs/patches/unrevert). It's now always possible to adjust the unrevert bundle, in which case, the operation continues only if the user agrees to delete the unrevert bundle.

But now a question emerge. Is it necessary to accommodate the bundle-revert in the case of reorder?; the answer is no, and it's because we don't delete any patch of $r_1$ so we still can apply the bundle-revert in $r_{1}''$.

So, finally! we find out that for reorder we need a special case of removing, which doesn't try to update the unrevert bundle. And this ends up being the "solution" for the issue, since the reorder blocks in that function. But! beyond this solves the issue something weird is happening, that is the reason of the double quotes for solution :)

This is more o less the step forward for now. The tasks ahead are, documenting the code in various parts and make the special case for the function tentativelyRemovePatches. On the way I will probably understand more about some of the functions that I mention before so probably I will add more info and rectify whatever is needed.

Hi hi all!

I have been accepted in the GSoC 2014 :) , as part of the work I'll be writing about my progress. The original plan is have a summary per week (or at least I hope so jeje).

I have already been reading some of the code of darcs and fixing some issues;

- Issue 2263 ~ Patch 1126
- Issue 1416 ~ Patch 1135
- Issue 2244 ~ Patch 1147 (needs-screening) (not any more $\ddot\smile$)

The details about the project is in History Reordering Performance and Features. Also some issues about the project are;

- Issue 2361
- Issue 2044

Cheers!

Sadly, a first slow week, I lost the monday with problems with my notebook for which I have to reinstall ghc, cabal, all the libraries, etc.. but! in the end this helped :)

The list of taks of the week include:

1. Compile and run darcs with profiling flags
2. Write scripts to generate dirty-tagged big repositories
3. Check memory usage with hp2any for the command optimize --reorder for the
generated repositories and repo-issue2361
4. Check performance difference with and without patch-index
5. Document reorder implementation on wiki
6. Actually debug/optimize reorder of issue2361 (Stretch goal)

1. Compile and run darcs with prolfiling flags

This seems pretty easy at first, but turned somewhat annoying because one have to install all the libraries with the option profiling. So a mini-step-by-step of the my installation of darcs with profiling
flags is (i'm using ubuntu 14.04, ghc-7.6.3 and cabal-install-1.20.0.2) :

- Install ghc-prof package, in my case with sudo apt-get install ghc-prof
- Install depencencies of darcs with enable-library-profiling, doing:
    - $ cabal install LIB --enable-library-profiling ( for each library :) )
    - or setting in ~/.cabal/config, library-profiling: True
- Finaly install darcs with enable-library-profiling and enable-executable-profiling

In my first week I worked on completing the garbage collection for repositories.

Darcs stores all the information needed under _darcs directory. In this part of the project we are only interested in the files stored in three directories:

• _darcs/patches/: stores the patches.
• _darcs/pristine.hashed/: stores the last saved state of working copy.
•  _darcs/inventories/: stores the inventories (lists of patches).

While working on a project under version control, these directories grow in size.
Every time we record a new patch:

• A new inventory file is stored in _darcs/inventories/ containing the augmented list of patches. Now, the old inventory file (without the new patch) is no longer needed (this is true in most cases).
• A new patch file is stored in darcs/patches/. If we later unrecord this patch, the patch file is no longer needed.
• The same happens with _darcs/pristine.hashed/. 

So, why do we keep these files if we no longer need them? Well, that’s because darcs wants to be fast and does not delete these files over time. Also it’s because if the repository is public and someone is cloning it, you don’t want to have some files disappearing in the process. 

Darcs, using "darcs optimize" command, only knows how to clean up the _darcs/pristine.hashed directory. Until now, the only way to clean the other two directories was doing a "darcs get". With the changes introduced, now "darcs optimize" also clean these directories.

Algorithms:

The implemented algorithm was pretty straightforward, in pseudo-code:

- inventory = _darcs/hashed_inventory
- while (inventory) 
    - useful_inventories += inventory
    - inventory = next_inventory(inventory) 
- remove files not in useful_inventories.

- inventory = _darcs/hashed_inventory
- while (inventory) 
    - useful_patches += get_patches(inventory)    
    - inventory = next_inventory(inventory)
- remove files not in useful_patches.

We can see that we travel the inventory list twice, one for inventories and one for the patches. Although this is not optimal, I think it is more modular, since now we have a function that gets the list of patches.


Commands affected:

- darcs optimize

Use cases:

It is useful when you need to free memory on your hard disk. 
For example:
- Record a new patch.
- Unrecord the new patch.
- Run optimize for garbage collecting the unused files corresponding to the unrecorded patch. Details in: http://pastebin.com/vYHiYV0F
You can find more use cases in the regression test script:
http://hub.darcs.net/darcs/darcs-screened/browse/tests/issue1987.sh.

Issues solved:

http://bugs.darcs.net/issue1987.

Patches created:

http://bugs.darcs.net/patch1134.

I was accepted for the Google Summer of Code 2014. I'll be working for Haskell.org and my project will focus on improvements of Darcs version control system.

The project consists on several parts:

1. Complete garbage collection for repositories.
2. Bucketed global cache.
3. Garbage collection of global cache.
4. Investigate and implement darcs undo command.
5. Investigate and implement darcs undelete command.

Here is a detailed description of my project proposal: http://darcs.net/GSoC/2014-Hashed-Files-And-Cache.

I'll try to give weekly updates of how my work is going, and let you know about the problems and solutions that I find in my way.

Thanks Haskell.org, thanks Darcs and last but not least thanks Google for giveng us this awesome opportunity.

darcsum was hanging again, so I made some updates:

• Fix a hang when reverting, when darcs responds with “Will not ask whether to revert this already decided patch…”.

• Fixed an error in at least my local darcsum, which caused it to break when darcsum-debug was enabled.

• Fixed the four warnings my emacs gave when byte-compiling it. These fixes could use some testing.

• Reviewed the status and backlog. Last release was 2010, the ELPA package dates from 2012, there’s a bunch of unreleased fixes, the site script needs updating for hakyll 4, the project still needs a maintainer.

And since I came this far, I’ll tag and announce darcsum 1.3. Hurrah!

This release includes many fixes from Dave Love and one from Simon Marlow. Here are the release notes.

Site and ELPA package updates will follow asap. All help is welcome.

Aditya BSRK’s darcsden-improvement GSOC has concluded, and I’ve recently merged almost all of the pending work and deployed it on darcs hub.

You can always see the recently landed changes here, but let me describe the latest features a little more:

File history - when you browse a file, there’s a new “file changes” button which shows just the changes affecting that file.

File annotate - there’s also a new “annotate” button, providing the standard view showing which commit last touched each line of the file. (also known as the blame/praise feature). It needs some CSS polish but I’m glad that the basic side-by-side layout is there.

More reliable highlighting while editing - the file editor was failing to highlight many common programming languages - this should be working better now. (Note highlighting while viewing and highlighting while editing are independent and probably use different colour schemes, this is a known open wishlist item.)

Repository compare - when viewing a repo’s branches, there’s a new “compare” button which lets you compare (and merge from) any two public repos on darcs hub, showing the unique patches on each side.

Cosmetic fixes - various minor layout and rendering issues were fixed. One point of discussion was whether to use the two-sided layout on the repo branches page as well. Since there wasn’t time to make that really usable I vetoed it in favour of the less confusing one-sided layout. I think showing both sides works well on the compare page though.

Patch bundle support - the last big feature of the GSOC was patch bundles. This is an alternative to the fork repo/request merge workflow, intended to be more lightweight and easy for casual contributors. There are two parts. First, darcs hub issue trackers can now store darcs patch bundle files (one per issue I think). This means patches can be uploaded to an issue, much like the current Darcs issue/patch tracker. But you can also browse and merge patches directly from a bundle, just as you can from another repo.

The second part (not yet deployed) is support for a previously unused feature built in to the darcs send command, which can post patches directly to a url instead of emailing them. The idea (championed by Aditya and Ganesh) is to make it very easy for someone to darcs send patches upstream to the project’s issue tracker, without having to fork a repo, or even create an account on darcs hub. As you can imagine, some safeguards are important to avoid becoming a spam vector or long-term maintenance headache, but the required change(s) are small and I hope we’ll have this piece working soon. It should be interesting to have both workflows available and see which works where.

I won’t recap the older new features, except to say that pack support is in need of more testing. If you ever find darcs get to be slow, perhaps you’d like to help test and troubleshoot packs, since they can potentially make this much faster. Also there are a number of low-hanging UI improvements we can make, and more (relatively easy) bugs keep landing in the darcs hub/darcsden issue tracker. It’s a great time to hack on darcs hub/darcsden and every day make it a little more fun and efficient to work with.

I really appreciate Aditya’s work, and that of his mentor, Ganesh Sittampalam. We did a lot of code review which was not always easy across a large time zone gap, but I think the results were good. Congratulations Aditya on completing the GSOC and delivering many useful features, which we can put to good use immediately. Thanks!

In the last post i show some examples and use cases of the "--look-for-replaces" flag for whatsnew, record, and amend-record commands in Darcs. When used, this flag provides automatic detection of replaces(possible ones), even when the modified files shows more differences than only the replaces, and even shows possible "forced" replaces.
The simplest case is when you made a replace in you editor in of choice and don't do any other change to the file and then, after check all is ok, remember that you could have used a replace patch.

Then, instead of:

> darcs revert -a file
Reverting changes in "file":

Finished reverting.
> darcs replace foo bar file
> darcs record -m "replace foo bar"
replace ./file [A-Za-z_0-9] foo bar
Shall I record this change? (1/1) [ynW...], or ? for more options: y
Do you want to record these changes? [Yglqk...], or ? for more options: y
Finished recording patch 'replace foo bar'

You could do:

> darcs record --look-for-replaces -m "replace foo bar"
replace ./file [A-Za-z_0-9] foo bar
Shall I record this change? (1/1) [ynW...], or ? for more options: y
Do you want to record these changes? [Yglqk...], or ? for more options: y
Finished recording patch 'replace foo bar'

But it doesn't have to be a full replace. For instance, if you don't want to change a pair replaces, when you try to detect the changes instead of:
Then, instead of:

> darcs whatsnew
hunk ./file 1
-line1 foo
-line2 foo
-line3 foo
+line1 bar
+line2 bar
+line3 bar

With the new flag you could record this:

> darcs whatsnew --look-for-replaces
replace ./file [A-Za-z_0-9] foo bar
hunk ./file 4
-line4 bar
+line4 foo

Say you replace a word for another word that was already in the file. Normally this would mean that you should use "darcs replace --force". The look-for-replaces flag always "forces" the replaces, so if you try this, the changes to make the replace reversible will be shown before the replace patch:
With the new flag you will see the same patches like if you have made a "darcs replace --force foo bar file":

> darcs whatsnew --look-for-replaces
hunk ./file 4
-line4 bar
+line4 foo
replace ./file [A-Za-z_0-9] foo bar

Given certain limitations you could have any number of replaces detected, like this:
All the replaces are shown below:

> darcs whatsnew --look-for-replaces
replace ./file [A-Za-z_0-9] fee bor
replace ./file [A-Za-z_0-9] fee2 bor2
replace ./file [A-Za-z_0-9] fee3 bor3
replace ./file [A-Za-z_0-9] foo bar
replace ./file [A-Za-z_0-9] foo2 bar2
replace ./file [A-Za-z_0-9] foo3 bar3

If you want to know more about the limitations of this functionality, check Automatic detection of replaces for Darcs - Part 2.

The last weeks i was implementing "--look-for-replaces" flag for whatsnew, record, and amend-record commands in Darcs. When used, this flag provides automatic detection of replaces(possible ones) even when the modified files shows more differences than only the replaces, given they meet the following prerequisites:
1. For a given "word" and a given file, there is not need for all the instances to be replaced, but there must be only one replace suggestion posible. i.e.:

2. The replace must happen in lines that have the same amount of words between the recorded and the working state, otherwise it would not be detected.
3. There must be at least one hunk with the same amount of lines in the - and + side that contains the replace.

⮁ ls -1pC
_darcs/  dir/  dir2/  dir3/  foo  foo2  foo3  foo4  foo5
⮁ mv foo dir3
⮁ mv foo2 dir
⮁ mv foo3 dir2
⮁ mv foo4 foo4.tmp
⮁ mv foo5 foo4
⮁ mv foo4.tmp foo5
⮁ mv dir3 dir
⮁ mv dir dir2/dir2
⮁ mv dir2 dir
⮁ darcs whatsnew --look-for-moves
move ./dir ./dir2/dir2
move ./dir2 ./dir
move ./dir3 ./dir/dir2/dir3
move ./foo ./dir/dir2/dir3/foo3
move ./foo2 ./dir/dir2/foo2
move ./foo3 ./dir/foo3
move ./foo4 ./foo4.tmp~
move ./foo5 ./foo4
move ./foo4.tmp~ ./foo5

The moves shown by "darcs whatsnew --look-for-moves" are not exactly the ones made but yield the same final result.

In the last few weeks i was implementing automatic detection of file renames adding "look-for-moves" flag to the amend-record, record, and whatsnew commands.

In darcs are 3 states:

• The recorded state is the one is marked by the last record made.
• The working state is the actual state of the files in the repository with all the last changes.
• The pending state is the one that mark changes like file adds, moves, replaces, etc, before they are recorded. Is a temporal state between recorded and working that let darcs know about what filenames to track, and changes that are not common like replaces.

 If a file rename is not marked in the pending state, darcs lost track of the file and can't know where it is, and then `darcs whatsnew` and `darcs record` will indicate the file as deleted.
To detect this file rename I choose to use the inode info in the filesystem to check for equality between different filenames in the recorded and working state of the repo. for those who don't know, the inode is an index number assigned by the file system to identify a specific file data. The file name is linked to the data by this number, and it's used by directories as well. You can consult this number with "ls -i".

⮁ mkdir testdir
⮁ touch testfile
⮁ ln testfile testfile.hardlink
⮁ ln -s testfile testfile.symboliclink
⮁ ls -i1
10567718 testdir
10485776 testfile
10485776 testfile.hardlink
10485767 testfile.symboliclink 

You can see that the hardlink shares the same number with the test file, this is because a file is essentially a hardlink to the file data and when you make a new hardlink you are sharing the same file data, so the same inode number.
To have an old inode to filename mapping, there must be some record of the files inodes in some place, so I added the inode info to the index of hashed-storage in _darcs/index. The index save the last info about the record plus the pending state, sort of, so is a perfect fit to save this info.
Then comparing the RecordedAndPending Tree(from the index) with the Working Tree i get the file changes in a pair list mapping between the two states. With this list I resolve dependencies between the different moves, making temporal names if it's necessary and generating a FL list of move patches to merge with the changes between pending and working patches.
This patches are shown in with whatsnew or are selected with record/amend-record to be recorded in the repo.
There is a little more to make this happen but that's the core idea of the implementation.
The algorithm doesn't care if the file are modified or not, because it doesn't care of the content of the files, so it's very robust in that sense.
With this implementation you could do any move directly with "mv", and is very lightweight and fast in detecting moves so is likely a good decision make "--look-for-moves" a default flag. You could do things like this:

⮁ darcs init
Repository initialized.
⮁ touch foo
⮁ darcs record -a -m add_file_foo -A x --look-for-adds
Finished recording patch 'add_file_foo'
⮁ mv foo foo2
⮁ darcs whatsnew --look-for-moves
move ./foo ./foo2

This doesn't work on Windows yet, because fileID(the function on unix-compat that get the inode number) is lacking an implementation on windows. I know the windows API have GetFileInformationByHandle (it returns a BY_HANDLE_FILE_INFORMATION structure that contains the file index number[1]), so there doesn't have to be too hard to add an implementation of it with some boilerplate code to make the interface.
More complicated moves should work and some does but I was having problems with the dependency resolving algorithm implementation. I made some mistakes in the first implementation and I'm dragging them since then. I'm confident to know what is the error so I will fix it soon.
UPDATE: i'm testing a windows implementation with the Win32 haskell library on a virtual machine.

Hello blog. Since last time I’ve been doing plenty of stuff, but not telling you about it. Let’s do a bullet list and move on..

darcsden/darcs hub

• fixed some bugs
• committed the hub.darcs.net front page, for easy hacking
• added repo counts to the front page
• GSOC testing/support

hledger

• expanded the docs for conditional blocks (if statement) in CSV rules
• added an include directive to allow sharing of common CSV rules

FunGEn & game dev

A sudden burst of activity here.

• schmoozed in #haskell-game, got caught up on haskell game development, updated the Games wiki page a bit
• updated and published my template for SDL projects on OSX: hssdl-osx-template
• continued some FunGEn updates I’ve been sitting for a year and did a release - see next post.

Recent activity:

I fixed another clumsy query on darcs hub, making the all repos page faster. Experimented with user and repo counts on the front page. I like it, but haven’t deployed to production yet. It costs about a quarter of a second in page load time (one 50ms couch query to fetch all repos, plus my probably-suboptimal filtering and sorting).

I’ve finally learned how many of those names on the front page have (public) repos behind them (144 out of 319), and how many private repos there are (125, higher than expected!).

Thinking about what is really most useful to have on the front page. Keep listing everything ? Just top 5 in various categories ? Ideas welcome.

Did a bunch of bookkeeping today, which inspired my first hledger commit in a while. I found the balancesheet command (abbreviation: bs) highly useful for a quick snapshot of assets and liabilities to various depths (add –depth N). The Equity section was just a distraction though, and I think it will be to most hledger users for the time being, so I removed it.

More darcs hub activity, including some actual app development (yay):

Added news links to the front page.

Cleaned up hub’s docs repo and updated the list of blockers on the roadmap.

Updated/closed a number of issues, including the app-restarting #58, thanks to a fast highlighting-kate fix by John McFarlane.

Tested and configured the issue-closing commit posthook in the darcsden trunk repo. Commits pushed/merged there whose message contains the regex (closes #([0-9]+)|resolves #([0-9]+)|fixes #([0-9]+)) will now close the specified issue, with luck.

Consolidated a number of modules to help with code navigation, to be pushed soon.

Improved the redirect destination when deleting or forking repos or creating/commenting/closing issues.

Fixed a silly whitespace issue when viewing a patch, where the author name and date run together. I’m still confused about the specific code that generates this - the code I expect uses tables but firebug shows divs. A mystery for another day..