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. Richard _______________________________________________ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
