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

[hendrik]

On Wed, Apr 18, 2007 at 08:53:02AM -0400, Ken MacDonald wrote:
> 
> 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'. 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!
> 

It;s probably worthwhile to document recommended practices for the use 
of monotone, addressing matters like:
   how do you organise multiple projects
   What to do if after your initial enthusiasm, you decide you picked 
     the wrong project names, or even an entire wrong tree structure
   How the developer should organise his workspace for multiple 
     projects

I find the discussion on policy branches a little airy right now, 
probably because we're not sure yet how these things are going to be 
used, either in the open-source or closed-source worlds.

Similarly, the new monotone user is at a loss as to best practices, or 
even what are good practices to choose from, with the concomitant fear 
that he won't be able to change his mind once he has set out wrong.

-- hendrik