tracking issues: was: Hg and web development: your experience ?

[Guo Tang]

What is the advantage of using MQ here?

I am stuck with clearcase UCM at work. Sometimes when I want to try some 
crazy ideas, I ended with some activitis in UCM, which later force me to
do merge when I rebase, or I am forced to delivery my crazy temp work due 
to activity dependency. Bad thing.

So I just use hg. First I do a snapshot of clearcase to hg, in log 
message, call it "baseline". Then hijack the files I want to modify. checkin hg. Before 
CC rebase, hg update to "baseline", CC update, merge to hg heads. I will 
ended up with lots of heads in hg. But that is fine, since hg update -C is 
fast. 

What is the advantage of MQ here over keep track of several hg heads? One 
of them is CC "baseline". Others are my temp works.

Thanks,
Guo

On Sat, 19 Jan 2008, Giorgos Keramidas wrote:

> On 2008-01-18 19:18, "Michael P. Soulier" <msoulier at digitaltorque.ca> wrote:
> >On 14/01/08 Giorgos Keramidas said:
> >> One of the 'tricks' I use in a production tree at work, where I have to
> >> integrate changes from a Subversion tree, to a staging area, build and
> >> then commit to Perforce is:
> >
> > This raises a question. I'm stuck using ClearCase at work, but I'm tempted to
> > do my work in Mercurial, and then merge into CC in time for official builds.
> > The main issue is issue tracking.
> >
> > We're using CC with UCM, so every change you make should correspond to a
> > single activity (bug or feature). If each of my changesets corresponds
> > similarly, how easy would it be for me to push those changesets one-by-one
> > into CC, changing the current activity after each one such that the patches
> > accurately represent the work for that activity?
> >
> > Has anyone done something like this?
> 
> That's why I am using Mercurial to develop stuff at work.
> 
> We are stuck with Perforce, which isn't my choice.  But every commit has
> to be related to a bug ID.  Sometimes I want to explore various options,
> and build temporary "test" versions, but I don't like losing work.  I
> can't commit to Perforce until I'm done and I can't save my work until I
> commit.
> 
> Enter Mercurial Queues...
> 
> I periodically import snapshots of the source tree from Perforce, and I
> use MQ to stack a set of patches on top of it.  I can use MQ to fold
> multiple patches into one, to version the patch queue, to push/pop
> patches until I am confident that it all works, and so on.
> 
> Right before committing I re-import from Perforce and use MQ to rebase
> my patches on top of the latest tree.  Then I prepare *one* patch per
> bugfix, and I commit that in Perforce, using:
> 
> 	cd ~/p4/workspace
> 	gpatch -p1 < /tmp/patchfile
> 
> 	[ perforce the perforce "chant" for committing in one go ]
> 
> Then I 'qdelete' the patches from my MQ based patch series and 'qcommit'
> once more recording the Perforce changeset ID which incorporated the
> qdeleted patch.
> 
> This seems to work well enough with Perforce, but the whole process is
> fairly Perforce-agnostic until the very final step, so I don't see why
> it wouldn't work with ${ANYSCM}.
> 
> - Giorgos
> 
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
>