Forest? Branches? And other beginner questions...

[Stuart W. Marks]

Marcin Kasperski wrote:
> (This is my first post to this list, so, before actual question, I would 
> like to thank the creators of mercurial. Interesting, well implemented 
> tool. Thank you.)
> 
> (background)
> I am new to mercurial (= I've read significant part of docs, and make 
> some experiments), and to the distributed source management (= have been 
> using RCS, DEC CMS, CVS and Subversion for years). Recently I decided to 
> adapt some distributed version control tool, read a couple of pages, 
> narrowed list to git and mercurial and finally picked the latter as I 
> need windows support.

I'm fairly new to mercurial as well, but I've confronted some of the same 
issues. I'll try to answer your questions.

> (question 1)
>  From the docs I've read I got the feeling, that I should use 'many 
> repositories' (= create separate mercury directory for every program, 
> library, documentation, whatever I track) - so the tagged, pulled, 
> pushed item is not made of a few independent entities. OK, let it be, 
> but if I then imagine having those 10 or maybe 20 separate projects, 
> tasks like verifying whether all are pushed to the main location, or 
> getting all the things to the new machine start being tedious.
> I noticed Forest plugin, which seem to be intended to help in such 
> cases. Unfortunately, it is almost undocumented (I can mostly guess what 
> the commands do, but some description of suggested process, layout etc 
> would be really useful)

I don't think the advice is necessarily to have separate repositories for each 
program, library, document, etc. If there is a set of related stuff, say some 
libraries and a set of programs that use those libraries, along with 
documentation, then it would make sense for them all to reside in the same 
repository. A key question is whether the artifacts are required to evolve at 
the same time. For example, if a change is made to a library, and change is 
made to a program that depends on the new version of the library, it might make 
sense to have them all in the same repository. But you also might put a bunch 
of stuff that is not so closely related in the same repository, merely because 
they're part of the same "family" of stuff, or for your convenience.

The advice about separate repositories is more about the workflow of developing 
and propagating changes. For example, many SCMs use a copy-modify-merge 
approach. In hg, the copy typically involves cloning some main repository into 
a local repository, and the merge would involve pushing changes from the local 
repository into the main repository. A more complicated setup might involve a 
team pushing changes from individual repositories into a workgroup repository, 
and then propagating these changes into a main repository at particular 
intervals. This is in contrast to centralized systems such as svn, where there 
is exactly ONE repository.

I don't know anything about the Forest extension. Looking at the extension page

http://www.selenic.com/mercurial/wiki/index.cgi/ForestExtension

it sort of makes sense, but I'm having trouble imagining the circumstances 
under which it would be useful.

> (question2)
> In git it is fairly clear, that one developer on one machine is using 
> one repo with many branches. In mercurial, it seemed each separate line 
> should be separate clone. But recently some branches command showed up, 
> not documented (almost). What is the current 'way of doing things'?

I think the preference for separate development lines is still separate 
repositories. However, there are a few cases where "in-repository" branches are 
called for. These branches probably don't work very well for individual 
developers. I think they're useful for development of parallel releases (e.g. a 
branch for patches to a 1.0 release, with 2.0 development on the main line) 
since having these in a single repository shows their relationship more clearly 
(to me at least). There are some things that still need to change in hg before 
this will work really well, though.

s'marks