fix windows build

comment

avoid sometimes expensive operations when annex.supportunlocked = false

This will mostly just avoid a DB lookup, so things get marginally
faster. But in cases where there are many files using the same key, it
can be a more significant speedup.

Added overhead is one MVar lookup per call, which should be small
enough, since this happens after transferring or ingesting a file,
which is always a lot more work than that. It would be nice, though,
to move getGitConfig to AnnexRead, which there is an open todo about.

response

Added a comment

Added a comment: git-annex-add slowdown

check symlink before reading file

This is faster because when multiple files are in a directory, it gets
cached.

retitle

reproduced

handle edge case of symlink to something that is not really a pointer file

That seems very unlikely to happen, but still, it's possible it could.
And with the recent addition of locked files to the keys db, this could
be called by places that did not call it before, so it seems even more
important it's correct.

Adds an extra stat of the file, and is potentially racy, but both
problems are fixed by the unix-2.8.0 path. I have not tested that path
builds because that package is not yet released and it would be difficult
to install it since it's tightly tied to a ghc version.

rename for clarity

Associated files are recorded now also for locked files, but this is
only needed to populate unlocked files.

Added a comment

Added a comment: more "mystery resolved" -- identical (empty) keys

Merge branch 'master' of ssh://git-annex.branchable.com

comment

Added a comment

Added a comment

Added a comment: OSX mystery resolved. add --batch is effective mitigation

comments

Added a comment

Added a comment: getting closer...

Added a comment

removed

Merge branch 'master' of ssh://git-annex.branchable.com

Added a comment: all recent builds/logs are fetched to smaug

display scanning message whenever reconcileStaged has enough files to chew on

Clear visible progress bar first.

Removed showSideActionAfter because it can't be used in reconcileStaged
(import loop). Instead, it counts the number of files it
processes and displays it after it's seen a sufficient to know it's
taking a while.

Sponsored-by: Dartmouth College's Datalad project

clarification

add debugging for reconcileStaged calls for benchmarking

scanAnnexedFiles in smudge --update

This makes git checkout and git merge hooks do the work to catch up with
changes that they made to the tree. Rather than doing it at some later
point when the user is not thinking about that past operation.

Sponsored-by: Dartmouth College's Datalad project

Merge branch 'master' of ssh://git-annex.branchable.com

claw back annexed file scan speedup

Following commit c941ab6f5b98becfa2880cb69cbc2c4a39057cd9, this avoids
the second, redundant scan when annex.thin is not set.

The benchmark now runs in 35.5 seconds, down from 40 seconds.

Note that the inode cache of the annex object has to be passed to
addInodeCaches now, because it might not already be in the inode caches,
unlike previously.

Sponsored-by: Dartmouth College's Datalad project

improve comment

remove obsolete part about a commit preventing it seeing changes

Added a comment: slow down is OSX specific

comment

Merge branch 'master' of ssh://git-annex.branchable.com

avoid double work in git-annex init, second try

reconcileStaged populates the db, so scanAnnexedFiles does not need to
do it again. It still makes a pass over the HEAD tree, but populating
the db was most of the expensive part.

Benchmarking with 100,000 files, git-annex init now takes 40 seconds,
vs 37 seconds with the old, buggy version of this fix. It should be
possible to win those 3 precious seconds per 100k files back, in the
case when when annex.thin is not set, with improvements to reconcileStaged
that avoid needing this second pass.

Sponsored-by: Dartmouth College's Datalad project

stop using addAssociatedFileFast

Use addAssociatedFile instead, after recent optimisations it seems just
as fast.

Revert "avoid double work in git-annex init"

This reverts commit 0f10f208a7c76061b7d48aaa7ea0fa8e641cace3.

The implementation of this turns out to be unsafe; it can lead to a keys
db deadlock. scanAnnexedFiles injects a call to inAnnex into
reconcileStaged, but inAnnex sometimes needs to read from the keys db,
which will try to re-open it when it's in the process of being opened.
The exclusive lock of gitAnnexKeysDbLock will then deadlock.

This needs to be done in some other way...

faster associated file replacement with upsert

Rather than first deleting and then inserting, upsert lets the key
associated with a file be updated in place.

Benchmarked with 100,000 files, and an empty keys database, running
reconcileStaged. It improved from 47 seconds to 34 seconds.
So this got reconcileStaged to be as fast as scanAssociatedFiles,
or faster -- scanAssociatedFiles benchmarks at 37 seconds.

(Also checked for other users of deleteWhere that could be sped up by
upsert. There are a couple, but they are not in performance critical
code paths, eg recordExportTreeCurrent is only run once per tree
export.)

I would have liked to rename FileKeyIndex to FileKeyUnique since it is
being used as a uniqueness constraint now, not just to get an index.
But, that gets converted into part of the SQL schema, and the name
is used by the upsert, so it can't be changed.

Sponsored-by: Dartmouth College's Datalad project

Added a comment

Added a comment: clarification

Merge branch 'master' of ssh://git-annex.branchable.com

todo

avoid double work in git-annex init

reconcileStaged was doing a redundant scan to scannAnnexedFiles.

It would probably make sense to move the body of scannAnnexedFiles
into reconcileStaged, the separation does not really serve any purpose.

Sponsored-by: Dartmouth College's Datalad project

optimise reconcileStaged with git cat-file streaming

Commit 428c91606b434512d1986622e751c795edf4df44 made it need to do more
work in situations like switching between very different branches.

Compare with seekFilteredKeys which has a similar optimisation. Might be
possible to factor out the common part from these?

Sponsored-by: Dartmouth College's Datalad project

remove unnecessary liftIO

Added a comment: deferring the scan

comment

fix link

Merge branch 'master' of ssh://git-annex.branchable.com

correctly update keys db in merge conflict

This is quite a subtle edge case, see the bug report for full details.

The second git diff is needed only when there's a merge conflict.
It would be possible to speed it up marginally by using
--diff-filter=Unmerged, but probably not enough to bother with.

Sponsored-by: Graham Spencer on Patreon

Added a comment: deferring the keys-to-files scan

comment

comment

Merge branch 'master' of ssh://git-annex.branchable.com

comment

added suggestion to match keys by file extension in the key

Added a comment: keeping connected files together

removed

Added a comment: specifying preferred content by metadata

Added a comment: specifying preferred content by metadata

Added a comment

Added a comment

rename bugs/delayadd_doesn__39__t_work.mdwn to bugs/delayadd_doesn__39__t_work_with_smallfiles.mdwn

Added a comment: using import tree and export tree

Add bug report

Added a comment

Initial report on performance regression

Added a comment

Added a comment

Added a comment: "why all these wild ideas are being thrown out there"

Merge branch 'master' of ssh://git-annex.branchable.com

--size-limit exit 101

Sponsored-by: Mark Reidenbach on Patreon

add --size-limit option

When this option is not used, there should be effectively no added
overhead, thanks to the optimisation in
b3cd0cc6ba4e5b9e2ae0abd9c8b2ec32475e09d2.

When an action fails on a file, the size of the file still counts toward
the size limit. This was necessary to support concurrency, but also
generally seems like the right choice.

Most commands that operate on annexed files support the option.
export and import do not, and I don't know if it would make sense for
export to.. Why would you want an incomplete export? sync doesn't, and
while it would be easy to make it support it for transferring files,
it's not clear if dropping files should also take the size limit into
account. Commands like add that don't operate on annexed files don't
support the option either.

Exiting 101 not yet implemented.

Sponsored-by: Denis Dzyubenko on Patreon

minor optimisation

Avoid a second mvar access.

Sponsored-by: Jochen Bartl on Patreon

comment

comment

comment

avoid displaying the scanning annexed files message when repo is not large

Avoids users thinking this scan is a big deal, when it's not in the
majority of repos.

showSideActionAfter has some ugly caveats, since it has to display in
the background of another action. I could not see a better way to do it
and it works fine in this particular case. It also doesn't really belong
in Annex.Concurrent, but cannot go in Messages due to an import loop.

Sponsored-by: Dartmouth College's Datalad project

comment

about "scanning for annexed" while in git-annex branch

Added a comment

Added a comment: matching include/exclude based on file extension in the key

Added a comment: keys db optimization

Merge branch 'master' of ssh://git-annex.branchable.com

avoid removing old associated file when there is a merge conflict

It makes sense to keep the key used by the old version of an
associated file, until the merge conflict is resolved.

Note that, since in this case git diff is being run with --index, it's
not possible to use -1 or -3, which would let the keys
associated with the new versions of the file also be added. That would
be better, because it's possible that the local modification to the file
that caused the merge conflict has not yet gotten its new key recorded
in the db.

Opened a bug about a case this is thus not able to address.

Sponsored-by: Boyd Stephen Smith Jr. on Patreon

todo

Added a comment: keys-to-paths db

comments

Added a comment: startup scan for files

Added a comment

Merge branch 'master' of ssh://git-annex.branchable.com

Added a comment

comment

Added a comment