[Top][All Lists]

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

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

From: John Meinel
Subject: Re: [Gnu-arch-users] BUG: feature request: 'tla chmod' which 'touch'es files
Date: Sat, 25 Sep 2004 17:26:53 -0500
User-agent: Mozilla Thunderbird 0.8 (Windows/20040913)

Matthew Dempsky wrote:
Aaron Bentley <address@hidden> writes:

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.

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.

Also, if checking timestamp, which one are you checking? As I
recall, mtime is the last modification to the file, but ctime is the
last update of permissions.

We use mtime.  Unfortunately, ctime is modified by operations we wish
to ignore, like adding hard-links.

Hm, I hadn't realized ctime was updated by hard-links... that really

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 we're going to start including permissions info in the inode sigs
file, we need to decide what to do about ACLs if anything.  I've
talked to a few people who seem to think this is a big deal, but arch
doesn't even "correctly" handle ownership changes in files.  On the
other hand, is there even any way to give good semantics for those
kinds of things in Arch?

I wonder if permissions aren't just outside the scope that arch should
be trying to address anyways.  It would seem ugly trying to
interroperate between two companies where one requires a umask of 077
while the other might have no requirements and everyone just defaults
to 002 or 022.

Yeah, they could do some arch magic like one company tags off a
branch, changes permissions and commits, then has the other company
tree-sync with the revision, but they'll have to repeat that each time
a new file gets added to the source tree.

Does having arch manage permissions do us any good?  Do other revision
control systems try to do this?  Are they considered successful?
Would anyone be opposed to dropping this feature?

(The last question isn't so much a serious proposal, but a
solicitation for feedback on if there are any uses for trying to
manage permissions in a distributed environment.)

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.

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.

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.


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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