[MERGE] init remote branches

John Arbash Meinel john at arbash-meinel.com
Tue Jul 4 21:16:00 BST 2006


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

Wouter van Heyst wrote:
...

> 
> Is doing a transport.has() first never better? Changing to EAFP style.

See Aaron's comment, which I agree with. has() adds a round trip,
without actually giving you anything you care about. The exception has
the same information, and means you got work done with your round trip.

> 
>> Also, you aren't supporting:
>>
>> bzr init --create-prefix sftp://foo
>>
>> Which means that we only support 'init' 1-layer deep, which should at
>> least be documented.
> 
> There was a comment in cmd_init:
> 
>             # The path has to exist to initialize a
>             # branch inside of it.
>             # Just using os.mkdir, since I don't
>             # believe that we want to create a bunch of
>             # locations if the user supplies an extended path
> 
> introduced by mbp at sourcefrog.net-20051031120610-da41deafd12fdbb8 , merged in
> 1498. --create-prefix seems to have been introduced in 1495 for push.
> 
> I think doing an optional --create-prefix for init, init-repo and branch also
> is fine.


Actually, I think I wrote that (it sounds like me :). I didn't want 'bzr
init' to automatically create a whole path, just because of an early
typo. But especially since the path can now be remote, so it is
difficult for the user to create themselves, I think having a user
option  (--create-prefix) is good.


> I originally copied the 'from bzrlib.transport import get_transport' and
> transport = get_transport(location) for init from here, until Robert mentioned
> the function local import was undesirable. I think Aaron has good
> reasons for importing the function, but I also think you bring up good
> reasons not to. I would probably go for importing the module on account
> of hooking in the general case. get_transport is accomodated well enough
> to hook in extra transports already though, so here not having to use
> bzrlib.transport.get_transport() might win. Any objections to switching
> back to that style?
> 

I would give you two options:

from bzrlib import transport
...
t = transport.get_transport()

or

bzrlib.transport.get_transport()


I'm planning on doing some demandload work in the near future, and I'm
going to be switching (effectively) to the first form.

I'll actually be doing

demandload(globals(),
	' bzrlib:transport,osutils,branch,workingtree'
)

Which creates a proxy object named transport, osutils, etc.


...

> The tests suffered from not being entirely TDD. The assertFalse should
> actually be in the test_init_existing_branch method, but since
> bzrdir.has_workingtree() only works on local paths, I return
> AlreadyBranchError in both cases and the tests pass, even though
> logically the assert is in the wrong place.
> 
> Thanks for the review! Especially for catching that logic inversion.
> 
> Wouter van Heyst

I guess there was a reason I didn't understand what you were doing. :)

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEqsyAJdeBCYSNAAMRApOnAJ9rbW6BWV4CDPooVE3P2MuYTe7xogCgkdLU
EZBaSNCRCfEBgFJWt33KAlY=
=jynj
-----END PGP SIGNATURE-----





More information about the bazaar mailing list