Hello,
I think it is really great that you are doing this.
On Monday 25 May 2009 13:33, Ganesh Sittampalam wrote:
> Hi,
>
> Coming up with a decent way of handling the CRC errors is proving a bit
> fiddly :-( We need to not scare the user too much or substantially upset
> the operation of normal commands, but also encourage them to fix their
> repos. So far I've come up with the following strategy:
>
> gzReadFile in ByteStringUtils detects broken CRCs, and writes to a global
> variable to indicate this (adding one more to Darcs.Globals :-( )
>
> Unless Quiet is in the options, Darcs.RunCommand installs an atexit
> handler to inspect the global and print out a short message if
> appropriate. Something along the lines of "Warning: CRC errors found.
> These are probably harmless but should be repaired. Run darcs
> <something> for more details."
I would find it very useful to report some details about where the problem (or
problems) is/are located, not least to enable a decision on where (local,
remote, cache that you mention below) to apply the repair.
>
> darcs <something> will check a bunch of files (see below) and also provide
> a full explanation of the problem to the user.
>
> It seems like corrupted CRCs might be found in any of
> {patches,inventories,pristine.hashed} of any of {the repository we're in,
> any other repository involved in a pull/push/get etc,any caches}. I
> propose to have a command that checks or repairs just the local repository
> + caches; it makes sense to have to repeat that command on the other
> repository if necessary given that it might be on a different
> machine/controlled by someone else. When repairing we'd also have to leave
> out readonly caches.
>
> The biggest issue I need feedback on now is the appropriate command-line
> interface to the check/repair commands. The natural choice would seem to
> be to add an option to darcs check and darcs repair. However, this
> actually interacts badly with the natural functionality of these two
> commands, which is to check/repair the pristine state by replaying the
> patch sequence. We shouldn't conflate the two, especially since even check
> can cause more patches to be downloaded into a lazy repository. We could
> make a 'gzcrcs' option that overrides the other check/repair functionality
> completely, but it would seem rather odd anf confusing.
>
> So my current plan is for a completely separate command,
I heartily support a separate command, in that way it can also be removed more
cleanly at a later stage.
> darcs gzcrcs
> {--check,--repair}. It probably wouldn't be listed in the standard help,
> but obviously the short message above would point the user at it.
>
> Thoughts?
>
> Cheers,
>
> Ganesh
> _______________________________________________
> darcs-users mailing list
> [email protected]
> http://lists.osuosl.org/mailman/listinfo/darcs-users
>
Thanks and best regards
Thorkil
_______________________________________________
darcs-users mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-users
