[rfc] auto-push / soft-checkouts

[Neil Martinsen-Burrell]

On 2009-10-13 11:56 , Marius Kruger wrote:
> (should I forward this to the list?)

Yes.  I'll send this reply there as well.  Apparently Reply-To is of 
more than theoretical interest.

> 2009/10/13 Neil Martinsen-Burrell<nmb at wartburg.edu>:
>> On 2009-10-13 05:52 , Marius Kruger wrote:
>>>
>>> This is part of the discussion I want to get going: normally with
>>> checkouts it is assumed that you always have a fastish connection to
>>> the maser branch. But I'm arguing that there's a use case where I
>>> want something between checkouts and totally separate branches. I
>>> think we need to think a bit about where we want our commandline
>>> interface to be heading, in stead of willy nilly tweaking things.
>>
>> Can you clarify how your proposal for "automatic push" differs from bound
>> branches?  I think of a bound branch as one that automatically pushes a
>> commit to another (usually remote) branch.
>
> Well it will do stuff like merge in remote revisions you don't have
> yet, and refuse to let
> you commit if your branch is out of date (unless you specify --local,
> which can cause problems later)
>
>> If you are without a fast-ish
>> connection, then you can do ``bzr unbind`` and no commands will contact the
>> remote branch.  Then, when your connection is available, you can do ``bzr
>> bind`` to get back to the checkout model.
>
> uhm, I dont want to bind/unbind the whole time - that is my point, it
> should just work.
> (note I work on lots of projects/components and I definitely don't
> want to remember to bind/unbind each and every branch)

So, the crux is that you would like a soft-failure on any remote 
operations?  My concern is that this introduces a further complication 
to an already complicated list of relationships among branches: 
checkouts (lightweight), bound branches, parent, push, submit.  The 
clarity of bound (always up to date with parent) vs. unbound (parent 
managed separately) and the explicitness of the commands to switch 
between those states (bind/unbind) are important benefits for explaining 
these concepts to new users.

>> Is your desire to have bound branches that "Never fail commands because of a
>> lack of connectivity"?  If so, then I think that this is how bound branches
>> *should* work and cases where they don't work that way could be filed as
>> bugs.
>
> Maybe that will do for, but I doubt if you will satisfy everybody that way.
> In some cases like when you really want to work in a centralised workflow,
> you actually want it to fail if your changes are not applied
> successfully on the mainline.
>
> But in my workflow I prefer if it will push it if it can, or just warn
> me about it otherwise, but don't make my commit fail.

I think that this branch relationship is reasonable as a plugin, where 
it fits nicely under "unbound branch, parent managed separately" and 
that separate management is via the auto-push plugin.  As far as being 
in the core, I think that because it complicates the user interaction 
model it should not be added until it has matured and gained acceptance 
as a plugin first.  Note that I am not a core developer, so the above 
arguments are all straw men.

-Neil