Re: [Monotone-devel] Ideas and questions.

[Richard Levitte - VMS Whacker]

In message <address@hidden> on Mon, 14 Feb 2005 04:55:56 -0800 (PST), Logan 
Sackette <address@hidden> said:

lsackette> If the name can be changed, that would be nice.  But I
lsackette> would rather see more effort place on storing multiple
lsackette> projects in one database.  I like how SVN has one
lsackette> database (though you can have multiple databases) for
lsackette> multiple projects.

Uhmm, if you consider that a project is just another branch (and it's
subbranches), why is that a problem?  I currently have several
projects (monotone itself as well as monotone-viz) in the database
db.monotone, as is seen with this list of branches:

: ; monotone --db=/home/levitte/monotone-repo/db.monotone list branches
matt.mto.test.botanhead
monotone
net.venge.monotone
net.venge.monotone.botan
net.venge.monotone.changesets
net.venge.monotone.cvssync
net.venge.monotone.delete_dir
net.venge.monotone.experiment.sqlite-shell
net.venge.monotone.gui
net.venge.monotone.i18n
net.venge.monotone.levitte.cvs_import
net.venge.monotone.noclobber
net.venge.monotone.rebuild_tracking
net.venge.monotone.restrictions
net.venge.monotone.sqlite3
net.venge.monotone.ssh
net.venge.monotone.win32
ocaml.monotone-viz
ocaml.monotone-viz.alter


For a while, I did run a private monotone-related branch in
db.monotone, but because of the many database rebuilds, I decided to
have my private stuff separately, so the next rebuild would just be a
matter of throwing away db.monotone (after doing diff on all my work
directories to be safe) and reloading everything from the sources.
That may seem paranoid, but I do recall having some trouble netsyncing
once after a rebuild, which I couldn't reproduce, so I left it.
Maybe I should try again next time there's a need for a rebuild...

Most usually, at least for projects I initiate, I've adopted the one
database per project standard, mostly because each project may have a
different server and in case of a bad crash, I want them cleanly
separated so the mess can be minimised.

lsackette> If we can find a one database solution, ~/monotonerc
lsackette> (.mtnrc) can point to the "default" database.  The
lsackette> --db option can still be used to override the default.

That sounds like a good idea to me.

lsackette> We can also use a ~/.monotone (.mtn) directory to
lsackette> store info about the databases being used.  That way,
lsackette> we don't have to worry about where the user is
lsackette> relative to checked-out directory.  SVN and other VCs
lsackette> have solved such problems, so we certainly can.

I'm sorry, exactly what problem does that solve?  There will still
need to be some hint to what the top of the project you're working on
is, so with a ~/.monotone directory, there would be a need to store
exact paths, and things could be really messy if I move my work
directory and forget to hack whatever file in ~/.monotone.

Or maybe I just don't understand what you're after...

lsackette> A better solution, would be to store information about
lsackette> the database being used in each subdirectory upon
lsackette> checkout or when a directory/directory-tree is added. 
lsackette> That way, a person is free to blow away a directory
lsackette> they were playing in without having to worry about
lsackette> cleaning up the ~/.monotone (.mtn) directory.

That's better, but why isn't the MT directory enough?  Is it because
of the upward search?  Of course, having MT directories would solve
that little problem, but I don't think that needs a very high
priority, there are tougher things to hit.

Cheers,
Richard

-- 
Richard Levitte                         address@hidden
                                        http://richard.levitte.org/

"When I became a man I put away childish things, including
 the fear of childishness and the desire to be very grown up."
                                                -- C.S. Lewis