baz-import test requires 'testresources'

[John Arbash Meinel]

Aaron Bentley wrote:
> John Arbash Meinel wrote:
> 
>>>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?
> 
> 
> Yes.  The bzr branch is here:
> http://www.robertcollins.net/unittest/testresources
> 
>  For something as 'core' as
> 
>>>bzrtools, should it be depending on a not-generally-available module?
> 
> 
> Umm, I don't know how to cope with this statement.  Now that there's
> native push, bzrtools isn't actually required for basic operations, and
> that was always the intent.  It's not core, and the barrier-to-entry is
> lower.
> 
> And you're talking about the requirements of Robert's branch-- the
> mainline does not (yet) have this requirement, because Robert has
> declared that his branch isn't ready to be merged.
> 
> I think he did say that testresources should be optional, at one point.
> 

Sure, but the mainline isn't really the official baz-import either, is
it? Anyway, as long as I can get to testresources it isn't terrible. But
I think we need some way to allow the test suite to still load plugin
tests (at least other tests), even if something like this is missing.

> 
>>>I think we could restrict IDs
> 
> 
> We certainly can, but that simply moves the encoding/decoding into
> baz-import, and means that any other tool that wants meaningful ids,
> (e.g. Tailor, foreign branches) need to perform their own conversions.
> 
> 
>>>because they aren't meant to convey
>>>information directly
> 
> 
> I am trying to convey information directly, using them.  Specifically, I
> am trying to convey "This revision was converted from Arch revision FOO
> using algorithm bar".  This is useful to both users and tools.  If the
> encoding is done by baz-import, then the tools users typically use that
> show revision IDs (log, cat-revision) will be unable to produce the
> unencoded form.

So what about the fact that you are already translating the '/' in arch
revisions into %. Should that also be handled at the bzr encoding layer?
Certainly bzrlib could urlencode things (so it would show up as %2F).

I think we should put in *some* sort of restrictions (for example,
newline is a really bad id character, and '/' isn't all that nice
either, control characters are also not wise).

So we can be a little flexible about what are standard is, and what we
encode versus what other tools have to handle. But I don't think we want
to switch and say "we will encode everything, you can give us any binary
blob of bytes".

> 
> 
>>>(they happen to have usernames, but more for
>>>uniqueness than because we are trying to tell someone something).
> 
> 
> They have both usernames and filenames, and I've found both useful in
> debugging.  Heck, we can still tell who's to blame for the two ghost
> revisions in the bzr tree. :-)

Technically, Martin is responsible because he set the 'pending-merges'
by hand before anything was implemented to pull across the changes. :)
Besides, I was just making sure bzr had builtin tests for missing revisions.

> 
> 
>>>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).
> 
> 
> You can have unicode domain names, can't you?   Ahh, the joys of Punycode.

Well, you can have encoded urls, which will sometimes be displayed as
unicode, but due to security concerns may also be displayed as their
standard representation.
So we could disallow unicode, and require people to give the punycode
representation. Since that is the 'true' domain name.

However, it might also be nice to go back and to allow unicode back into
both file-ids and revision-ids, since then unicode filenames would still
have their filename in their id. (Though remember, id's don't change,
which is why weave.py still has the id 'knit.py-abaoeu')

> 
> Aaron

Ultimately I don't care. Whether we encode them before writing them to
disk, or we just disallow the characters. I just want filenames on
Windows that work, so I can finally get rid of my Arch branches.
I was actually thinking to just hack the bzrtools code to use 'Arch-'
and just do a conversion (since it is likely to be a one time thing, or
at least I'll be the only one doing the conversion).
I have a project that I worked on which is willing to switch to bzr, and
I would really like it to do so.

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/edb10888/attachment.pgp