From cb192eafed9ebbe1da3e08746e7103a83528a31b Mon Sep 17 00:00:00 2001 From: Spencer Date: Fri, 2 Aug 2024 04:37:11 +0000 Subject: [PATCH] removed --- ...comment_4_af837321a3f4ab5dfee2be11a9129d98._comment | 10 ---------- 1 file changed, 10 deletions(-) delete mode 100644 doc/forum/remote-specific_meta-data/comment_4_af837321a3f4ab5dfee2be11a9129d98._comment diff --git a/doc/forum/remote-specific_meta-data/comment_4_af837321a3f4ab5dfee2be11a9129d98._comment b/doc/forum/remote-specific_meta-data/comment_4_af837321a3f4ab5dfee2be11a9129d98._comment deleted file mode 100644 index abcbeae578..0000000000 --- a/doc/forum/remote-specific_meta-data/comment_4_af837321a3f4ab5dfee2be11a9129d98._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="Spencer" - avatar="http://cdn.libravatar.org/avatar/2e0829f36a68480155e09d0883794a55" - subject="Necro" - date="2024-08-02T04:10:32Z" - content=""" -This is rather old, but I find it a good question. For example if I clone from a clone, the new clone will have metadata about the original origin - assuming annex was used - in the form of a uuid, but no way of tracking where that uuid came from or might be. - -Last known paths might help, or some sort of ‘client-host’ metadata for each normal repo that’s recorded whenever a certain repo has others configured as its remotes. Specifically in an `A<-B<-C` configuration, B might register A as its host, and B as a client of A so that when B and A sync, B is added to A’s client list, or if B and C sync first, C is registered as B’s clients and can see that B has A as a host. -"""]]