From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Sickel Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Message-Id: <3D645A08-D276-423C-BA62-700A536A033B@corpus-callosum.com> Date: Fri, 4 Apr 2014 00:39:07 -0500 References: <5332c061.924ab40a.15cc.55a2@mx.google.com> <20140402071913.72076a71@zinc.9fans.fr> <2968a2c260ea9a1c5c75c91ec9f1ea84@brasstown.quanstro.net> <20140403075006.0ab35e51@zinc.9fans.fr> <4e95272faa3b0b38eec77c00bc56bc2d@brasstown.quanstro.net> <20140403195715.043e0146@zinc.9fans.fr> In-Reply-To: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] Python/Mercurial error Topicbox-Message-UUID: d6925bd2-ead8-11e9-9d60-3106f5b1d025 > On Apr 3, 2014, at 1:04 PM, Ramakrishnan Muthukrishnan w= rote: > I tried cloning the go repo multiple times with the new hg and I get > the error *everytime*. :( What file system are you using? Have you tried 'hg clone -U'? There are a few cases with hg where the repository your trying to clone has a= file stored in its repo that is longer than a valid path on certain Plan 9 f= ile systems. This is the case for go, python, and a few other prominent rep= ositories. In the case of go, getting the repo cloned without the update ca= n work, because it doesn't fail during the file walk that would be invalid d= uring temporary reconstruction if the work area file space. Then an update t= o tip later will actually work because it bypasses the garbage file that was= replaced|moved in a later commit. - jas