Re: [Monotone-devel] newbie questions (best practices)

[Timothy Brownawell]

On Fri, 2005-05-27 at 15:54 -0400, Nathan Cournia wrote:
> Hi,
> 
> I've just started to use monotone and have some questions.
> 
> 1.  Should I maintain each project I'm working on in a seperate .db file

I believe this is considered the "right" way to do things, yes.

> 2.  If I do keep each project in a seperate .db, how do I share my
> work with my co-workers?  Do I run `monotone serve myhost:port
> com.work.myproject` for each .db where, "port" is a unique number? 

Yes.

>  Is there a way to have multiple .db's running on the same port?

No. Or you could put them into the same database on the server. You
could also put them in the same database generally, but then all your
projects are lumped together from the point of view of your filesystem
(I think this is why seperate dbs are considered "right".).

> I just sync'd my database with a friend.  I then updated my working
> copy.  When running `monotone update`, monotone popped up `meld` to do
> a 3 way merge.  I accidently, closed `meld` before doing the merge. 
> As a result, it looks as if I've lost the changes I had made to my
> working copy.
> 
> 3. Is there a way to get back the changes I made to my working copy?

I don't think so.

> 4. If I had committed my working copy before sync'ing, what would have
> happened?  Would I have been presented with the 3 way merge during the
> sync command?

You would not have lost your work, but there would be multiple heads.
The server you synced with would also have multiple heads. You would
then run "monotone merge" and be presented with the 3-way merge tool.

> 5. If I had committed my working copy before updating, but after
> syncing, what would have happened?  Would have been presented with the
> 3 way merge during the commit command?

Same as above, except the server wouldn't know about your work.

> 6. Is there a general rule to follow when committing/updating/syncing,
> i.e. always commit before doing a sync or update?

I do commit, pull, merge (if it complains about multiple heads), sync,
update (if I did merge).

This way, everything is in the db so merge errors can be corrected,
nobody has multiple heads at the end, and my working copy is up-to-date.

Tim