Tags & production questions

[Satish Balay]

On Thu, 3 May 2007, Guido Ostkamp wrote:

> Hello Georg,
> 
> >> With ClearCase/CVS the solution is easy: The tag label 'Release1' for 
> >> the file B is moved to version 5 and we can go on with a fixed 
> >> production.
> >
> > Uhhhh, don't do that. If you keep any touch on continuity and 
> > reliability moving labels runs you into big troubles if anybody wants to 
> > rebuild exactly the previously released version. Perhaps, I'm too 
> > strict, but within the projects I have joined moving real release labels 
> > was always a desaster.
> 
> well, as you said, of course we never move labels once the version has 
> been produced, passed internal quality assurance and has been released to 
> customers. However, if there are errors during production or in early test 
> stages, I feel it's perfectly legal to adjust labels as this belongs to 
> the process of 'setting up' the version.
> 
> Yes, you could instead certainly add a lot of increasingly numbered 
> 'Release-candidate xyz' labels, but if just one file is missing or has a 
> wrong version out of possibly thousands of files, this used to be 
> overkill; also nobody has any interest in those rejected versions which 
> were never officially released.
> 
> Hm, possibly this kind of labeling might be easier with Mercurial.

The process you've mentioned assumes you don't hit any corner cases
[with wrong dependencies among changes] when you skip certain
revisions in your dev tree [or when you grab the latest sourcefile and
copy it over to the old release tag. etc..]

If these assumptions work for you with clear case/svn, then the
following process will work for you with mercurial.

- have a dev, release clones [instead of tags & branches]

- if you have a commit in dev that you want to apply to release do:
  * cd dev-repo
  * hg export rev10 rev12 > patchfile
  * cd release-repo
  * hg import patchfile

- now test release-repo code & publish

If you follow the 'release' process recommended by multiple folks in
this thread, the above process is still valid. [usually these changes
to release will cleanly merge back into dev]

You might be able to do the above with branches in a single repo.  But
personally I prefer using multiple clones. Is is easy to clobber over
yourself when working with multiple branches, so the simplicity
offered by multiple-clones is worth the disk-space tradeoff for me.

Satish