Added a comment: setting up sync

Added a comment

Added a comment

Added a comment

Added a comment

added suggestion to allow use of synchronous=OFF with Sqlite

Added a comment: thanks

comment

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

Added a comment: adding disableremote

removed

Added a comment: adding disableremote

clear progress bar before displaying messages

In particular this clears it before "transfer stalled". If an external
special remote uses showInfo while progress is displayed, it will also
improve display of that.

Generally this will avoid all such problems in the future..

Sponsored-by: Svenne Krap on Patreon

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

removed

drop, move, mirror: when two files have the same content, honor the max numcopies and requiredcopies

Eg, before with a .gitattributes like:

*.2 annex.numcopies=2
*.1 annex.numcopies=1

And foo.1 and foo.2 having the same content and key, git-annex drop foo.1 foo.2
would succeed, leaving just 1 copy, despite foo.2 needing 2 copies.
It dropped foo.1 first and then skipped foo.2 since its content was gone.

Now that the keys database includes locked files, this longstanding wart
can be fixed.

Sponsored-by: Noam Kremen on Patreon

Added a comment

Added a comment

remove unused import

verify associated files when checking numcopies

Most of this is just refactoring. But, handleDropsFrom
did not verify that associated files from the keys db were still
accurate, and has now been fixed to.

A minor improvement to this would be to avoid calling catKeyFile
twice on the same file, when getting the numcopies and mincopies value,
in the common case where the same file has the highest value for both.
But, it avoids checking every associated file, so it will scale well to
lots of dups already.

Sponsored-by: Kevin Mueller on Patreon

fix build

avoid warning

avoid nub

It's O(N^2) which could matter when there are many dup files using the
same key.

refactor

close

respinse

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

fix exponential blowup when adding lots of identical files

This was an old problem when the files were being added unlocked,
so the changelog mentions that being fixed. However, recently it's also
affected locked files.

The fix for locked files is kind of stupidly simple. moveAnnex already
handles populating unlocked files, and only does it when the object file
was not already present. So remove the redundant populateUnlockedFiles
call. (That call was added all the way back in
cfaac52b88e157dd4e71626fe68af37015b9c9bd, and has always been
unncessary.)

Sponsored-by: Dartmouth College's Datalad project

remove supportUnlocked check that is not worth its overhead

moveAnnex only gets to that check if the object file was not present
before. So in the case where dup files are being added repeatedly,
it will only run the first time, and so there's no significant speedup
from doing it; all it avoids is a single sqlite lookup. Since MVar
accesses do have overhead, it's better to optimise for the common case,
where unlocked files are supported.

removeAnnex is less clear cut, but I think mostly is skipped running on
keys when the object has already been dropped, so similar reasoning
applies.

bloom doesn't work, but this should I hope

plan

comment

going round and round, boredly

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

comment

comment

Future proof activity log parsing

When the log has an activity that is not known, eg added by a future
version of git-annex, it used to be treated as no activity at all,
which would make git-annex expire think it should expire the repository,
despite it having some kind of recent activity.

Hopefully there will be no reason to add a new activity until enough
time has passed that this commit is in use everywhere.

Sponsored-by: Jake Vosloo on Patreon

Added a comment

comment

improve docs based on forum feedback

comment

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