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.