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

[Ken MacDonald]

On 4/18/07, Markus Schiltknecht <address@hidden> wrote:
> 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).

Hi Markus,
I wasn't planning to create a nested set of workspaces (though I did
that by accident once a few days ago when I first started playing with
mtn; good idea to avoid that!). Just a main directory to house the
project, and then a number of workspaces positioned below the main
directory.

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

It's called ClearCase; it actually becomes your filesystem, with all
access to files, directories, etc. pretty tightly controlled. In
general you can't just move, rename, or delete files or directories
without ClearCase's 'approval', so "do it and monotone will figure it
out" is a fairly drastic change. I've also worked with CVS, PVCS, CMS,
and a few others I've forgotten. No SVN (so far)!

> > 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).

Actually, I've proposed a central server in order to generally sync
with a 'star' topology (each user syncing primarily with the central
server). In practice, the actual machine hosting each developer's DB's
as well as the central server will be the same machine, thus using the
developer name to disambiguate individual project repositories in the
higher level directories, something like:

c:\kippers_km\ .... my copy of the 'kippers' project and all branches/workspaces
c:\kippers_fs\ ... fred smith's copy of 'kippers' project, etc.
...
c:\sardines_km\.... my copy of 'sardines' project
etc.

As I type this, I may modify my proposal, to where each developer
would have a top level directory for all of his copies of mtn
projects:

c:\mtn_km\ .... all of my project directories are under this main directory
c:\mtn_km\kippers\ ... my 'kippers' project
c:\mtn_km\sardines\ ... my sardines project
...
c:\mtn_fs\kippers\ ... fred's copy of 'kippers' project...
...
c:\mtn_server\kippers\ ... "central" copy of 'kippers'
... etc.

This would keep the top level of the disk structure a bit more
manageable after more projects are generated.

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

Actually, getting this out in the open and chatting about it is
helping me clarify my own thoughts about it....

>    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.

OK, that's in line with what I expected. As for U*X, I do that, too,
just that I've been testing on Windows, thus my examples...

> 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.

Of course you're right there. The nomenclature of mtn is rather
different than other VCS's I'm familiar with. In particular, I find
"divergence" amusing, as in ClearCase, it qualifies as a Very Bad
Thing, indicating that two copies of the database that should have
identical contents have incompatibilities.

> 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...

Um, we're doing website development mostly with PHP, MySQL, Flash, and
HTML/XHTML, so our 'projects' tend to be e-commerce or display sites
for local or national businesses and community organizations.

At any time, we're engaged in active development or site updates for
perhaps half a dozen of them. Some will probably migrate immediately
into mtn, while others are fairly static, for instance we may just
update their "upcoming artists" page once a month. In a case like
that, we probably do not absolutely need a VCS, as we'll have only a
single developer at a time making updates, and for only a few minutes.
We'll probably initially use mtn only for projects where multiple
developers need concurrent access to the code.
Ken