Fancy branches versus Transports

[Lalo Martins]

And so says John A Meinel on 16/09/05 22:35...
> I wanted to merge my Transport code to the latest bzr.dev, so I pulled
> it in, and I'm looking over Lalo's branch constructor code.
...
> I can still do that with Lalo's code, it just looks funny, because I am
> instantiating a "LocalBranch" for remote operations.

there are two separate things here; the new constructors, and the
LocalBranch class.

FWIW, one of the motivations for the new constructors was to make it
easier for you to do exactly what you want to do.

The LocalBranch class was created as the first step of an attempt to
drill down which Branch methods deal with the filesystem (those would
remain in LocalBranch) and which are just branch logic (those would
float up back to Branch).  In the end, it would be possible for
RemoteBranch to subclass Branch.

Then you came back from vacation and made this effort irrelevant ;-)

So if you're already getting rid of RemoteBranch, feel free to get rid
of LocalBranch too (folding it back into Branch).  The drilling down
part was already done in your previous branch.

Another reason the LocalBranch wasn't removed before my branch was
merged, is that we wanted to make the Branch constructor abstract, so
that we could quickly catch all code that uses it and move it to the new
constructors.

So, if you have one single class, I suppose you have to have an usable
constructor (unless you want to define __new__ and make it raise
something).  I'm not sure what should be the result of Branch(foo) -
maybe equivalent to Branch.open(foo)?  But that doesn't smell very good.

Anyway, the current implementation of the constructors (by
implementation I mean the code inside the methods themselves) is clearly
temporary; it was intended to introduce the new API asap, giving us an
opportunity to migrate calling code.  (Right now it just wraps the old
constructor.)  A more complete implementation would have been a waste of
time, since I was expecting either you or me to further change branch
construction in the direction of transports and storages.

In short - keep the API (namely, you build a branch by calling one of
the three constructors, and no other way), and blow away the internals
as much as you want.  If there is anything I can do to help, just ask.

best,
                                               Lalo Martins
--
      So many of our dreams at first seem impossible,
       then they seem improbable, and then, when we
       summon the will, they soon become inevitable.
--
http://www.exoweb.net/                  mailto:lalo at exoweb.net
GNU: never give up freedom                 http://www.gnu.org/