Merge branch 'master' into reorg

Conflicts:
	debian/changelog
This commit is contained in:
Joey Hess 2011-03-16 18:47:04 -04:00
commit 3a020e599e
6 changed files with 50 additions and 18 deletions

11
debian/changelog vendored
View file

@ -13,6 +13,15 @@ git-annex (0.20110316) experimental; urgency=low
directory would contain fewer than 1024 files.)
* The setkey, fromkey, and dropkey subcommands have changed how
the key is specified. --backend is no longer used with these.
-- Joey Hess <joeyh@debian.org> Wed, 16 Mar 2011 16:20:23 -0400
git-annex (0.24) unstable; urgency=low
Branched the 0.24 series, which will be maintained for a while to
support v1 git-annex repos, while main development moves to the 0.2011
series, with v2 git-annex repos.
* Add Suggests on graphviz. Closes: #618039
* When adding files to the annex, the symlinks pointing at the annexed
content are made to have the same mtime as the original file.
@ -20,7 +29,7 @@ git-annex (0.20110316) experimental; urgency=low
like metastore to be used with annexed files.
(Currently this is only done on systems supporting POSIX 200809.)
-- Joey Hess <joeyh@debian.org> Wed, 16 Mar 2011 16:20:23 -0400
-- Joey Hess <joeyh@debian.org> Wed, 16 Mar 2011 18:35:13 -0400
git-annex (0.23) unstable; urgency=low

View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://joey.kitenet.net/"
nickname="joey"
subject="comment 3"
date="2011-03-16T17:46:40Z"
content="""
Alright, I've added #idefs and the symlink timestamp mirroring feature will be unavailable on OSX until I get a version that works there.
"""]]

View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
nickname="Jimmy"
subject="comment 4"
date="2011-03-16T20:32:01Z"
content="""
Just tried it out on my mac and it's working again. I guess this issue could be closed for now.
"""]]

View file

@ -1,17 +0,0 @@
git-annex 0.19 released with [[!toggle text="these changes"]]
[[!toggleable text="""
* configure: Support using the uuidgen command if the uuid command is
not available.
* Allow --exclude to be specified more than once.
* There are now three levels of repository trust.
* untrust: Now marks the current repository as untrusted.
* semitrust: Now restores the default trust level. (What untrust used to do.)
* fsck, drop: Take untrusted repositories into account.
* Bugfix: Files were copied from trusted remotes first even if their
annex.cost was higher than other remotes.
* Improved temp file handling. Transfers of content can now be resumed
from temp files later; the resume does not have to be the immediate
next git-annex run.
* unused: Include partially transferred content in the list.
* Bugfix: Running a second git-annex while a first has a transfer in
progress no longer deletes the first processes's temp file."""]]

View file

@ -0,0 +1,12 @@
Branched the 0.24 series, which will be maintained for a while to
support v1 git-annex repos, while main development moves to the 0.2011
series, with v2 git-annex repos.
git-annex 0.24 released with [[!toggle text="these changes"]]
[[!toggleable text="""
* Add Suggests on graphviz. Closes: #[618039](http://bugs.debian.org/618039)
* When adding files to the annex, the symlinks pointing at the annexed
content are made to have the same mtime as the original file.
While git does not preserve that information, this allows a tool
like metastore to be used with annexed files.
(Currently this is only done on systems supporting POSIX 200809.)"""]]

View file

@ -0,0 +1,12 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
nickname="Richard"
subject="comment 7"
date="2011-03-16T21:05:38Z"
content="""
Ah, OK. I assumed the metadata would be attached to a key, not part of the key. This seems to make upgrades/extensions down the line harder than they need to be, but you are right that this way, merges are not, and never will be, an issue.
Though with the SHA1 backend, changing files can be tracked. This means that tracking changes in mtime or other is possible. It also means that there are potential merge issues. But I won't argue the point endlessly. I can accept design decisions :)
The prefix at work is from a university netblock so yes, it might be on a few hundred proxy lists etc.
"""]]