Re: [Monotone-devel] YANQ (yet another newbie question)

[Markus Schiltknecht]

Hi Ken,

Ken MacDonald wrote:
> The tutorial shows the user creating a workspace for a branch (and a
> subdirectory to contain it) in Section 2.5, with the "mtn setup"
> command; I didn't see anything to suggest that branches/workspaces
> needed to be created in top-level directories - someone clarify if
> this is wrong!

That's correct, you can create a monotone workspace in whatever 
directory on the filesystem you want. What I wanted to say is: in almost 
every case, you don't want to have a workspace within another workspace. 
Nor start a 'branch' as a subdirectory of your workspace (the subversion 
way of doing it).

What filesystem based VCS are you coming from? It might only confuse you 
to compare with svn...

> Briefly, when we roll out our use of mtn, I expect the following
> conditions: we have several developers, but eventually will all be
> using the same server to store our mtn 'stuff'.

However you like. In most cases, it's convenient to have a central 
server to sync to. But you could all just sync your laptops from time to 
time. Monotone gives you all the freedom to work however you want (and 
sync and merge whenever you want).

> We have a lot of
> projects, and so I think we'll store our individual copies of projects
> in upper level directories named <project>_<initials> holding the
> actual "project.mtn" database. Then creating a workspace/subdir under
> that for each branch that comes along. So, for my test "kippers"
> project, I propose the following directory/workspace structure:
>
> c:\kippers_km\  ... top level for this project, contains the DB file 
> kippers.mtn
> c:\kippers_km\main\ ... "main" branch/workspace in this subdir
> c:\kippers_km\cart\  ... "cart" advanced development branch for
> eventually selling kippers
> c:\kippers_km\minor_bugs\ ... branch for fixing easy/quick bugs
> ..... etc.
>
> Please feel free to comment on whether this seems feasible; I'm really
> just starting out on this and now's the time to fix it!

That sounds fine. Sorry, I might have caused more confusion than helping 
you...

However, some more thoughts:

 - AFAICT, it's quite common to name the 'main branch' 'trunk'.
 - see the wiki for branch naming conventions [1]

> Actually, by "back up" I meant "cd .." back up to my top level project
> directory (c:\kippers_km\ - see above). From there I deleted the
> "wrong-branch-name" subdirectory/workspace and its contents using
> Windows commands "del" and "rmdir"; this is where I should have used
> "mtn drop" instead, or could I have just renamed the directory - would
> mtn have figured that out?

No, and it absolutely does not matter, how you name these directories. 
Let me give you an example:

  mtn --db monotone.db checkout -b net.venge.monotone random_dir_name
  cd random_dir_name
  mtn status   # works
   ...
  cd ..
  mv random_dir_name  another_dir_name
  cd another_dir_name
  mtn status   # does still work
   ...

Sorry, this is UNIX speech, but I think you get what I mean. The 
workspace directory (the one containing _MTN) can be named whatever you 
like. Monotone only cares about things *in* that directory.

> This is the first I've created this particular project, so there's
> nothing to sync with yet, and only the one file with only two
> revisions to it, so I'm not doing updates or anything very advanced at
> this point.

Okay.

Another side note (and I'm really getting picky here ;-)  it's only for 
clarification, to give you the feeling for how monotone works): in 
monotone you never have a 'file with x revisions'. In monotone, a 
revision is a complete set of files and directories - basically what you 
have after a checkout. So what you've rather had is two revisions with 
only one file each.

> Thanks again for the help and any additional suggestions,

You are very welcome. Thank you for using monotone! Do you mind sharing 
what projects you are using monotone for? We'd certainly like to enlarge 
our list of projects using monotone...

Regards

Markus


[1]: Monotone Wiki: BranchNamingConventions:
http://www.venge.net/mtn-wiki/BranchNamingConventions