Re: [Nano-devel] questions about uniquely numbered backups

[Benno Schulenberg]

On Tue, Apr 28, 2015, at 22:52, Mark Majeres wrote:
> Maybe there is a better algorithm for generating a unique ID?
> Wouldn't using the system time, to the nearest second, be sufficient?

That would be an idea.  But it would be a user-visible change:
whoever uses this backup feature will hate us changing the
naming scheme.  So I don't want to go there.  (Also: Emacs
uses a similar ordinal numbering scheme, but it is cleverer
about it: by default it will keep only the first two and the
last two of these numbered backups.  (It is also cleverer
about making a normal, unnumbered backup: it will make a
backup only the first time you save a file.  In nano, when
you do ^O <Enter> twice, the backup and the current file
will have identical contents; which is pointless.))


On Wed, Apr 29, 2015, at 03:40, Eitan Adler wrote:
> If nano dosn't do this already, it should start sharding files into
> multiple directories inside the backup store.  Having millions of
> files in a single directory will result in slowness regardless of the
> algorithm used to generate filenames.

Hmmm... no.  Sharding is not a responsibility of nano.  If people
really want to keep thousands of backup files, they should implement
a sharding scheme themselves.  Emacs doesn't do sharding (nor does
it need to, because it deletes the pointless in-between backups),
and Vim isn't even able to make numbered backups, as far as I can
tell.

At first I thought to make nano stop at one hundred or one thousand
backups, to make the user aware that he is doing something silly:
what is he going to do with one hundred versions of the same file,
each a little different from the earlier one?  If it is intended as
a primitive kind of version control, well, then a hundred thousand
possible versions should be more than enough.

Benno

-- 
http://www.fastmail.com - Access your email from home and the web