merge vs pull (was What we did at UBZ)

[James Blackwell]

Martin,

Sorry, lost a couple lines in that post. I've added them here.

On Wed, Nov 23, 2005 at 12:11:36PM +1100, Martin Pool wrote:
> On 22 Nov 2005, James Blackwell <jblack at merconline.com> wrote:
> > This is a good point that has been mentioned by Aaron before. My thoughts
> > are something like: 
> > 
> > ~$ bzr branch http://offin.thevoid/coolcode cool
> > ~$ cd cool
> > cool/ $ bzr pull 
> > bzr: Nothing new
> > 
> > cool/ $ sleep 86400
> > cool/ $ bzr pull
> > bzr: Changes applied and saved.
> > 
> > cool/ $ echo "hi" > hi; bzr add hi; bzr commit -m "added hi"
> > cool/ $ bzr pull
> > bzr: Nothing new
> 
> At the moment, this one will tell you the branches have diverged (and
> they have.)
> 
> > cool/ $ sleep 86400
> > 
> > cool/ $ bzr pull
> > bzr: Changes applied. Review changes and commit
(users hacks changes and commit)
> 
> You don't show the person committing here.  Are they leaving the merged
> changes uncommitted?
> 
> > cool/ $ bzr pull
    bzr: Nothing new
> 
> What did this do?
> 
> > cool/ $ sleep 86400
> > cool/ $ echo "bye" > bye; bzr add bye; bzr commit -m "added bye"
> 
> So this new file is mixed in with the previous merge?  Why?
> 
> > cool/ $ bzr pull --pretend-converged
> > bzr: Changes applied and saved
> 
> Sure but what is that option supposed to *do*?
> 
> > Right now, bzr help is 13 commands. That's pretty good, and a very, very
> > powerful selling point. I think that its reasonably possible to get that
> > down to ten commands without breaking new minds, by combining three
> > commands -- pull, branch and merge, into one command.
> 
> Well, combining three into one would only get it to 11 commands. :-)

pull, branch and merge into one does get us down to an even dozen,
actually, as "pull" isn't listed on the initial commands (which in its
current incarnation should be anways.)

Its still better to say "An even dozen core commands" than "thirteen
commands"

> More importantly, having few commands is not a win if the behaviour of
> those commands is unpredictable.  It's not an end in itself.  It seems
> that a combined pull/merge would be somewhat unpredictable both in
> whether you later need to commit, and in whether it forms a rolled-up
> commit or not.

I think we're looking at opposite ends of the same telescope.

I think you're saying that users will loose the ability to differentiate
between what was a merge and a pull.  I'm saying I think potential users,
new to RCS, don't have an an intuitive, a priori understanding that these
are two different things. 

A vehicle has at least two useful orthoganal states: Driving on
highways and driving on side streets. Each state provides different 
benefits and has different requirements (Imagine taking a hard left on the
highway or letting a passenger out in front of their house at 75MPH, 
diving 600 miles via side streets). 

One of the reasons cars are wildly successful is that it has successfully
abstracted two forms of travel (local and distant) into one ("drive").
There is no "highway/town" toggle necessary to lock down the allowed
steering, door locks, gear ratios, gas tank size, etc. I just get in and
go.

Why again do we need this update/merge button on the tool? If bzr can
figure it out for me, then why do I need to know about it at all?  Since
ease of use is one of bzr's claims to fame, then it makes sense to yank
this button out and have the tool make the determination. This leaves bzr
open for newer people that don't have a posteri knowledge. :)



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051128/369c4d5d/attachment.pgp