Tags in forests. My solution(s).

[Douglas Philips]

On 2008 Jun 6, at 4:59 PM, Roman Kennke wrote:
> really no need to merge, because we have no pull operation here). Now
> what happens when 2 or more processes are doing this. There's a chance
> (because hg doesn't know hg lock and hg unlock) that it ends up with  
> hg
> add tag-xyz1 && hg add tag-xyz2 && hg commit && hg commit. This might
> infact still work correctly (except that the second commit is a no- 
> op),
> but I have a _very_ bad feeling about such an attempt.

Why? Mercurial does do locking:
--------
via: http://hgbook.red-bean.com/hgbookch4.html

4.5.3  Concurrent access
...
Mercurial uses locks to ensure that only one process can write to a  
repository at a time (the locking mechanism is safe even over  
filesystems that are notoriously hostile to locking, such as NFS). If  
a repository is locked, a writer will wait for a while to retry if the  
repository becomes unlocked, but if the repository remains locked for  
too long, the process attempting to write will time out after a while.  
This means that your daily automated scripts won’t get stuck forever  
and pile up if a system crashes unnoticed, for example. (Yes, the  
timeout is configurable, from zero to infinity.)
--------

So it might be that some of the 'hg commit's are redundant or ignored,  
but locks make sure that either a changeset is committed or it isn't.  
Maybe you could explain in more detail what your concern is, I don't  
seem to be understanding...


> I'm not understanding your proposal correctly. My primary problem is
> that it really doesn't make sense to let multiple automatic processes
> push/pull to one single repository. With the tagging-as-cloning  
> approach
> it basically works like this:
> 1. The autobuilder fclones the dev-master to the tag location, thus
> creating a tag, let's call it xyz.
> 2. Then the autobuilder clones from that 'tag' clone to a temporary
> location on its machine, and builds the software
> 3. When the build is successful, the tag is renamed to xyz-ok,  
> otherwise
> it is simply rm -rf 'ed.

What's the point of step 1?
	Mercurial guarantees that the revisions that the autobuilder pulls in  
step 1 and step 2 will be the same.
	Why not just pull from dev-master in step 2 and in step 3 either pull  
to the xyz-ok location (same tags/revisions) or not.

> I haven't found a way that is very reliable using the hg tag or hg  
> fsnap
> approach. With snapshots it is much better, but there are still too  
> many
> commands involved for my taste, and synchronization is practically not
> existent in Mercurial, this calls for trouble.

I can't speak to your taste, but I am not seeing a reason to be  
worried about trouble. In fact, upon re-reading that section of the  
book quoted above, I am very much inclined to set up my new workflows  
using the snapshot method you outlined...

--Doug