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

[Matthew Gregan]

At 2005-12-23T08:53:47-0500, David Hoke wrote:

> assuming something similar to the following series of commands (and
> whatever was necessary to prep for them)(output results omitted):

> cd workingcopy1
> monotone --branch=testbranch1 setup .
> echo version 1 of file 1 >file1.txt
> monotone add file1.txt
> monotone commit --message="commiting initial version of file"
> cd ..\workingcopy2
> monotone checkout .
> type file1.txt
> cd ..\workingcopy1
> echo verion2 of file 1 >file1.txt
> monotone status
> monotone diff
> 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.  But, no
> difference is shown.

'status' is the command that tells you what would happen if you ran 'commit'
right now.  It shows you the changes made in your local workspace compared
to the base revision of the workspace (i.e. the committed revision you
checked out).

If you want a command that will tell you what would would happen if you ran
'update', the closest thing is either 'log', or a script that runs 'automate
children' on your workspace's base revision and parses the output nicely.

Other than 'log', the workflow of monotone doesn't tend to require a
specific status-like command to show you what would happen on update.
That's not to say that it wouldn't be useful to some users, but the
recommended workflow is:

- checkout/update
- make your changes
- commit
- maybe merge heads if there is now divergence
- maybe pull/merge/push if you feel like it
- update

Most importantly, note that the user commits their changes against the base
revision they started working against--they don't attempt to update their
workspace to the latest revision while there are local changes.  This helps
make development a little safer--changes are already committed to the
repository before you attempt to update your working copy.

> It appears that files do not carry any sort of date/timestamp into
> monotone storage with them.  I would very much like to have that
> information retained (at least the probable last modification stamp) and
> restored when files are retrieved from monotone storage.  (Probably stored
> in GMT zone range, and adjusted as needed for system/timezone setting of
> extract destination.)

That's correct.  At present, monotone only stores the file name, file data,
and any user-specified manually set file attributes.  There's a feature
request logged in our Savannah bug tracker requesting the ability for
monotone to track ctime and mtime:
https://savannah.nongnu.org/bugs/?func=detailitem&item_id=11145

> Efforts to build monotone have led me to the point where I seem to be
> missing a "libintl.h" (I think) - can someone tell me what I need to
> obtain to have this.  (I have attempted building with both cygwin and
> mingw - I believe I got farthest with mingw so far.)  And could someone
> clarify what external dependencies actually exist for building - I recall
> notes mentioning "boost" (which I've retrieved and at least partially
> built), but I thought docs indicated no other external dependencies for
> building.

Cygwin will "just work", assuming you've installed recent versions (note
that all but the last one or two builds of boost::filesystem were broken in
Cygwin) of all of the appropriate packages (autoconf, automake, boost,
gettext, iconv, zlib, maybe some others I'm forgetting right now).

For MinGW, see here: http://venge.net/monotone/wiki/BuildingOnWindows

Cheers,
-mjg
-- 
Matthew Gregan                     |/
                                  /|                address@hidden