baz-import test requires 'testresources'

[John Arbash Meinel]

Martin Pool wrote:
> On 12 Dec 2005, John Arbash Meinel <john at arbash-meinel.com> wrote:
> 
>>The baz-import test suite tries to import something called "testresources".
>>This is a module/package that I don't have installed on my system. Is it
>>a 3rd party toolset that is available?
>>I tried looking in Ubuntu Synaptic, and I didn't find anything called
>>"testresources".
>>
>>I want to work on writing a test case for my "--continue-on-errors"
>>flag, but as it stands I can't run the test suite.
> 
> 
> I think this is Robert's module. 

Is it something publicly accessible? For something as 'core' as
bzrtools, should it be depending on a not-generally-available module?
(I know if you have bzrtools installed, and don't have testresources,
then bzr selftest will fail, because it can't load that test_baz_import.
You have to run bzr --no-plugins selftest, which means you can't test
your other plugins)

> 
> 
>>Also, I need a workaround for the current baz-import using "Arch:" as
>>the revision identifier prefix. I really want to switch one of my
>>repositories from Arch to bzr, but I have to be able to check it out on
>>Windows.
>>I was thinking about just hacking the code to use "Arch-" instead, and
>>just do a one-time conversion and not worry about it in the future. But
>>I would really prefer to do the "correct" thing.
>>
>>Though as a side note, if we just decide to prohibit non-filesystem safe
>>revision identifiers (or encode them on disk), I realized that this
>>probably could be done outside of "bzr upgrade". We no longer keep track
>>of revision sha1's (and we never look at the inventory sha1 either,
>>maybe we do in 'bzr check'). But anyway, a simple script that goes
>>through all of the revision store and renames the files, and renames the
>>internal identifiers should be enough.
>>It probably could be done with a simple regex substitution, since at
>>present the revision identifier is not present in any hashes. (It would
>>be present in the .sig file, but as of yet, that isn't really used).
> 
> 
> Well, I would have preferred to just allocate IDs that used a safe
> subset of ascii, but the weight of opinion is that they should be
> escaped in the storage layer.  That seems to suggest we need a format
> upgrade where in the new format they're written out escaped.
> 

I think we could restrict IDs because they aren't meant to convey
information directly (they happen to have usernames, but more for
uniqueness than because we are trying to tell someone something).

Can email addresses have non-ASCII characters? I'm thinking someone like
Erik Bagfors (sorry about not marking the a, I don't know how to do it).

Just to ask where non-ASCII characters could show up in ids. File-ids
are already sanitized. (An all arabic filename gets a file id of
'-2005090123132-234aa4a4ha43a')

I think right now, all id's are ASCII. The problem is we need to go one
step further and make them a subset of ASCII.

So no matter what, we need some sort of upgrade, to get the baz-import
non-filesystem safe characters out.

How close are we to other things that would need a format upgrade?
Knits, moving revisions into a weave, etc?

John
=:->
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051213/91e8895a/attachment.pgp