Issue 201: "pull" and "db check" have different opinion on whether branch certs are needed

Reported by Michael Raskin, Dec 6, 2011

Steps to reproduce the problem:
-------------------------------

1. mtn pull mtn://code.monotone.ca/\?net.venge.monotone
2. mtn db check

Expected result:
----------------

Success

Actual results:
---------------

"serious problem" reported, mtn db check return code 
non-zero

Problem is:
-----------

mtn pull doesn't pull branch certs unless they match the pattern 
that I pull. mtn db check considers missing branch certs a serious 
consistency problem. 

It would be nice if monotone would pull all certs for pulled 
revisions. It would be nice if I could force mtn db check to ignore 
some classes of consistency half-problems. Two valid changelogs is 
not a problem worth my attention in most cases. 

It is a bug that succesful mtn pull can create whatever monotone can 
call a serious problem. The simplest solution is probably to demote 
missing branch certificates to an mtn db check warning.

Comment 1 by Stephen Leake, Jun 23, 2012

confirmed in nvm head; added test pull_branch_vs_db_check

Comment 2 by Richard Hopkins, Jun 24, 2012

"It would be nice if monotone would pull all certs for pulled 
revisions."

Agree.

Comment 3 by Markus Wanner, Jun 25, 2012

It's news to me that a missing branch cert is considered a serious 
problem. What's wrong with having revisions without any certs at 
all? I don't personally count that as an inconsistency (and 
certainly not multiple changelog, date, author, suspend or comment 
certs, no matter what their content is).

I'd vote for relaxing db check to something sane, instead of 
fiddling with netsync.

Comment 4 by Richard Hopkins, Jun 25, 2012

I don't consider those problems either in the "source" 
database. What I do prefer though is that I don't have to worry some 
info is only in some databases, which is why I'd like netsync to 
transfer all certs for negotiated revisions. 

I like everything being everywhere for safety as well as a less of a 
mental burden of remembering; I don't like the notion of sharding 
promoted more by other DVCSs, and thoroughly agree with Nathaniel's 
slides.

Comment 5 by Markus Wanner, Jun 25, 2012

> What I do prefer though is that I don't have to worry
> some info is only in some databases, which is why I'd
> like netsync to transfer all certs for negotiated
> revisions. 

Arguably, monotone database are not intended to carry the exact same 
data. Otherwise we'd have no branch argument to netsync. I'm not 
sure I agree that all known data for a revision should be 
transferred, if the revision is. After all, the user specifically 
asks for a certain branch to be synched - and thereby specifies that 
he's not interested in whatever other data there is that belongs to 
other branches.

Also consider that we do read permissions per branch. Why should one 
party have to send out a branch cert the other party doesn't have 
read access to?

However, I'm not strongly opposed to synching all known certs for a 
revision. I just think the users should be aware of the implications 
of such a change. For example, to keep a private branch private, 
you'd then have to make sure you don't ever sign a publicly 
reachable revision with your branch name. That's quite a bit harder 
than simply setting proper read permissions.

It's certainly an entirely different issue from "db check" 
failing to accept revisions without branch certificates.

Comment 6 by Stephen Leake, Jun 25, 2012

consensus on relaxing db check, so that's done in 
a4549e0dd9f2288465eb61bb885ceaaf07359776

closing this bug; someone can open a new one if they want to persue 
pulling all certs for a revision.

Status: Fixed