On Wed, Dec 27, 2017 at 8:35 PM, Lars Schneider
<larsxschneider@xxxxxxxxx> wrote:
>
>> On 27 Dec 2017, at 17:49, SZEDER Gábor <szeder.dev@xxxxxxxxx> wrote:
>> Using an ever-growing flat text file might seem like asking for
>> trouble on the long run, but it's perfectly adequate for this purpose.
>> Contributors' topic branches are short-lived in general, so this file
>> won't grow large enough to cause any issues. Grepping through several
>> tens of thousands such lines is sufficiently fast, so not even
>> git/git's forever living integration branches will cause scalability
>> issues with the current rate of ~1 push/day for a couple of decades.
>> And even if we reach the point that this file grows too big, the
>> caches can be deleted on Travis CI's web interface.
>
> One more thing:
> Maybe we could delete "$HOME/travis-cache/good-trees" if the file
> has more than 1000 lines *before* we add a new tree?
>
> Or we use something like this to cap the file:
>
> echo "$(tail -1000 $HOME/travis-cache/good-trees)" > $HOME/travis-cache/good-trees
Well, there is always something new to learn.
I was aware that things like 'cmd file >file' don't work, because the
shell opens and truncates 'file' before executing the command, so 'cmd'
will open the already empty file, but I didn't know that 'echo "$(cmd
file)" >file' works. Thanks for letting me know.
However, this is subject to the portability issues of the shell's
'echo', i.e. try
echo "$(cat git.c)" >git.c
with Bash and Dash. Bash produces the exact same contents, but Dash
turns all '\n' in help and error strings to real newline characters.
Now, Git's object names will never contain such characters, and most
likely $TRAVIS_JOB_{NUMBER,ID} won't ever do that, either, so this is
not an issue for this 'good-trees' file. Still, I think it'd be better
to stick to using a good old temporary file:
tail -1000 good-trees >tmp
mv tmp good-trees
> I agree that the "always growing problem" is not a big one
> but an approach like the one above would avoid any discussion
> for sure.
