gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: Making --setup default in tag and import


From: Mikhael Goikhman
Subject: Re: [Gnu-arch-users] Re: Making --setup default in tag and import
Date: Wed, 9 Feb 2005 23:06:08 +0000
User-agent: Mutt/1.4.2.1i

On 09 Feb 2005 09:38:45 -0800, Tom Lord wrote:
> 
> In your list of solutions you omitted the one that I think is probably
> cleanest: extending the namespace.   For example, right now we can have
> a revision called:
> 
>       patch-1
[...]
>       patch-1.del
[...]
>       patch-1.2

This is a conservative solution. It would solve the problem of Michael
(corrupted revision), but not most of the other problems including the
ones suggested by Aaron and yourself (unintentional or insane commit, a
typo in import or tag, nuclear codes). The preferable solution for this
kind of problem (in some sense cleanest) is to destroy the history rather
than backtrack. This solution has a minimal impact on performance
(or zero if you don't insist on consistency). This is why I suggested
replacing by destroying rather than replacing by addition, as you did.

If we allow to consider a timestamp solution, then it may be something
like: keep the global list of invalid timestamp-revisions in =meta-info,
then any archive operation in a tree would first query for new invalid
timestamp-revisions, and invalidate the tree if needed. That would be
one extra archive file access (we already have many).

I am aware that no solution working in 100% of cases may be implemented
with (remote) timestamps, but something like 99.9% is certainly possible.
We should also not underestimate the communication factor. One web or
mailing list message containing a warning is usually enough to eliminate,
say, 90% of dependencies. So the error is reduced greatly. I know that at
least one person on this list will not use a solution that gives 0.01% of
errors, but most of the people will be happy to use such stable solution.
The error is often not critical, a tree was not invalidated (some futher
operations may fail), or was mis-invalidated (this is fixable by re-get).

It may be easier though (but not safer) to have a third party software
that performs a comfortable cheating in archive, for those who needs it.

Regards,
Mikhael.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]