merge vs pull

[Martin Pool]

On 28 Nov 2005, Kevin Smith <yarcs at qualitycode.com> wrote:
> James Blackwell wrote:
> >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. 
> 
> As a very interested RCS spectator, I have to agree with this idea. I 
> would like the command set to match workflow tasks, not internal 
> activities.

OK.  So we should try to articulate what work task is accomplished by
the two commands, or if that can't be done change to commands which can
be clearly articulated.  Perhaps we will decide the functions are ok but
the names are bad, or that they are really the same thing.

*merge*
  Take the work in another branch, and integrate it into the destination
  branch.  Let me review, test, or edit the results before committing it
  into my branch.  After committing, I have a new revision which
  descends from the tip of both branches.

*pull*
  Update a replica of another branch.  This can only succeed if the 
  source is a descendent of the tip of the target.  After pulling, the 
  destination has the same history as the source.  Pull doesn't make a
  new revision.

When should I use pull?

  When you're keeping a local replica, mirror or backup of a branch stored
  somewhere else. 

When should I use merge?

  When you want to review and integrate changes, making a new revision 
  to show you did the merge.

I can see it would be nice to have one less command and yet I think both
use cases are valuable.

> I would need to see a concrete proposal for combining the commands 
> before I could express a preference. I know there are lots of nooks and 
> crannies. Other systems (CVS, darcs, mercurial) seem to make this 
> particular decision with the entire tool paradigm in mind.

The other approaches seem to be:

 * two commands (e.g. CVS update vs merge)

 * no "pull" functionality (arch, kinda has it in archive-mirror but 
   it's more restricted)

 * merge automatically makes a new revision if needed (bk?, mt?)

   More restrictive because you don't have the chance to review the 
   results; and you don't have the option of making a merge revision.

 * merge happens without forming a new revision (darcs)

   There's no record of exactly what was merged.

-- 
Martin
-------------- 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/038b03f0/attachment.pgp