On 03/03/2007, at 10:22 AM, Nathaniel Smith wrote:
Hmm, odd, I seem to be in the minority :-). I have a directory under
~/src/ for each project, so I have e.g. ~/src/monotone/, and then it
contains my db in the top level, monotone.mtn, and a bunch of checkout
directories on different branches, and build directories for those
checkouts. The nice thing about this approach is that it means all
the data for a single project is stuck together in one place; this is
sort of the model I have in the back of my head when I talk about how
I think the UI should look.
I could modify clone so that it stored the database in "<working-copy-
name>.db". Or "<working-copy-name>.mtn-db".
e.g.
mtn clone venge.net -b net.venge.monotone
would produce a directory "net.venge.monotone" and a database
"net.venge.monotone.mtn-db".
mtn clone -b net.venge.monotone venge.net monotone-src
would produce a directory "monotone-src" and a database "monotone-
src.mtn-db".
If the database already exists it could be re-used. If a database is
specified, it would be used - as it is now.
Thoughts:
- This would mean that the database could be kept around if the
checkout later fails.
- This would make the existence of the database more explicit.
- It generates a file that the user didn't explicitly ask for.
- This would massively simplify the code (because the db creating
and population wouldn't need to be inserted into the middle of
checkout code - you're really just doing three normal mtn ops in a row.)
- It shows that mtn has another common use case where you want to
run a series of commands in a row. (Maybe I need to implement the
suggestion on the UI wiki page where monotone logs the commands used
with a timestamp in ~/.monotone/ somewhere and gathers it in
occasionally. Then we could use that as empirical data for UI design.)
Be well,
Will :-}
_______________________________________________
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
