Tags & production questions

[Guido Ostkamp]

Hello Mark,

>> well, in my case the fix has already been developed. Of course, it 
>> could be backported into a cloned repository, but having seperate 
>> repositories for each version means that you don't have the complete 
>> history in one repository so that tools showing the different branches 
>> don't work any longer, correct?
>
> No.
>
> Your current development stream will still have *all* the history in it, 
> minus the changes made in the cloned branch (i.e. the clone made at 
> release time) until you merge them across.
>
> Your cloned stream will have all the history that was available when it 
> was cloned.

that's exactly the point. If I do not merge it across, I cannot run e.g. 
'hg view' or 'hg glog' and see all my tags / branches at once. On the 
other hand, if I merge it, then additional cloned repositories will just 
use up additional space as the information is already available elsewhere.

> The least error prone method of branching in Mercurial (IMO) is via 
> cloned repositories.

Ok, as it doesn't need to 'hg update -C rev' to switch.

>> Furthermore I think you need significantly more disk space if each 
>> developer would have to keep several cloned repositories in his home 
>> directory.
>
> If you are developing under Windows, maybe.  Linux/Unix will hard link 
> on cloning if possible. See 
> http://www.selenic.com/mercurial/wiki/index.cgi/WindowsInstall?highlight=%28cloning%29%7C%28hardlink%29#head-fdd32e8f8fd45ec6231a3bccb94cc6a66c21956b

I think I've learned from the manuals, that hardlinking is only done for 
the history records, but not for the working copy which is usually around, 
otherwise editing of files in a clone would have negative impacts on other 
repositories. This means that keeping cloned repositories around needs a 
lot more disk space unless one avoids to check out the working copy when 
cloning or removes it after committing.

Even if there is no working copy around and hardlinks are possible, there 
is still a possibly large number of extra inodes used for that.

On the other hand, disadvantage of a single repository would be that a 
switch of the working copy is needed before any changes can be made to 
another version, and one can't keep any uncomitted stuff around because it 
might get overwritten.

By the way, I haven't found a command yet to get rid of the current 
working copy of an repository (with the exception of creating another new 
clone with 'hg clone -U'). Is there such a command, something like 'hg 
clobber'?

Regards,

Guido