update
This commit is contained in:
parent
57fddd5cd2
commit
dde219dc95
4 changed files with 22 additions and 22 deletions
3
debian/changelog
vendored
3
debian/changelog
vendored
|
@ -5,6 +5,9 @@ git-annex (3.20121212) UNRELEASED; urgency=low
|
|||
via symlinks. Note that direct mode is currently experimental. Many
|
||||
git and git-annex commands do not work, or can even cause data loss in
|
||||
direct mode.
|
||||
* assistant: Support direct mode; however kqueue based systems (including
|
||||
OSX) do not yet support autocommitting after files are modified in
|
||||
direct mode.
|
||||
* kqueue: Fix bug that made broken symlinks not be noticed.
|
||||
* vicfg: Quote filename. Closes: #696193
|
||||
* Bugfix: Fixed bug parsing transfer info files, where the newline after
|
||||
|
|
|
@ -6,14 +6,16 @@ I don't know if it'll be easy or hard. Let's find out..
|
|||
|
||||
* First, got direct mode adding of new files working. This was not hard, all the
|
||||
pieces I needed were there. For now, it uses the same method as in
|
||||
indirect mode to make sure nothing can modify the file while it's being added.
|
||||
indirect mode to make sure nothing can modify the file while it's being
|
||||
added.
|
||||
|
||||
* An unexpected problem is that in its startup scan, the assistant runs
|
||||
`git add --update` to detect and stage any deletions that happened
|
||||
while it was not running. But in direct mode that also stages the full file
|
||||
contents, so can't be used. Had to switch to using git plumbing to only
|
||||
stage deleted files. Happily this also led to fixing a bug, where deletions
|
||||
were not always committed at startup.
|
||||
stage deleted files. Happily this also led to fixing a bug; deletions
|
||||
were not always committed at startup when using the old method; with the
|
||||
new method it can tell when there are deletions and trigger a commit.
|
||||
|
||||
* Next, got it to commit when direct mode files are modified. The Watcher
|
||||
thread gets a inotify event when this happens, so that was easy. (Although
|
||||
|
@ -30,20 +32,14 @@ I don't know if it'll be easy or hard. Let's find out..
|
|||
* Another unexpected problem: When an assistant receives new files from one
|
||||
of its remotes, in direct mode it still sets up symlinks to the content.
|
||||
This was because the Merger thread didn't use the `sync` command's direct
|
||||
mode aware merge code.
|
||||
mode aware merge code.. so fixed that.
|
||||
|
||||
One other interesting thing about file transfers in
|
||||
direct mode is that they can sometimes happen before the git branch is
|
||||
pushed and merged. When that happens the object is stored in indirect mode.
|
||||
Happily the direct mode aware merger detects such objects and converts them
|
||||
to direct mode.
|
||||
* Finally there was some direct mode bookeeping the assistant has
|
||||
to get right. For example, when a file is modified, the old object has
|
||||
to be looked up, and be marked as not locally present any longer. That
|
||||
lookup relies on the already running `git cat-file --batch`, so it's
|
||||
not as fast as it could be, if I kept a local cache of the mapping
|
||||
between files and objects. But it seems fast enough for now.
|
||||
|
||||
* Noticed that when the assistant adds a new object for a modified direct
|
||||
mode file, it neglects to update the mapping for old object, so it
|
||||
incorrectly still maps that object to the file. That bad data could lead to
|
||||
unknown buggy behavior.
|
||||
|
||||
This is complicated by a mapping only being maintained from objects to
|
||||
files, but not a reverse mapping. To get from files to objects currently
|
||||
requires querying git for the symlink target, which is relatively slow.
|
||||
|
||||
At this point the assistant seems to work in direct mode on Linux!
|
||||
Needs more testing..
|
||||
|
|
|
@ -87,9 +87,6 @@ is converted to a real file when it becomes present.
|
|||
* Deal with files changing as they're being transferred from a direct mode
|
||||
repository to another git repository. The remote repo currently will
|
||||
accept the bad data and update the location log to say it has the key.
|
||||
* When the assistant adds a modified direct mode file, it leaves behind
|
||||
an associated files mapping to the file for the old key as well. That
|
||||
needs to be deleted (sync deletes it in the similar situation).
|
||||
* kqueue does not deliver an event when an existing file is modified;
|
||||
need a different way to detect file modifications (possibly an OSX specific
|
||||
interface?)
|
||||
|
@ -114,3 +111,4 @@ is converted to a real file when it becomes present.
|
|||
of `.git/annex/objects/` or hard-linking if the same key is present
|
||||
elsewhere in the tree. **done**
|
||||
* handle merge conflicts on direct mode files **done**
|
||||
* support direct mode in the assistant (many little fixes)
|
||||
|
|
|
@ -33,7 +33,10 @@ any time). To do so:
|
|||
|
||||
## use a direct mode repository
|
||||
|
||||
The main command that's used in direct mode repositories is
|
||||
Perhaps the best way to use a direct mode repository is with the git-annex
|
||||
assistant.
|
||||
|
||||
Otherwise, the main command that's used in direct mode repositories is
|
||||
`git annex sync`. This automatically adds new files, commits all
|
||||
changed files to git, pushes them out, pulls down any changes, etc.
|
||||
|
||||
|
|
Loading…
Reference in a new issue