Mercurial in a corporate environment (migration from CVS)

[Stephen Morton]

On Tue, Jan 17, 2012 at 3:49 PM, Angel Ezquerra <ezquerra at gmail.com> wrote:

>
> On Jan 17, 2012 7:37 PM, "Stephen Morton" <stephen.c.morton at gmail.com>
> wrote:
> >
> > On Tue, Jan 17, 2012 at 11:36 AM, Harvey Chapman <hchapman-hg at 3gfp.com>
> wrote:
> >>
> >> On Jan 16, 2012, at 10:51 AM, Stephen Morton wrote:
> >>
> >> > But wait, there could be more commits since you did your update
> before doing the nightly build so the push could fail. So you do a pull
> first.
> >> > ...
> >> > But that only minimizes the conflict window but it still exists. So
> you have to implement retries.
> >>
> >> Arrange for your main repo to deny pushes while the build is pulling
> and tagging, i.e. "lock" it down with a hook. Remember to release the lock
> before starting the build.
> >>
> >
> > Yes, this is the "hg lock" extension that I was saying that I'd need to
> write. It's just sad that I have to do this for such a fundamental
> operation as tagging.
> >
> >>
> >> > But what if you use named branches? Some other nightly build process
> on another branch could have also added a tag. There could be a *real*
> file-level conflict on the .hgtags file.  So you have to write a script
> that resolves these conflicts, 99% of the time this just means taking all
> tags and removing conflict markers though a good script should check for
> duplicate tags too. And you've got this now:
> >>
> >> Serialize your nightly builds, or stagger them by 5 minutes.
> >>
> >
> >
> > Different builds on different branches are going to take different
> amounts of time. Staggering the builds by an amount of time is a good hack,
> but in the end it's just a hack and eventually one build is going to take 5
> minutes longer than another and they'll collide. (We don't intentionally
> write software that kinda works most of the time except when it doesn't
> around here.)
> >
> >
> > On Tue, Jan 17, 2012 at 3:23 AM, Didly <didlybom at gmail.com> wrote:
> >>
> >>
> >> I wonder if you could create the tags in a "tag branch", that is, a
> >> named branch where all the "tag changesets" (i.e. the modification so
> >> the .hgtags file) would be made. If you were the only one modifying
> >> that branch, wouldn't that solve the problem (as there would never be
> >> multiple heads on that "tag branch")?
> >
> >
> > This would solve the contention of tag operations being affected by
> regular designer commits. But would not solve the problem of tag operations
> being affected by other tag operations.
> >
>
> Why? I believe that mercurial looks for tags on all the heads on the repo.
> Your script could tag on its own "tag" branch, independently of everybody
> else, while you're users tag on their own branches.
>

If you use cloned repos for branching, then yes this is a solution.

But if you use named branches you still run the risk of conflicting with
_yourself_. If a bunch of asynchronous build daemons are all building loads
on different branches and updating the tags file on the tags branch, either
you've got to coordinate the daemons --a form of locking in itself-- or
protect the .hgtags file.

I suppose you could go one step further and make a bunch of named branches,
specifically for tagging, which have the same names as your named branches
but with "_tags" postpended and that could avoid the problem. So you'd have
working branches like "default", "rel1.0", "rel2.0", "rel3.0"and then
corresponding tags branches "default_tags", "rel1.0_tags", "rel2.0_tags",
"rel3.0_tags".
   And tagging would still not be completely trivial. You'd still need to
do something like:

current_changeset=`hg id -i`
hg pull
hg update ${branch}_tags
hg tag -r $current_changeset <tagname>
hg push
hg update $current_changeset  #Do not update to $branch because there could
have been commits since $current_changeset and you want your build
workspace to reflect what was actually built.


Stephen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20120117/59a4fe58/attachment-0002.html>