From a1a04874986dbac8a7ccaf58164069fac030e80f Mon Sep 17 00:00:00 2001 From: Stan Date: Tue, 28 Jun 2016 23:07:16 +0000 Subject: removed --- .../comment_2_c84054b4174bb89009147ab874891f7a._comment | 17 ----------------- 1 file changed, 17 deletions(-) delete mode 100644 doc/forum/v5_to_v6_upgrade_strategy/comment_2_c84054b4174bb89009147ab874891f7a._comment (limited to 'doc') diff --git a/doc/forum/v5_to_v6_upgrade_strategy/comment_2_c84054b4174bb89009147ab874891f7a._comment b/doc/forum/v5_to_v6_upgrade_strategy/comment_2_c84054b4174bb89009147ab874891f7a._comment deleted file mode 100644 index 6933cb7a8..000000000 --- a/doc/forum/v5_to_v6_upgrade_strategy/comment_2_c84054b4174bb89009147ab874891f7a._comment +++ /dev/null @@ -1,17 +0,0 @@ -[[!comment format=mdwn - username="Stan" - subject="comment 2" - date="2016-06-28T23:04:57Z" - content=""" -Many thanks for the reply. I did not add too much detail to my post as it was my first, and I was a bit shy. - -I did do all of the steps indicated re v6. The binary has been fine for me also. - -My question is a bit more complex as I am looking to apply v6 at some point to a set of distributed repos. Essentially it has the typical duplicated system topology: 2 remotes, several clients, each of which is linked to both remotes. Thus it will survive multiple failure scenarios. - -I would be looking at the strategy of the order of repo upgrade. Say, a client first, and run a set of tests. And so on. Remotes last perhaps. - -In any case I build a test bed as above and have been experimenting with a single client at a v6 repo. - -So far it has been smooth, but right now I seem to be stuck where thinning is not having any effect: I still have a particular big file (1.5GB) in both the annex and the working dir. Lock removes the big file from the working dir, and leaves a link, and unlock restores the big file in the working dir. Yet, the annex still contains the big file no matter what. I was under the expectation that one of the big file copies would go away. -"""]] -- cgit v1.2.3