Hi,
Stefan Monnier <[EMAIL PROTECTED]> writes:
> The ones I tried at first all used recency to decide what to delete.
In fact, `tla-prune-revlib' in `tla-tools' (by Miles Bader) is slightly
more sophisticated than this. It allows the combination of several
heuristics:
--min-age=NDAYS
> Yes, this is a good idea. I never used these wrappers and I do not know
> if many people have used these wrappers. Would any satisfactory users of
> such wrappers come forward to share your experience with the revsion
> library management of, say, FAI? Good strategies would be a great
> additi
Yes, this is a good idea. I never used these wrappers and I do not know if
many people have used
these wrappers. Would any satisfactory users of such wrappers come forward to
share your
experience with the revsion library management of, say, FAI? Good strategies
would be a great
addition int
> "Mikhael" == Mikhael Goikhman <[EMAIL PROTECTED]> writes:
Mikhael> But I can't love a software (any) that allocates massive
Mikhael> ever-growing cache without asking.
I basically agree with Stefan about what the default should be---a
sparse, greedy revlib. Suppose that's what we e
On 07 Dec 2005 17:44:45 -0500, Stefan Monnier wrote:
>
> I have misunderstood, sorry. But now I don't see why this situation
> you're describing is any different from the one we have now (except
> that now those files are in a pristine rather than in a revlib).
>
> > You claim (quoted) that manu
Stefan Monnier <[EMAIL PROTECTED]> writes:
> Huh? Have you ever lived at a place where all HOMEs are on NFS?
Have you ever seen a company where some HOMEs are _not_ on NFS?
;-)
(Yes, I'm exagerating a bit, but HOMEs on NFS are a very common
solution when you have one sysadmin in charge of file
>> >> I really wish tla stopped supporting pristines and just forced the use of
>> >> a greedy revlib (which would be setup automatically in a default location,
>> >> if needed).
>>
>> > This would be insane. You suggest that whenever someone requests a tree
>> > of 1000 files, 10Mb, tla should cr
On 06 Dec 2005 23:13:27 -0500, Stefan Monnier wrote:
>
> >> I really wish tla stopped supporting pristines and just forced the use of
> >> a greedy revlib (which would be setup automatically in a default location,
> >> if needed).
>
> > This would be insane. You suggest that whenever someone requ
>> I really wish tla stopped supporting pristines and just forced the use of
>> a greedy revlib (which would be setup automatically in a default location,
>> if needed).
> This would be insane. You suggest that whenever someone requests a tree
> of 1000 files, 10Mb, tla should create million of fi
Stefan Monnier wrote:
>>>Why settle with "often enough" when you can have revision-libraries?
>>>I really wish tla stopped supporting pristines and just forced the use of
>>>a greedy revlib (which would be setup automatically in a default
>>>location, if needed).
>>>
>>>
>>There are some cas
Mikhael Goikhman <[EMAIL PROTECTED]> writes:
> In almost no cases. If it is a commit-only tree, you need a pristine
> only; if it is a replay-only tree with local changes, a pristine again.
If it's /replay/ (not update or merge), no pristine should be needed.
> A good (compact and fast) solution
On 05 Dec 2005 21:09:58 -0500, Michael Poole wrote:
>
> Mikhael Goikhman writes:
>
> > This would be insane. You suggest that whenever someone requests a tree
> > of 1000 files, 10Mb, tla should create million of files occupying 10Gb.
> > [This is optimistic, since just nodes alone of typical 4Kb
Mikhael Goikhman writes:
> This would be insane. You suggest that whenever someone requests a tree
> of 1000 files, 10Mb, tla should create million of files occupying 10Gb.
> [This is optimistic, since just nodes alone of typical 4Kb occupy 4Gb.]
Wow! How many 1000-file, 10 MB projects have mill
On 04 Dec 2005 11:42:19 -0500, Stefan Monnier wrote:
>
> > Disagree. Revision libraries although nice to have are not needed for
> > real work with tla. Pristines and periodical cacherevs are often enough.
>
> Why settle with "often enough" when you can have revision-libraries?
Because revlib is
>> Why settle with "often enough" when you can have revision-libraries?
>> I really wish tla stopped supporting pristines and just forced the use of
>> a greedy revlib (which would be setup automatically in a default
>> location, if needed).
> There are some cases when one does not need either.
Co
Stefan Monnier wrote:
>>Disagree. Revision libraries although nice to have are not needed for
>>real work with tla. Pristines and periodical cacherevs are often enough.
>>
>>
>
>Why settle with "often enough" when you can have revision-libraries?
>I really wish tla stopped supporting pristines
> Disagree. Revision libraries although nice to have are not needed for
> real work with tla. Pristines and periodical cacherevs are often enough.
Why settle with "often enough" when you can have revision-libraries?
I really wish tla stopped supporting pristines and just forced the use of
a greedy
Matthew Hannigan <[EMAIL PROTECTED]> writes:
> On Fri, Nov 25, 2005 at 06:57:06PM +, Andrew Suffield wrote:
>> > Besides, a revlib consumes a _huge_ amount of inodes that constitutes a
>> > real problem in many cases (compared to one tarball per 50 revisions).
>>
>> git already proved this is
>> * the number 50 is hard coded; it really should be a value that the user
>> can customize.
> Before this is viable, it *must* be possible to turn this behaviour
> off. On large trees, cacherevs are massively wasteful of space;
> revision libraries are often a more efficient solution.
I use a
Matthieu Moy wrote:
>
> My sysadmin was a bit angry while reinstalling my machine (with a
> newer distro), since I didn't delete my revlib before that, and the
> backup+restore of the 2 or 3 Gb of revlib I had took several hours.
>
> He would have been even more angry if I told him how long it to
Mikhael Goikhman <[EMAIL PROTECTED]> writes:
> Besides, a revlib consumes a _huge_ amount of inodes that constitutes a
> real problem in many cases (compared to one tarball per 50 revisions).
My sysadmin was a bit angry while reinstalling my machine (with a
newer distro), since I didn't delete my
Matthieu Moy wrote:
>
> That's even more complex than it seems to be, because (from my
> experience) latency is usually more important than bandwidth. So it
> may be faster to download one 5Mb cachedrev than 50 patches of 10Kb
> each.
Agreed. Optimizing for remote archives is quite different than
o
"Alfred M\. Szmidt" <[EMAIL PROTECTED]> writes:
> So if you have a tree that is 300MiB, and you fix a couple of
> documents over 50 revisions, the total size of the patches might be as
> low as 300KiB, but using the `number of patches' algorithm, you will
> end up with a new cacherev that takes up
Agreed. Optimizing for remote archives is quite different than
optimizing for local archives. IMHO tla always sort of dodge this
problem by picking some middle position.
One should always pick a middle position, that way both parties get
benefits without a single party getting screwed.
> So if you have a tree that is 300MiB, and you fix a couple of
> documents over 50 revisions, the total size of the patches might
> be as low as 300KiB, but using the `number of patches' algorithm,
> you will end up with a new cacherev that takes up 300.3MiB. Not
> very smart.
25 matches
Mail list logo
