bzr read-only errors need improvement (was Re: bzr requires write permissions to root directory of repository)

John A Meinel john at arbash-meinel.com
Mon Feb 20 14:56:08 GMT 2006


martin f krafft wrote:
> also sprach Alexander Belchenko <bialix at ukr.net> [2006.02.20.1157 +0100]:
>> May be because it's very possible that in ./bzr/tmp will grow junk
>> files when some operations fails for some unpredictable reasons.
>> Who then should clean this dir?
> 
> bzr check for sure. it would also be trivial to add a warning
> mechanism to warn about unexpected files in there on every
> operation... apart, those junk files are hardly going to consume
> much space...
> 

But how would you then swap the file in $wd/.bzr/tmp for the file
$wd/.bzrignore

I know you have mentioned 're-use the existing inode', which you could
do with a truncate + write, I guess. But I know most bzr operations are
'write to a temp file + rename over existing file' since that is atomic
on posix platforms.

We don't have to have atomicity for something like .bzrignore, but it is
nice to have ^C not corrupt a file.

Now, I will say that .bzrignore is probably going away, to be replaced
by a meta-only file. (No longer user-editable).

And after Aaron Bentley's TreeTransform code, I believe we use
$wd/.bzr/limbo instead of $wd/bzr-tree-change

Though I will say that doing 'bzr revert' without having write access
seems a little bit funny to me.

I realize you have taken great pains to set up all of your read and
write access (so .bzr/ is writeable, but $wd is not, but $wd/some/path
is writable, etc). I think you are being a little abusive to the system,
but it is likely that we will be able to support your use case without
too much difficulty. More by happenstance than by design.

You still have the issue of the temporary log message on commit. Which
we have discussed putting into .bzr/ though we really want to avoid
putting files a user would modify in there. I believe both svn and cvs
have the property that their meta directories are not generally to be
edited by users. (You can if you know what you are doing, but bzr is the
same way.) It was very bad in Arch to not know which ones were okay to
modify and which ones weren't.

John
=:->


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060220/ade8fe8a/attachment.pgp 


More information about the bazaar mailing list