Tags & production questions

[Matt Mackall]

On Thu, May 03, 2007 at 10:39:33PM +0200, Guido Ostkamp wrote:
> 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'?

You can check out the empty revision with "hg co null". If you want to
clobber changed files in the process, add -C. Removing ignored files
is another matter.

-- 
Mathematics is the supreme nostalgia of our time.