On Sat, Jan 9, 2010 at 10:25 AM, Michael Jay Lippert
<mlippert...@gmail.com> wrote:
> I've got a few questions I'm hoping someone can help me out with.
>
> I think the questions can be answered w/o having to read through my
> scenario, but I thought it might be useful for context.
>
> Scenario:
> We use Clearcase at work. Because it doesn't even support changesets and is
> frequently a pain to work with, and I was also interested in learning how
> mercurial works, I decided to use mercurial for the feature I'm currently
> working on. I've got TortoiseHg 0.9.2 installed on my Windows XP box
> (actually 2 of them).
>
> In order to use mercurial I have a couple of Clearcase views (of our
> codebase). One of them is on top of a hg repository. I use this one to
> periodically update the hg repository default branch with the latest changes
> in the Clearcase repository so that they match.
>
> The other Clearcase view I use for checking changes back into Clearcase. I
> might be able to use the 1st Clearcase view (the one w/ the hg repository
> under it) for this purpose, but there were a couple of issues before, so for
> now I don't want to confuse the issue. The major problem is that Clearcase
> requires that all files it is tracking be readonly unless the file has been
> checked out of Clearcase. If the file is not readonly and has not been
> checked out of Clearcase, it is considered "renegade".
>
> I've been doing my development in a clone of the hg repository that is under
> the Clearcase view lets call it 'Main', in a named branch I'll call 'Dev'.
> Every so often I pull the latest Clearcase changes from 'Main' to 'Dev', and
> then merge the default branch to my feature branch in 'Dev'.
>
> Now I'm ready to get my changes back into Clearcase.
> To do this I will need to:
>
> Check out every changed file from Clearcase.
> Then patch each of those files with my changes
> Then check them all back in.
The new Perfarce extension does almost this exact same thing, for
interaction with a perforce server. It also has the restriction that
files in the client workspace be read-only so is a real PITA. Let me
try to explain it's workflow in a little more detail.
To create an hg mirror of a part of a perforce server, you create a
'clientspec' that you never actually use. The clientspec just
provides the view of the server you would like to mirror. You then
do:
hg clone p4://server/clientspec mymirror
This pulls every changelist from the perforce server (that affects
files in your clientspec view) into the mymirror Mercurial repository.
The perforce changelist ID is stored in each changeset in the
"extras" area, so the extension can quickly determine whether a
changeset originated from p4 or from you. This is a more robust
method than your named branch method, but can only be done by an
extension with direct access to Mercurial's internal APIs.
Inside the mymirror repository, you can use hg incoming and hg pull to
see and import new changelists submitted to perforce. hg outgoing
will find the tip perforce changelist in your repo and reports
changesets from there to the tip.
When you push, the extension does the equivalent of 'hg status --rev
p4tip:tip', which outputs the list of modified, added, and removed
files accumulated between those two changesets. It then issues p4
commands to 'edit', 'add', or 'delete' those files. There is then a
separate step to submit the changes to the perforce server.
When you later pull the changelist with the changes you pushed, the
extension knows to import it as a merge changeset that connect the
'p4tip' and 'tip' changesets that were used to do the push.
> Question 1:
> Can I create a patch from the tip of my feature branch to the tip of the
> default branch? I see the 'export patch' in the context menu in the
> Repository Explorer in THG. It seems if I want to use that I'd have to do
> the merge first in mercurial, and then use that option to create the patch?
Select the tip of the default branch in the repository explorer. This
establishes a diff base. Right click on the tip of the feature
branch, then select 'diff with selected'. This opens a 'status'
window with the accumulated changes between the two branches. From
there you can use the file/hunk selection logic to leave out changes
you don't want in the patch, then click 'save as'.
> Question 2:
> How would I get a file containing a list of all the files that are patched
> by the patch I just created?
This is easy do do on the command line: hg status --rev default:feature
But that will prefix each file with their status char ('M', 'A', 'R').
Add the -n argument to remove the status character.
The patchutils package has utilities that extract data like this from
a patch file.
> Question 3:
> How do I apply the patch to the Clearcase view? I haven't ever used a patch
> file before and I'm not sure what patch tool to use or if the patch created
> by THG needs to be applied starting from a particular location and/or using
> special options.
>
> I'm probably going to get my changes checked into Clearcase on Monday, and I
> can do this all manually, but I thought there might be an easier way, and it
> was worth asking.
Mercurial/TortoiseHg will not apply patches outside of their
repository. You would need to use an actual version of 'patch' to do
that. There are cygwin and gnuwin32 packages that can be used.
http://gnuwin32.sourceforge.net/packages/patch.htm
http://gnuwin32.sourceforge.net/packages/patchutils.htm
If you know Python or are interested in learning, you could study the
'p4export' extension that I wrote that only does the 'push' operation
of the 'perfarce' extension (we started at about the same time and I
quickly joined with perfarce and dropped development on p4export).
The p4export() function gets the list of changes between the last p4
revision and the specified revision (defaults to tip) and applies them
to a perforce client spec.
http://bitbucket.org/sborho/p4export/src/tip/hgext/p4export.py
FYI: The changelog.nodesbetween() stuff is only used to collect
changeset messages from the mercurial commits and put them in a file
that could be used to make the p4 commit. I'd be glad to answer any
questions you have trying to follow what the source does.
----------------------------------
On an separate track, you could possibly implement your workflow in an
entirely different manner. When you are ready to push your work to
clearcase, simply push your Mercurial changesets to the workspace you
are using to import work into Mercurial.
Now chdir into that folder and run commands something like this (I
have no idea what clearcase commands look like, or how to make it take
a list of files on the command line).
clearcase edit "hg status -nm --rev .:feature"
clearcase edit"hg status -nr --rev .:feature"
hg merge feature
hg commit
clearcase delete "hg status -nr --rev .:feature"
clearcase add "hg status -na --rev .:feature"
clearcase commit
--
Steve Borho
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Tortoisehg-discuss mailing list
Tortoisehg-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tortoisehg-discuss
