[Monotone-devel] confusion with heads

[Evan Martin]

Hi all,

I just started playing with monotone and I've been bugging Graydon
about it, but he suggested I can also bug this list with user issues.

I have a situation that's confusing me, and I suspect it's caused by
confusion about how monotone works in general, so I'll just restate my
assumptions and hopefully you can identify where I've gone wrong.

I have a database "neugierig.db" served at neugierig.org.  I pull this
database into a new one, checkout my project, and "monotone heads"
produces different output than if I just check out the same branch
from the original database directly.  See below, where I check out
using the different access mechanisms out into directories "cw1" and
"cw2".

address@hidden:~/projects$ monotone -d test.db db init
address@hidden:~/projects$ monotone -d test.db pull neugierig.org
org.neugierig.crossword
monotone: setting default server to neugierig.org
monotone: setting default branch include pattern to 'org.neugierig.crossword'
monotone: setting default branch exclude pattern to ''
monotone: doing anonymous pull; use -kKEYNAME if you need authentication
monotone: connecting to neugierig.org
monotone: first time connecting to server neugierig.org
monotone: I'll assume it's really them, but you might want to double-check
monotone: their key's fingerprint: 237991c5e8132f8864c99fdf3cf4a9ed79ad8c77
monotone: warning: saving public key for address@hidden to database
monotone: finding items to synchronize:
monotone: bytes in | bytes out | certs in | revs in | revs written
monotone:   91.6 k |      5429 |       36 |       9 |            1
monotone: verifying new revisions (this may take a while)
monotone: bytes in | bytes out | certs in | revs in | revs written
monotone:   91.6 k |      5452 |       36 |       9 |            9
monotone: successful exchange with neugierig.org
address@hidden:~/projects$ monotone -d test.db co cw1 -b org.neugierig.crossword
address@hidden:~/projects$ monotone -d neugierig.db co cw2 -b
org.neugierig.crossword
address@hidden:~/projects$ cd cw1
address@hidden:~/projects/cw1$ monotone heads
monotone: branch 'org.neugierig.crossword' is currently merged:
d3e08e2a5ea5a5c735387d9d9003e9b87fbccb78 address@hidden 2005-12-19T00:58:13
address@hidden:~/projects/cw1$ cd ../cw2
address@hidden:~/projects/cw2$ monotone heads
monotone: branch 'org.neugierig.crossword' is currently merged:
0a881d41aca72c9cd407999e682a11724495c56e address@hidden
2005-12-19T00:57:37

These revisions make sense, in that I committed these different
revisions at different places and synced.  So I expected a fork here,
but I don't see why I don't get the "unmerged heads" output... why do
they have different heads?

Here's enough of the history of each to see where they diverged:

address@hidden:~/projects/cw1$ monotone log --brief | head -3
d3e08e2a5ea5a5c735387d9d9003e9b87fbccb78 address@hidden
2005-12-19T00:58:13 org.neugierig.crossword
99d42636acad6dd4ea0a526bafccef40a3db4cd5 address@hidden
2005-12-18T23:41:11 org.neugierig.crossword
f37c1d4b1c1e036a8cacc52c890eac6ac86e3e70 address@hidden
2005-12-16T23:42:06 org.neugierig.crossword

address@hidden:~/projects/cw2$ monotone log --brief | head -3
0a881d41aca72c9cd407999e682a11724495c56e address@hidden
2005-12-19T00:57:37 org.neugierig.crossword
f37c1d4b1c1e036a8cacc52c890eac6ac86e3e70 address@hidden
2005-12-16T23:42:06 org.neugierig.crossword
94ce904aae6ef939af168180fb571bc5adc41bd2 address@hidden
2005-12-16T23:41:46 org.neugierig.crossword

They share history at the revision (is that the right term?) starting with f37c.

In general, I find most of my confusion with monotone comes from not
being able to see "what's available" in a given database.  That is, I
monotone sync against some random machine, and "ls branches" lets me
see branches there are but there doesn't seem to be a comparable
command to let me see which revisions there are (aside from using "co"
then using "log").  For example, before I was able to isolate this to
two checkouts from the same database, I had thought the problem was
with my sync permissions (I had thought maybe some versions weren't
getting synced from my local database to a remote one for some
reason).  If I'd had a way to look at the contents of each, it
would've been easier to see that wasn't the problem.