[BUG] transport/memory.py doesn't handle strings

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Collins wrote:
> On Tue, 2005-10-18 at 16:45 -0500, John A Meinel wrote:
> 
>>There are a couple of changes that should be made to the
>>transport/memory.py implementation.
>>First, most of the "put" functions can take either a file-like object, or
>>a string. Which means that MemoryTransport.put() shouldn't just call
>>read(), it should also check to see if it is already a string. (Either
>>that, or we can change the api if you really prefer).
> 
> 
> I think that the ambigious api is very strange. I'd much rather have
> explict put_stream, put_string etc.

I'd rather have put_iterable, because files are iterables of strings,
but so are lists, and so are strings.  So all of these have the same result:

put_iterable('hello')
put_iterable(['hel','lo'])
put_iterable(StringIO('hello'))

I can always adapt an interable into a file, but why bother when we only
need an iterator of strings in the first place?

>>I'm also concerned that MemoryTransport.clone() returns the exact copy of
>>itself. Because one of the fundamental bits of Transport objects is that
>>they have a "base" where all paths are given relative to that base.
>>
>>Since all files and directories are stored inside the dictionary as
>>relative paths, clone(offset=".bzr/") will fail. And this type of cloning
>>is used in bzrlib/branch.py so that the Store objects have "base" set
>>appropriately.
> 
> 
> In bzrlib/branch.py, cloning at the top is checked for by
> 'new_transport.base == old_transport.base'. I was duplicating that
> interface.

There should be a test for transport.base != transport.clone('a').base.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDVZWX0F+nu1YWqI0RAmk2AJoDX83AkCKdipkhHGJztmZluJGDpgCeOOIQ
II+EMRv+DxWXf/LCn85B5BY=
=vaNA
-----END PGP SIGNATURE-----