Re: [Gnu-arch-users] Cacherevs ignored by tla library-add -s

[Martin Langhoff]

> What do you think of having libraries default to being non-sparse &
> greedy ?

It'd be great, but then it could potentially grow without the user
being explicitly aware. In that sense a default of non-greedy makes
sense, but makes the library less useful (or perhaps I was using it
wrong -- how do you get nongreedy/nonsparse to be automagically
useful?).

In my mind, the ideal scenario would be to incorporate the
functionality of 'shrink-library' to the library-handling code, and
provide a set of tunable parameters for the library. From there, the
library should be managed 'transparently', with a few tunables like
max revisions in library and max disk space, so that everytime a
revision is added, the library code evaluates whether to prune itself.
Revisions added manually with library-add should be marked specially
and not removed. The tunables should be settable on a per-repo and
per-project basis as well.

Mind you, this automagic behaviour works nicely for a well-connected
LAN/WAN/Internet scenario, with all/most of the repositories always
available. Other scenarios, like disconnected operation, still require
a greedy/nonsparse and potentially huge revlib.

While arguably narrow-scoped, the reason I'd like to have a smarter
revlib is because I am somewhat disappointed with shared revlibs, and
we are back to per-developer revlibs. Even on the local disk, sharing
the library between two or more users (relaxing umask, making group
sticky, etc) is possible, but gets tla endlessly confused about
permissions, because it compares the permissions with the permissions
in the library literally.

If that's the way it's meant to be, shared revlibs are a nightmare --
we kept doing undo and removing the "meta" files before redo-ing. I
suspect the library code should keep a few files describing what the
metadata should look like, instead of relying on the literal file
metadata in the library.

regards,


martin