This is a preview of the filecache work I'm doing. You can test it
with "darcs optimize --filecache" and then use the cache with
"darcs changes --filecache GNUmakefile". There are still some things
I have to investigate.

1 patch for repository http://www.darcs.net/repos/unstable:

Mon Mar  8 21:54:50 CET 2010  Benedikt Schmidt <beschmi@gmail.com>
  * add support for filecache (optimize and changes for now only)

Attachments

• add-support-for-filecache-_optimize-and-changes-for-now-only_.dpatch
• unnamed

I'm marking this as "amend-in-progress" as it's not intended to be pushed 
yet. Someone else jump in and correct me if that's an incorrect use of 
the bugtracker.

Just a snapshot for anyone interested.

13 patches for repository /Users/beschmi/darcs/unstable:

Tue Mar  9 20:28:39 CET 2010  Benedikt Schmidt <beschmi@gmail.com>
  * add ghci target (do not push)

Tue Mar  9 21:52:02 CET 2010  Benedikt Schmidt <beschmi@gmail.com>
  * add support for filecache (optimize and changes for now only)

Wed Mar 17 01:06:30 CET 2010  Benedikt Schmidt <beschmi@gmail.com>
  * fix comment

Wed Mar 17 01:08:03 CET 2010  Benedikt Schmidt <beschmi@gmail.com>
  * add ghci target to Makefile

Wed Mar 17 01:10:31 CET 2010  Benedikt Schmidt <beschmi@gmail.com>
  * add preliminary support for filecache to annotate

Sat Mar 20 16:40:46 CET 2010  Benedikt Schmidt <beschmi@gmail.com>
  * remove unneeded module import

Sat Mar 20 16:41:39 CET 2010  Benedikt Schmidt <beschmi@gmail.com>
  * improve FileMod modules

Sat Mar 20 17:30:55 CET 2010  Benedikt Schmidt <beschmi@gmail.com>
  * fixes for filecache^Wpatch index

Sat Mar 20 23:57:56 CET 2010  Benedikt Schmidt <beschmi@gmail.com>
  * disable trace in FileModMonad

Sat Mar 20 23:59:10 CET 2010  Benedikt Schmidt <beschmi@gmail.com>
  * various improvements to patch index (sets instead of lists, directory name)

Sun Mar 21 01:11:55 CET 2010  Benedikt Schmidt <beschmi@gmail.com>
  * some more filecache to patch index replacements

Sun Mar 21 01:35:49 CET 2010  Benedikt Schmidt <beschmi@gmail.com>
  * commit before modifying the storage format

Sun Mar 21 16:30:08 CET 2010  Benedikt Schmidt <beschmi@gmail.com>
  * use Data.Binary

Attachments

• add-ghci-target-_do-not-push_.dpatch
• unnamed

I started reviewing this (I'm also happy to finish it off if Benedikt is busy).

I noticed this comment in the code:
-- | The latest Patch that touches the file is always the first in the list
type TouchingMap = Map FileId (Set PatchId)

I was skeptical that (Set PatchId) would keep things sorted correctly in all cases.  I looked at how 
Set would be storing things:
-- | The PatchId identifies a patch and can be created from a PatchInfo with make_filename
type PatchId = String

So the sort order comes down to string sorting.  The next question is, how are the PatchIds created?  
The comment in other places say to use make_filename, which is now renamed to makeFilename:
-- This makes darcs-1 (non-hashed repos) filenames, and is also generally used in both in
-- hashed and non-hashed repo code for making patch "hashes"
makeFilename :: PatchInfo -> String
makeFilename pi =
    showIsoDateTime d++"-"++sha1_a++"-"++sha1PS sha1_me++".gz"
        where b2ps True = BC.pack "t"
              b2ps False = BC.pack "f"
              sha1_me = B.concat [_piName pi,
                                  _piAuthor pi,
                                  _piDate pi,
                                  B.concat $ _piLog pi,
                                  b2ps $ isInverted pi]
              d = readPatchDate $ _piDate pi
              sha1_a = take 5 $ sha1PS $ _piAuthor pi

The interesting and relevant bit is that the patchids start with an ISO Date/Time.

Because patches can commuted and stored in a different order than the order they are created in, the 
type of TouchingMap means sometimes it may be possible for the patch index will store touching files 
in the wrong order.

I'll see if I can come up with an example that would be wrong with (Set PatchId) and correct with 
[PatchId].  Of course, the "trivial" example is when patches that touch the same file are created at 
nearly the same time on different machines.  In that scenario, one machine could have clock that is 
behind the other.  If it the clocks were enough different you could imagine the patches being in the 
wrong order in the index.

Hi Jason,

On 8/29/10 1:28 , Jason Dagit wrote:

> Jason Dagit<no-reply@example.com>  added the comment:
>
> I started reviewing this (I'm also happy to finish it off if Benedikt is busy).

I'm happy that someone is looking into this and it is a good motivation
to publish a new patch that is easier to consume for reviewers. I can
publish my darcs-repo which has been forked from unstable in march if
you (or someone else) wants to look at the code before I get around to
rebasing everything to current unstable.

 > I noticed this comment in the code:
 > -- | The latest Patch that touches the file is always the first in 
the list
 > type TouchingMap = Map FileId (Set PatchId)

The code changed quite a bit since I sent the last patch, so I don't
remember all the details anymore. Nevertheless, I'm pretty sure that
the code never assumed that the alphabetic order of patchids has any
relation to the order of patches in the repo. So the comment is clearly
wrong and might be left over from an older version of the code.

The main idea at the time was that you have to read the inventory
anyways, so that's where you get the list of patch-infos in the right
order and the TouchingMap is just used to filter out the relevant
patch-infos.

   Benedikt

Benedikt, can you publish the repository with your work in progress? Are
you ok with someone else porting it to the current HEAD of darcs?

I have ported patch index to the current screened.
Create a patch index with darcs optimize --patch-index,
and show the patch index with darcs show patch-index-all.
You can also view the files in patch index with darcs show patch-index-
files

Attachments

• added-files-filemodmonad_-filemod_-filemodtypes.dpatch

On Tue, Feb 28, 2012 at 5:07 PM, BSRK Aditya <bugs@darcs.net> wrote:
>
> BSRK Aditya <bsrkaditya@gmail.com> added the comment:
>
> I have ported patch index to the current screened.

Thanks for porting this patch.  It applied cleanly to a fresh copy of
screened.  However, I get the following build error:

src/Darcs/Commands/Show.hs:31:8:
    Could not find module `Darcs.Commands.ShowPatchIndex'

It looks like src/Darcs/Commands/ShowPatchIndex.hs is missing from the
patch bundle.

--
Michael

Ah! I missed that file. Use the patch I attached here instead. I 
confirmed that it builds.

Attachments

• added-files-filemodmonad_-filemod_-filemodtypes.dpatch

The last patch(dated 2012-03-01.04:32:27) now has conflicts with latest
screened. I am uploading a new patch with the conflict resolved.

Attachments

• changes.dpatch

This patch again removes the conflicts introduced to screened

Attachments

• changes.dpatch

Sorry, I mailed the wrong patch.

Attachments

• sync.dpatch

This has been integrated in darcs since the end of BSRK's summer of code 
project.