Added a comment

1 files changed, 17 insertions, 0 deletions

diff --git a/doc/forum/v5_to_v6_upgrade_strategy/comment_2_ef2648a58037b867e2d745eb4b3a15a2._comment b/doc/forum/v5_to_v6_upgrade_strategy/comment_2_ef2648a58037b867e2d745eb4b3a15a2._comment
new file mode 100644
index 000000000..e39d8f268
--- /dev/null
+++ b/doc/forum/v5_to_v6_upgrade_strategy/comment_2_ef2648a58037b867e2d745eb4b3a15a2._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="Stan"
+ subject="comment 2"
+ date="2016-06-28T23:10:07Z"
+ 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 built 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 remove 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.
+"""]]