merge vs pull (was What we did at UBZ)

[Jan Hudec]

On Tue, Nov 29, 2005 at 15:11:29 +1100, Martin Pool wrote:
> On 28 Nov 2005, James Blackwell <jblack at merconline.com> wrote:
> 
> > 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. 
> 
> Except they're not orthogonal at all; there's a continuum from side
> streets to highways, and the basic operations (signal/turn/slow/
> accelerate) are the same, differing only in degree.
> 
> So this is like saying that the operations for a one-person project and
> a 200-person project should be same, differing only in their speed,
> frequence, etc.  There I agree.
> 
> Car analogies can be amusing but in my experience they're rarely
> accurate.  If I had to make one it'd be like this: often when you stop
> the car you want to turn off the engine, set the handbrake, open the
> door, etc.  So you could argue the engine should automatically cut out
> when you come to rest.  But obviously people don't always want that.
> 
> > 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.
> 
> In the example you describe above, sometimes you need to review &
> commit, and sometimes you don't.  There really are two different
> behaviours; we're just debating whether the user should have to choose
> which one they want, or whether there should be a heuristic which might
> sometimes surprise them.
> 
> So there are really two questions:
> 
>  - Should there be two behaviours; if not how can they be unified?

The behaviours are different. That's a fact. The question is whether
they should be covered by two commands. I believe they should.

>  - If there are two behaviours, how do we select one: different
>    commands, options, heuristic, etc.

I believe that:
1) pull should never merge commited stuff. It is ok to merge uncommited
   stuff. It also should become branch if called with empty or
   non-existent target.
2) Merge should merge commited stuff when there is any. It should refuse
   to operate when there are uncommited changes (because it can possibly
   create uncommited changes) and it should do pull if there is nothing
   to merge, including pull's fallback to branch.

There remains fundamental difference in usage -- you must commit before
merge, but must not commit before pull. And pull guarantees, that the
target is equal to source (modulo revision-history, which is likely
going away anyway), while merge does not guarantee it (though it does
it, if there is nothing to merge).

-- 
						 Jan 'Bulb' Hudec <bulb at ucw.cz>
-------------- 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/20051129/0831b9d8/attachment.pgp