Re: [Monotone-devel] Show working copy STATUS against the branch HEAD version

[Daniel Carosone]

On Tue, Jan 17, 2006 at 11:31:11AM -0800, Drakie Awita wrote:
> Let's say I checked out a working copy of current branch's head
> revision (rev-W). While I'm modifying my working copy, some other
> developer checks into current branch their modification against rev-W,
> hence the head revision is now "rev-N".

Yup, this happens all the time.

> Now, before I check-in my modified copy and do the merge with rev-N,
> is there some monotone command for me to show the difference between
> my yet-to-be-checked-in modified copy and the latest branch head rev-N
> ?

Yes there is, but see below. You can use the head selector: 

  monotone diff -r h:

(or name explicit versions or use other selectors if there are
multiple heads):

  monotone diff -r h:/a:address@hidden

> I notice that "monotone status" only shows me the difference between
> my modified copy and rev-W, not the latest head rev-N.  I could have
> figured out the current head revision number "rev-N" through "monotone
> heads", and then do a "monotone diff -r rev-N" for each of the files
> in my modified copy (through "montone list known"?), but it's
> cumbersome and I haven't yet figured out a way to list all the new
> files added by rev-N without checking out rev-N (here I need something
> like "monotone list known/unknown -rev N" from my working copy
> associated with rev-W)

just do the diff over the whole tree, without the file restrictions,
and you'll get all in one - including adds/renames/deletes etc that
the other developer has done.

However, the diffs this will show you can be a little confusing, and
probably aren't quite what you want: they pretty much show your work
being undone together with the other developer's work being added.
That's good to see if you're going to be in conflict, perhaps, but at
least I find it a little confusing.  I want to see what the other
developer has done.

Typically, what you really want to see is the diffs along the line
between the other developer's new head, and your common ancestry point
(which might be your base revision, or might be some ancestor of it,
if you've committed several versions).  This shows you the changes
you'd bring into your tree from his work, with a merge.

You can certainly do this by naming explicit version id's, perhaps
with the assistance of a gui tool like monotone-viz to see and select
the divergence point easily.  Sadly there isn't yet a nice easy magic
selector that will pick the right version for you.

All that being said, part of getting used to working with monotone is
to get comfortable with just committing against your base revision
first, and then resolving merges later: it might be days before the
rev-N actually reaches you, in some scenarios, so it really doesn't
matter whether you look at these diffs before or after committing.

--
Dan.

pgpBP4qSWWIne.pgp
Description: PGP signature