Re: vc-update for bzr etc.

["Stephen J. Turnbull" <stephen@xemacs.org>]

Thien-Thi Nguyen writes:
 > () "Stephen J. Turnbull" <stephen@xemacs.org>
 > () Mon, 22 Nov 2010 13:31:23 +0900
 > 
 >    bzr pull -- synchronize branch to parent exactly, never does a
 >                non-trivial merge, sometimes operates on a non-local
 >                branch and not on the workspace IIRC.
 >    git pull -- merges branch into workspace, commits unless conflict,
 >                never affects a branch outside of the workspace.
 >    hg pull  -- fetches branch, never updates workspace or affects a
 >                branch outside of the workspace.
 > 
 >    I don't see the point of having a single command whose implementation
 >    can vary so randomly.  That's not a uniform UI, that's a
 >    nondeterministic one.
 > 
 >    I agree that perfectly uniform semantics is not really possible, of
 >    course.
 > 
 > Looks like the sub-operations are:
 > 
 >  (0) determine "news"
 >  (1) download "news" (to some temporary space)
 >  (2) merge (conditionally, looping for conflict resolution, etc)
 >  (3) commit
 > 
 > Can these DVCSes do such sub-operations *individually* somehow?
 > Step (3) is given, but the others?

I believe so, although the solutions in the case of bzr might be
exceptionally gross and possibly inefficient (eg, to do (1) I think
you would have to either create a new branch, or get the revid of the
tip and then uncommit, which doesn't destroy any commits, it just
rewinds the tip in the same way that git reset does).  git's solution
to (0) is a bit ugly too ("fetch --dry-run"), while bzr provides
"missing" and hg "incoming".