[BUNDLE] save commit messages

[John Arbash Meinel]

Stefan (metze) Metzmacher wrote:
> Hi *,
> 
> I've create a little bundle that stores the commit message
> in a temporary file and only deletes it on success.
> 
> Has anyone an idea how to write a blackbox test for this?
> 
> metze


Write a test in 'bzrlib/tests/blackbox/test_commit.py'

It shouldn't be too hard to create a test which has unresolved
conflicts. And assert that the output of the commit message includes
information on finding the saved commit message.

Some of this should be whitebox tested, IMO. Like, it might be nice to
hook into tree.commit(), and have it unlink the file, so that you know
the later unlink will fail. This is pretty minor, though.

Much more important is that you don't seem to handle the fact that you
need to open the file in binary mode, and that 'message' is more likely
to be a Unicode string, rather than a plain string. Which means you need
to encode the string before writing it to the file. (Or open up a codecs
file which does translation for you). (I'm not positive we want to write
the file in binary mode, we seem to read it in text mode, so writing in
text mode is probably okay. But better to use open(foo, "wt") to make it
explicitly obvious)

Now, we read a file supplied by '--file' as a 'bzrlib.user_encoding'
encoded file, so you should write out the file in that encoding.

Which brings up other encoding headaches. In that you can right now use
'tree.commit(message=X)' to commit any Unicode message you desire. But
since we are serializing it out to a file, it now is possible that it
will not fit in user_encoding. So we have to decide what we want to do.
It seems bogus to fail just because we can't write the Unicode message
to the file. So we could either not create the file if we can't write it
correctly, or we could use encode('replace') which changes un-encodable
characters with '?'.

Perhaps do a plain encode(), and trap an exception, that you will only
report if the commit fails, so that the user knows there may be some
information lost in the commit. This is an edge case, though. So more
important is that we don't abort the test suite because of user_encoding.


I believe the current test suite actually depends on this ability under
Windows, so we will probably see bugs pop up if we don't handle it. At
the very least, we need to do something, so that

I'm not sure if it is better to write the temporary file to '.'. Or if
it would be better to write it to tree.basedir.
I probably would go for 'tree.basedir' especially when you consider that
commit might be being called as part of an api, and '.' is somewhere
completely unrelated.

I think it would be good to say:

'Commit message saved. Use bzr commit --file %s to re-use the commit
message' % (msgfilename,)

You probably should trap the mkstemp() call, in case the user is in a
readonly directory.
There are people who version /etc, and only have .bzr/ as writeable. it
would be nice if they still could commit there. So maybe we should have
a 2-level mkstemp call. First try tree.basedir, and if that fails, use
no pre-specified dir, so that it goes into $TMP.

Sorry to make this so complex. Unfortunately, that is what we get when
we chose to support Unicode, even on platforms that are not 100% unicode
compliant.

John
=:->


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