Updated Issue 201 - "pull" and "db check" have different opinion on whether branch certs are needed (monotone)

Hello,

The following issue has been updated:

201 - "pull" and "db check" have different opinion on whether branch certs are needed
Project: monotone
Status: Fixed
Reported by: Michael Raskin
URL: https://code.monotone.ca/p/monotone/issues/201/
Labels:
 Type:Defect
 Priority:Medium

Comments (last first):

# 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

# 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.

# 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.

# 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.

# By Richard Hopkins, Jun 24, 2012:

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

Agree.

# By Stephen Leake, Jun 23, 2012:

confirmed in nvm head; added test pull_branch_vs_db_check

# 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.



--
Issue: https://code.monotone.ca/p/monotone/issues/201/