Tags & production questions
Mark A. Flacy
mflacy at verizon.net
Thu May 3 23:56:01 UTC 2007
On 2007.05.03 15:39, 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.
The cloned stream will have all the history that was available at the instance of release.
The development stream will have all the history up to date.
Your cloned stream accurately reflects the state of things when you cut the release plus whatever bug fixes that you have developed on *that* stream.
IMO, you are vastly overrating the importance of all clones being able to see everything 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.
How big is your project? How large are your disk drives?
>
> 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.
You should read "hg help clone"...
You can safely clone repositories and checked out files using full
hardlinks with
$ cp -al REPO REPOCLONE
which is the fastest way to clone. However, the operation is not
atomic (making sure REPO is not modified during the operation is
up to you) and you have to make sure your editor breaks hardlinks
(Emacs and most Linux Kernel tools do so).
...which wouldn't help if you are running Windows, of course.
>
> 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.
Use reiserfs then.
More information about the Mercurial
mailing list