Re: [Gnu-arch-users] BUG: feature request: 'tla chmod' which 'touch'es files

[Matthew Dempsky]

John Meinel <address@hidden> writes:

> Matthew Dempsky wrote:
>
>> Why do we need to worry about old signatures at all?
>> Is there something wrong with telling people "when you upgrade from
>> tla $LAST_RELEASE to tla $CURRENT_RELEASE, you will need to delete all
>> of your revlibs and pristine trees"?  It doesn't cause any harm except
>> that the user will need to rebuild them.
>> If it's *really that critical* that they be able to use their
>> existing
>> inode-sigs, I think they can write (or pay someone to write) a little
>> script that would update the sigs to the new format.  Only issue is
>> making sure that permissions are correct which doesn't seem any easier
>> to check for than by just reconstructing the tree.
>
> Well, I know for archives you want to be very careful. I think for
> revlibs, the only thing we would need is for inode sigs to be forward
> compatible. Meaning 1.2.2 can read 1.2.0 sigs, but 1.2.0 can't read
> 1.2.2.

Sure, given the current format of the inode sigs it probably wouldn't
be hard at all to be backwards compatible, but there's the risk that
the revlibs are corrupt (permissions are bad).

> I think the idea about saving trees is that some people might have
> slow downloads, or large revlibs, and wiping them out and restarting
> is a little painful.

Upgrading in general can be painful for people.  Until a few months
ago I was still using tla 1.0, because I didn't have any tla packages
to install (in fact tla on my shell account is *still* 1.0).

Really, how much of a cost is it for someone to wipe their revlibs and
pristines?  Sure, it might take a while, but surely you won't need all
of them immediately after updating, and you could write some simple
scripts to inventory your revlib before and then take care of
recreating your revlib overnight.

>> Hm, I hadn't realized ctime was updated by hard-links... that really
>> blows.
>
> Well, I think it was mentioned earlier that one thing the inode
> checking code should do is update the inode sig if it finds that
> nothing truly changed. It could do this for ctime as well. If 'tla
> changes' found that there was no change in a file, the revlib should
> be brought up to date, and 'tla changes --link' can create the
> hard-links, and then update their ctime. Maybe not, as a hard-link
> could go back across many patch levels. But if ctime is just a flag
> that you need to check for corruption, rather than a hard-fast
> indication of corruption, then if it gets updated, the next time you
> do a check, you make it match.

If a revision library or pristine tree file's inode flags it as
potentially corrupt, with what do you compare it to determine if the
file has changed?

> From my understanding, the only "important" permission to keep track
> of is the "executable" bit. So that when I write a script, it will
> stay executable between checkin/checkout.

Yeah, that seems important to me too.

> All other bits seem arbitrary, as they seem more site-dependent. (On
> my working tree, I might want 664/775, but in public_html, I want
> 644/755)
>
> As far as "ownership". That is something you definitely *do not*
> want. If I check something into my tree, and you check it out, you
> should be the owner. My user most likely does not exist on your
> machine, and you wouldn't have the right to modify a file, or possibly
> even read it.

Both right.

> The other advantage of only paying attention to the X bit is that you
> can check out trees in "read-only" mode, which works pretty well for
> hard-linked trees, just in case you editor doesn't support breaking
> hardlinks.

Emacs supports breaking hardlinks, but if you open a read-only file it
puts the buffer into read-only mode by default (C-x C-q to change to
r-w), and when you save it asks if you're sure you want to save a
write-protected file, and then the new file it creates is still
read-only.  Just seems irritating to me.