[Monotone-devel] Re: seeming monotone status/diff/update in-consistency; file timestamp question; other

[Graydon Hoare]

David Hoke wrote:

> monotone commit --message="version 2 of file 1"
> cd ..\workingcopy2
> ***Note this point****
> monotone status
> monotone diff
> type file1.txt
> monotone update
> type file1.txt
> -----------------------------------------------
> At the "***Note this point***" point, I would expect a difference 
> to be displayed, as workingcopy2 contains verion 1 of the file,
> while its corresponding monotone branch contains version 2 of the file.

Every working copy has a base revision, stored in MT/revision. The base 
revision is the revision you checked out, or last updated to. If B is 
your base revision, then when you commit your working copy W, you commit 
a new edge to the revision history which has B as ancestor. The new edge 
is B->W.

The command "monotone diff" shows the B->W edge, before you commit it, 
so you can decide if you want to commit it. It does not search the 
branch for other revisions which might have been committed since your 
last checkout or update.

In general it is not possible or meaningful to show "the difference 
between a revision and a branch". The branch may have multiple head 
revisions. Suppose you had committed three other working copies, all 
with different contents, to the branch. What would you expect "diff" to 
display?

> However, after requesting the update, version 2 of the file is retrieved.

Yes. Update searches the branch for descendents of the base revision. If 
it finds an update target T, it attempts to merge your B->W edge with 
B->T into a new working copy M, and applies the T->M edge to your 
working copy, and forgets about M and rewrites your base revision as T.

This has the effect of "moving" your uncommitted edge-in-progress from 
being "based on B" to being "based on T". For example, if you have this 
graph:

    B --------> T (update target)
     \
      +---> W (uncommitted changes to B)

Then running "monotone update" will change to this situation:

    B --------> T
                 \
                  +---> W

> 1) This sort of functionality could be useful for any wishing
> to use monotone in a more "centralized"

I agree that it would be nice to have a command which lists the other 
heads in a branch with details of the possible diffs which they will 
apply, when updated-to. "monotone diff" is not that command, however.

> 2) Without having tried it, I'm guessing there might be similar 
> issues if one wished to retrieve one branch somewhere, and then
> diff it against a different branch,

I must ask that you drop the concept of "diffing branches" from the 
discussion. Within monotone's data model, there is no such operation. 
One cannot calculate any useful difference between branches. Branches 
may have multiple heads, be discontinuous, share revisions, etc.

Diffing happens between specific revisions.

> TWO
> It appears that files do not carry any sort of date/timestamp 
>
> Is there a specific reason that monotone should _not_ do this?

It's extra information, and nobody's asked for it yet. It can be 
provided by attributes though. If you like we can cook up some attribute 
support for carrying timestamps around (by default we don't carry owner, 
group, mode, or symlinks either). Note that you will therefore be 
responsible for *merging* timestamps when they disagree. Perhaps not too 
onerous.

> THREE
> Can someone clarify usage of "revision ID/selector/ID"? 

Sure. A revision ID is a hash of the text of a revision: it identifies a 
point in the history graph and the contents of your tree at that moment.

A selector is a "convenience" string which is expanded early in command 
processing, and which may expand to zero or more revision IDs. In many 
(most?) commands you can use a selector where you would otherwise use a 
revision ID, and if the selector expands to a unique revision ID, the 
command will succeed. If the selector expands to multiple revision IDs 
(for example, if you use "yesterday" and you committed 10 revisions 
yesterday) then monotone will print a list of the expansions and exit, 
asking you to be more specific.

> Also, attempting to use d:yesterday or d:now (mentioned in help):
> monotone: warning: [string "<std hooks>"]:749: `date' format too long
> monotone: misuse: selector 'yesterday' is not a valid date
> monotone: warning: [string "<std hooks>"]:742: `date' format too long
> monotone: misuse: selector 'today' is not a valid date

Curious. This is probably a bug. It might be platform-specific. Do any 
date selectors work? (for example, if you use a specific date in the 
YYYY-MM-DDTHH:MM:SS format?)

> FOUR
> Efforts to build monotone have led me to the point where I seem 
> to be missing a "libintl.h" (I think)

libintl.h is part of the gettext development package. Gettext is used to 
convert message strings to the user's locale: I believe monotone can 
currently speak French, Brazilian Portugese, Japanese and English. I 
think the gettext development package is bundled with the gettext 
runtime, though I can't quite remember. The mingw.org site points to 
this download. You might want to try it:

http://prdownloads.sf.net/mingw/gettext-0.11.5-2003.02.01-1.exe?download

> (I have attempted building with both cygwin and mingw - I believe
> I got farthest with mingw so far.)

Yes, stick with mingw. Cygwin might work, but mingw will work much 
better. I'd like someday to get a msvc port working too, but it'll take 
some work.

> And could someone clarify what external dependencies actually exist 
> for building

There might be some more -- it's easy to forget one -- but I think you 
should be mostly in luck if you have:

g++ 4.x, gnu make, automake 1.7, autoconf 2.58, zlib 1.1.4, boost 
1.32.0, gettext and gettext-devel. I think you're lacking the latter.

> I thought docs indicated no other external dependencies for building.

Sorry, we use the phrase "no external dependencies" on the webpage to 
discuss runtime requirements. Monotone does have a certain number of 
build requirements.

Let us know if you have further questions.

-graydon