Re: [Monotone-devel] new to monotone

[Matthew Gregan]

At 2005-08-22T16:41:45-0700, Howard Spindel wrote:
> 1.  I installed monotone 0.20 originally.  I saw no problems with it.
> Yesterday I tried upgrading to monotone 0.22.  After the upgrade, the
> diff function no longer works - I get the Windows popup box that says
> the program attempted an illegal operation and must be terminated.
> Yes, I did the db migrate, and other functions besides diff worked
> fine.  I downgraded to 0.20 and diff works again.  System is WinXP.  I
> installed from the available Win installer - I didn't build monotone
> myself.  Known problem?  Workarounds?

It's not a known problem.  I'm not sure what's going on here--when the
release binaries are built, the full testsuite is run before the
binaries are packaged.  At least 22 of the tests that are run use
'monotone diff', so I'd have expected to see test failures if diff has
recently become buggy on Win32.  I'll look into this further when I have
a chance.

Since you can reproduce the problem, it'd be useful if you could add
'--debug' to the argument list when running a 'monotone diff' command
that results in a crash, then make the debug output available.

> 2.  I'd like to set up some offsite backup.  If I were to ftp my
> monotone database files to my ISP, is my data safe?  That is, is the
> database encrypted?  Would it work better if I somehow was able to use
> monotone's replication features to keep a remote database in sync?  If
> that means my ISP would have to open a hole in its firewall, I doubt
> if they would do that.  Suggestions?

The database is not encrypted.  If you're copying your personal monotone
database around, you're also copying your private key(s) around (unless
you're running a dropkey/dump cycle on a copy of the database
beforehand).  Using monotone's built-in networking is probably going to
be the most bandwidth efficient backup method, and you won't need to
worry about private keys being copied to a remote location.

You'd need to convince your ISP to open a hole in the firewall and let
you leave a monotone server running.  If you've got (or can get) ssh
access, you can avoid both of those requirements and use a bit of port
forwarding and scripting instead.

If you can't use monotone's networking to synchronize the database to a
remote location, you could copy a compressed database dump to your
backup location.  The way to do this is probably something like:

% cp mydb.db mydb-backup.db
% monotone -d mydb-backup.db dropkey address@hidden
% monotone -d mydb-backup.db db dump | gzip -9 --rsyncable > mydb-backup.dump.gz
% rm mydb-backup.db

% rsync mydb-backup.dump.gz my-isp:
...or ftp/scp/whatever.
% rm mydb-backup.dump.gz

> 3.  Do you guys have any shortcut ways to compare a working copy to
> the most recent previous version in the database?  monotone diff
> doesn't do it, because the working copy is checked in.  I want to
> compare against the version previous to the most recent check-in.  I
> can do it by finding the right hash key, but that's a bit clumsy.  Is
> there a way to tag a certain revision with a human friendly label, so
> for example, I could diff all changes since the last customer release
> without finding the right hash key?  I did read the manual and
> tutorial looking for these features, but if they are there I missed
> them.

I'm not sure what you mean.  A simple 'monotone diff' will show you a
unified diff of the changes in your working copy against the base
revision that the working copy was created from.  You can specify one or
two '--revision' arguments to specify specific revisions as the 'old'
and 'new' targets for the diff.

As for tagging revisions with a human-friendly label, it sounds like
'monotone tag' is what you're after.  These tags are stored in the
database and will be copied to remote databases by a netsync.  You can
specify a tag instead of a revision by using the selector syntax, i.e.
'monotone diff --revision t:release-0.9' to diff the current working
copy against whichever revision was tagged 'release-0.9'.

Cheers,
-mjg
-- 
Matthew Gregan                     |/
                                  /|                address@hidden