| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
git-annex has been using MissingH's `abdNormPath` forever, but that's
unmaintained and possibly buggy, and doesn't work on Windows. I've been
wanting to get rid of it for some time, and finally did today, writing a
`simplifyPath` that does the things git-annex needs and will work with all
the Windows filename craziness, and takes advantage of the more modern
System.FilePath to be quite a simple peice of code. A QuickCheck test found
no important divergences from absNormPath. A good first step to making
git-annex not depend on MissingH at all.
And it fixed some weird behaviors on Windows like
`git annex add ..\subdir\file` not working.
Note that absNormPathUnix has been left alone for now.
|
| |
|
|
|
| |
Note: Test reordered because running git-annex sync early broke the
environment for some other tests.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix bug in automatic merge conflict resolution code when used
on a filesystem not supporting symlinks, which resulted in it losing
track of the symlink bit of annexed files.
This was the underlying bug that was causing another test to fail,
which got worked around in f5d0c8f0bf7f018479eb4da7e8c41598b7aacb7d.
I've chosen to keep 2 separate test cases since the old test case only
detected the problem accidentially.
Test suite passes on FAT & in windows, as well as on proper unix systems.
This commit was sponsored by Ellis Whitehead.
|
| | |
|
| |
|
|
|
|
| |
This adds a test for a failure mode seemingly specific to Windows
that was removed in f5d0c8f0bf7f018479eb4da7e8c41598b7aacb7d, and puts it
in its own test case.
|
| |
|
|
|
|
|
|
|
| |
This fixes the problem of the environment variables apparently not being
seen on Windows. I could probably remove the setting of the env vars from
Test.hs now as this covers it better.
Note that outside the test suite, git-annex on windows seems to manage to
configure the repo so commits work on its own.
|
| |
|
|
|
|
| |
f5d0c8f0bf7f018479eb4da7e8c41598b7aacb7d broke the mixed conflict
resolution test. Since origin is no longer involved, both sides have to
sync after pairing. (The sync before pairing is just to get a commit.)
|
| |
|
|
| |
A broken symlink would cause the mode setting to fail.
|
| | |
|
| |
|
|
|
|
|
| |
On windows, the sync of the second cloned repo to origin failed, because
synced/master was a non-fast-forward. This may be a bug of its own, but
it's not the issue that this test was intended to test, so disconnect
the repos from origin before syncing.
|
| | |
|
| |
|
|
|
|
| |
On Windows, a file that is not writable cannot be deleted even if in a
directory with write perms. So git object files were not getting deleted
when removing a git repository.
|
| |
|
|
| |
Opened a bug about this: https://github.com/jystic/unix-compat/issues/10
|
| |
|
|
| |
This reverts commit 65eb61a902ecf68da69d774063fea4880f619a13.
|
| |
|
|
|
|
| |
revert 852f1f6cea85a7c781c8286f459023bdacebe021
tasty-rerun is stuck in NEW in debian
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This will be used in expiring old unused objects. The timestamp is when it
was first noticed it was unused.
Backwards compatability: It supports reading old format unused log files.
The old version of git-annex will ignore lines in log files written by the
new version, so the worst interop problem would be git annex dropunused not
knowing some numbers that git-annex unused reported.
|
| |
|
|
|
|
| |
have run
Should be ready now for tasty-rerun.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* numcopies: New command, sets global numcopies value that is seen by all
clones of a repository.
* The annex.numcopies git config setting is deprecated. Once the numcopies
command is used to set the global number of copies, any annex.numcopies
git configs will be ignored.
* assistant: Make the prefs page set the global numcopies.
This global numcopies setting is needed to let preferred content
expressions operate on numcopies.
It's also convenient, because typically if you want git-annex to preserve N
copies of files in a repo, you want it to do that no matter which repo it's
running in. Making it global avoids needing to warn the user about gotchas
involving inconsistent annex.numcopies settings.
(See changes to doc/numcopies.mdwn.)
Added a new variety of git-annex branch log file, that holds only 1 value.
Will probably be useful for other stuff later.
This commit was sponsored by Nicolas Pouillard.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
I've had one or two fails sent to me involving cases QuickCheck didh't
easily find, and tasty makes this easy.
|
| | |
|
| | |
|
| |
|
|
| |
Also merged in Test.hs from master.
|
| |
|
|
|
| |
This is a win. Will need to wait for tasty getting into Debian,
and do a trivial conversion of the remainder of the hunit tests.
|
| | |
|
| |
|
|
|
|
| |
directory special remote.
Directory special remotes now fully usable.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In direct mode, it's best to whenever possible not move direct mode files
out of the way, and so I made unannex avoid touching the direct mode file at
all.
That actually turns out to be easy, because in direct mode, unlike indirect
mode, the pre-commit hook won't get confused if the unannexed file later
gets added back by git add. So there's no need to commit the unannex right
away; it can be staged for the user to commit later. This also means that
unannex in direct mode is a lot faster than in indirect mode!
Another subtle bit is the bookkeeping that is done when unannexing a direct
mode file. The inode cache needs to be removed so that when uninit runs
getKeysPresent, it doesn't see the cache and think the key is still
present and crash when it's not.
This commit is sponsored by Douglas Butts. Thanks!
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Better to have a working test suite that doesn't test a few things
than no working test suite.
Most of the disabled stuff is because for some reason "git annex sync"
doesn't work when run inside the test suite. Looks like PATH problems.
The directory and rsync special remotes seem broken on Windows, or
maybe the tests are. Pretty sure the hook special remote test is broken.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fixes the behavior of the manual mode group.
The current manual mode preferred content expression is:
"present and (((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1))) or (not copies=semitrusted+:1))"
The old matcher misparsed this, to basically:
OR (present and (...)) (not copies=semitrusted+:1))
The paren handling and indeed the whole conversion from tokens to the
matcher was just wrong. The new way may not be the cleverest, but I think
it is correct, and you can see how it pattern matches structurally against
the expressions when parsing them.
That expression is now parsed to:
MAnd (MOp <function>)
(MOr (MOr (MAnd (MOp <function>) (MOp <function>)) (MNot (MOr (MOp <function>) (MOp <function>))))
(MNot (MOp <function>)))
Which appears correct, and behaves correct in testing.
Also threw in a simplifier, so the final generated Matcher has less
unnecessary clutter in it. Mostly so that I could more easily read &
confirm them.
Also, added a simple test of the Matcher to the test suite.
There is a small chance of badly formed preferred content expressions
behaving differently than before due to this rewrite.
|
| | |
|
| |
|
|
|
| |
On a filesystem that only supports direct mode, it will test
direct mode twice, but oh well.
|
| | |
|
Joey Hess