Improving init workflow [was: Re: [RFC] branch --bind]

[Tim Michelsen]

I like this optimasation initative.

I work with a central server / repository workflow.
In order to create a new project I currently run:

1) bzr init sftp://my.remote.server.net/newproject
2) bzr co sftp://my.remote.server.net/newproject

It would be nice if both could be combined.

Also, when using the Eclipse IDE, it comes more complicated:

1) create a new Pydev project "newproject" in Eclipse
    (This creates the .project and other Eclipse files)
2) close Eclipse
3) cp newproject newproject_ecl
4) bzr init sftp://my.remote.server.net/
5) bzr co sftp://my.remote.server.net/newproject
6) cp -r newproject_ecl/* newproject
   (copy the Eclipse configurations in the checked out working branch)
7) rm-rf newproject_ecl

I would appreciate any hints on how to accelerate this procedure.

Thanks and regards,
Timmie


Ian Clatworthy schrieb:
> I've put together a patch extending the branch command with a --bind
> option. See
> https://code.edge.launchpad.net/~ian-clatworthy/bzr/branch-bind-option/+merge/16725.
> The intent is that
> 
>   branch --bind X Y
> 
> is equivalent to
> 
>   branch X Y
>   cd Y
>   bind X
>   cd -
> 
> Poolie has approved this patch. lifeless and fullermd have asked for
> more discussion before this lands. Some background ...
> 
> FWIW, my short term driver for this is a better qbranch dialog. Due to
> locking considerations, I can't easily add a "Bind to parent" checkbox
> to qbranch without pushing the functionality down into the bzr core.
> 
> Longer term, I think our "checkout" model is broken - heavyweight and
> lightweight checkouts have different semantics - and needs fixing. I'd
> like to see lightweight checkouts the default with the option of a true
> (history horizon) cache. That's a separate debate though. If anything,
> having "branch --bind" is good because we can introduce new users to
> bound branches without needing to explain all the complexity/issues
> around various checkout types.
> 
> Discuss way. :-)
> 
> Ian C.
> 
>