Trying again with an address the listserv likes. On Fri, 2005-12-09 at 16:50 +0900, Stephen J. Turnbull wrote: > I disagree. The only case where rm -rf is reasonable is in the case > where the content is not corrupt but there's no simple way to resnap > the inodes. I think it's reasonable for you to want this, but if Stefan's > idea about resnapping the links works, wouldn't that be even better?
In arch 1 'resnapping' the inode signature is definately doable, if you
care to. In the simplest form just store the {hash of choice} in the
index file for the revision, and consult that to determine if content
has changed. Oh and store the permissions for the files and reapply
those. Oh, and there are a couple more little gotchas but nothing
insurmountable.
> If the content is corrupt, you always want to know why. Maybe most of
> the time the answer is trivial (a link-unsnapping editor) or it isn't
> worth the effort for most people to actually look and find out. But
> tla should _never_ presume to make that judgment. It should preserve
> the information until explicitly told to destroy it.
Well, for user created information I completely agree. But if you
consider the revision library a leaked-abstraction (as I do), then I
think its reasonable for tla to manage it itself. However I couldn't
find a sane way of doing that in baz... (If memory serves, baz deletes
corrupt *pristines*, not corrupt revision library entries. The rationale
was that we saw many many users move source trees from fs to fs, moving
of revision libraries was much less common, and is subject to a much
greater chance of racing with other operations - atomic renames do not
prevent breaking other processes that are accessing a revlib.)
For a more ambitious improvement on revlibs, consider
http://wiki.gnuarch.org/Win32FriendlyFormats which describes a rev lib
that does not have one-inode per file per revision, rather has one-inode
per file-content referenced. This gives you substantially better disk
utilisation/performance on some common file systems like ext3, NTFS and
HFS Plus. This format can definately be improved upon, it was still in
discussion when we decided to focus on the bzr codebase. That format was
inspired by the first storage format bzr used, and is very similar to
git/arch 2.0.
Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Gnu-arch-users mailing list Gnu-arch-users@gnu.org http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
