On Sun, Apr 3, 2011 at 11:35, Dieter Plaetinck <die...@plaetinck.be> wrote:

> - centralized: have 1 (or more) remotes that always keep a copy of the files 
> which are being removed on all other remotes, these would be backup-nodes, 
> they don't follow the strict "always in sync" rule that applies to the 
> regular nodes. (they follow the original git-annex idea more strictly)

FWIW, there has been talk about using bup as a storage back-end for
git-annex. That would allow you to keep full revision history and all
files in one or two main locations and just use plain git-annex on the
other ones.

> - decentralized: allow users to "remove files" by removing the symlink, but 
> still keep the blob in .git-annex on at least one of the nodes, so that it 
> can be restored from that.

Leaving a stale object in the store that no one really knows about
seems like an extremely bad idea. And even if git-annex were able to
track its existence internally while hiding the symlink from the user,
I fear this would cause confusion. I would prefer a way to properly
delete a file from all repos, but the bup-backed one would obviously
still keep everything around. Of course, you wouldn't need the bup
back-end for your podcasts, but for photos or other important personal
data, it would be useful.

vcs-home mailing list

Reply via email to