Re: [Monotone-devel] Assorted DB Admin Questions

[Timothy Brownawell]

On Sat, 2007-09-01 at 12:55 +0100, Anthony Edward Cooper wrote:
> Hello all :-),
> 
>     We use Monotone at work, were using CVS, and we are very impressed 
> with the system :-).
> 
>     A couple of questions if I may that I have been unable to get 
> answers to...
> 
>     Background:
>        Running monotone version 0.35 on Solaris 9.0 and RHAS4U2 (32 bit 
> binaries running on 32 and 64 bit systems). We have one `master' 
> repository (so everyone knows where to go to pick up the latest changes, 
> network bandwidth, storage capacity, backups (being paranoid)) with 
> developers storing their own databases on the workstation's local hard 
> disk. Every time they commit, they sync. We have specific coding 
> standards and procedures that must be adhered to. I administer Monotone 
> and I have decided to have an error free policy for the db. The size of 
> the db is 1GB with about 40K revisions.
> 
> 1) I did a routine db check on the database and got 3 minor problems 
> relating to two date certs on three revisions (when there was only one 
> author cert). I know this isn't an issue. However I want to have a clean 
> database.

Really I suppose we should just make db check not complain about
mismatched certs ever. It doesn't break things, and it's an expected
result of normal operations.

>  The only way I could remove the certs was to do a db dump, sed 
> (to remove them) and then db load. This then passed. I supposed I could 
> have used the SQL interface but I felt that there was probably a greater 
> chance of mucking things up.
>     A) Is there a better way of removing the certs? I know I could 
> double up the author certs to keep it happy but then this would not 
> reflect what happened (these revisions were created by the merging 
> process that our build manager kicked off).

Well, the SQL interface is the only other way to remove arbitrary certs
right now. It's not really something that's meant to be needed during
normal operation.

>     b) I have been assuming that db dump, db load is absolutely 
> completely lossless, is this a correct assumption? I'm just being paranoid!

Yes.

> 2) A number of mistakes have been made by developers whereby they have 
> used tag and branch names that are not consistent with our project 
> standards. I have been asked to rectify these user mistakes. So when I 
> have made these changes etc I need to stop people from syncing their 
> databases to the master without downloading the new corrected database 
> first (which they can do via scp and then they get it up to date with an 
> mtn sync). I had thought that the best way of doing this would be to 
> change the epochs of the affected branches. Those users not interested 
> in those branches (projects) just carry on as before, whilst the ones 
> affected have to download a new db.

>  However how do I generate the new 
> epoch hash?

Monotone does it by basically pulling hex characters from /dev/random.

>  Does it have to be unique or just different from the 
> previous one?

It should be unique for that branch.

>  Is there a better way of invalidating a user's database 
> WRT to the master such that a sync is guaranteed to fail until they 
> download the new one?

No, that's exeactly what epochs were designed for.


-- 
Timothy

Free (experimental) public monotone hosting: http://mtn-host.prjek.net