I have a web project managed with Mercurial.
the "default" Branch is the main. we use it in my company as release branch.
now I need to «clone» this release to add custom forms for a new consumer: i created a new branch: "idea"
when i find a bug in default, I just need to merge "default" into "idea" and the fix is available for the fork.
but when I fix a bug in "idea" in a release, how do i apply it into default without adding the custom forms in the default branche?
in this case, i need to merge the rev 110 and 111 in default, but only thes rev
o 111[tip] 3d14d9c9096d 2013-03-14 18:11 +0100 darius
| ajout de la gestion des droit sur etat de tickets
|
o 110 5be5e130241c 2013-03-14 16:49 +0100 darius
| correction bug unité article
|
o 109:100,108 8c2ea9d76a2f 2013-03-14 16:44 +0100 darius
|\ fusion avec default
| |
| # 108 7d175b11327f 2013-03-14 16:36 +0100 darius
| | correction du bug des unité
| |
| o 107 adc0dcf2bfc8 2013-03-14 14:59 +0100 darius
| | correction taille bar
| |
| o 106 f41472a6c515 2013-03-14 14:44 +0100 darius
| | correction js des popup de fichiers attaché
| |
| o 105 e5c7e243bcca 2013-03-13 17:15 +0100 darius
| | correction bug de blocnote et z-index typeahead
| |
| o 104 72566ddba6b3 2013-03-08 12:28 +0100 darius
| | ajout des graphes d'activité par client
| |
| o 103 d069dfb24006 2013-03-08 10:09 +0100 darius
| | correction du bug de blocnote supprimé a cause de char null dans le blocnote
| |
| o 102 6dc51702fde0 2013-03-07 18:06 +0100 darius
| | ajout du lien de fichier qui ouvre dans une autre fenetre
| |
| o 101:99 96f6af3df7f7 2013-03-07 17:12 +0100 darius
| | refractoring des stats dans une appli ticket_stats et ajout du activite by clien
| |
o | 100:97,99 941134915ff0 2013-03-06 15:34 +0100 darius
|\| Fusion avec default
| |
| o 99 67a2e2f2b263 2013-03-06 15:11 +0100 darius
| | correction click sur adress mail dans les ticket
| |
| o 98:95 a20ba888c900 2013-03-06 12:26 +0100 darius
| | correction du bug des accents dans les nom de fichiers et de la modif d'activite
| |
o | 97 b1930e15c1be 2013-03-05 17:59 +0100 darius
| | modif du settings.dev_on_prod et du formulaire de ticket
| |
o | 96:92,95 a51f00d107d7 2013-03-05 17:55 +0100 darius
|\| Fusion avec default
| |
| o 95 f3f3234f38e6 2013-03-05 17:54 +0100 darius
| | ajout des user pas admin ok
| |
| o 94 2c0e09aab0ab 2013-03-05 17:43 +0100 darius
| | correction bug de creation d'utilisateur via admin
| |
| o 93:91 051d00064aba 2013-03-05 17:38 +0100 darius
| | retrait du cache sur les ticket a cause de boucles recursive au niveau du cache
| |
o | 92:89,91 0d7ce90cd324 2013-03-05 17:08 +0100 darius
|\| Fusion avec default
| |
| o 91 43357d05bdd6 2013-03-05 17:07 +0100 darius
| | correction cas ou pas de hierarchie
| |
| o 90:88 984da3636ded 2013-03-05 16:12 +0100 darius
| | correcion bug creation contacts
| |
o | 89 605374295adc 2013-03-05 15:14 +0100 darius
|/ ajout de la branche idea
|
o 88 2f699fca00d5 2013-03-05 15:12 +0100 darius
| mise a jour des libs required
|
o 87 f37e580921cc 2013-03-05 14:32 +0100 darius
| ajout du cache sur les objet Cegid
|
sry for my poor english. it is not my mother language.
This looks like a work for graft.
hg -v help graft
This command uses Mercurial's merge logic to copy individual changes from
other branches without merging branches in the history graph. This is
sometimes known as 'backporting' or 'cherry-picking'.
...
In your case you need a: hg graft "110::111"
EDIT: It looks like you're already on 108, otherwise> hg update 108
It would be preferable to commit the fixes in the default branch only. If a fix is already committed in the "idea" branch, then the best thing to do is to export the fix changeset as a patch, and to apply this patch on the default branch.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
I have a table like this
ID | DrugstoreName | date | city | zipcode
1 | a1 | 2015-10-19 | paris 01 | 75001
2 | a2 | 2015-10-23 | paris 02 | 75002
3 | a3 | 2015-10-19 | paris 05 | 75005
4 | a4 | 2015-10-24 | marseille | 13000
5 | a5 | 2015-10-19 | nice | 06000
6 | a6 | 2015-10-23 | paris 09 | 75009
7 | a7 | 2015-10-24 | paris 09 | 75009
8 | a8 | 2015-10-24 | paris 03 | 75003
9 | a9 | 2015-10-23 | paris 03 | 75003
10 | a10 | 2015-10-19 | paris 04 | 75004
What I am trying to do is to select distinct (city/zipcode) from my table, for which i don't have any matching records with at least one of certain dates (date1,date2,date3).
and if possible also show the nearest date for which we have no record.
for example i want to select distinct (city,zipcode, nearest-date-not-found) WHERE date doesn't match at least one of ("2015-10-23","2015-10-24");
the result should be:
paris 01 | 75001 | 2015-10-23
paris 02 | 75002 | 2015-10-24
paris 05 | 75005 | 2015-10-23
marseille | 13000 | 2015-10-23
nice | 06000 | 2015-10-23
paris 04 | 75004 | 2015-10-23
It's a bit complicated, and i know that i should think about redesigning my tables. but this is what I have for the moment, and i should deal with it.
The trick here is you want dates for missing records. So how do you select data from a database when data isn't present? We need to create those missing records in order for the database to return them as a value.
In the below example we do this by cross joining to a derived table (Y) which contains the dates you want to limit by. This could also be accomplished by using SELECT Distinct date from Foo where date in ('2015-10-23','2015-10-24') assuming records exist for those dates. Then, by using aggregate functions, a distinct on dates and a having clause, we can generate the desired results.
An outer join would not work. It wouldn't generate dates for each of the city/zips only a null record. So this becomes a great time to understand cross join and why Cartesian products can help.
I used group_concat to show all missing dates and record dates. I did this so you could see why min(Y.date) returns the lowest date.
SELECT A.city, A.zipcode, min(Y.date) as Date,
group_Concat(Y.Date) as AllMissingDates,
group_Concat(A.Date) as RecordDates
FROM foo A
CROSS JOIN
(SELECT '2015-10-23' date UNION ALL SELECT '2015-10-24') Y
WHERE A.Date <> Y.date
GROUP BY City, ZipCode
Having count(Distinct A.Date) < 2;
SQL FIDDLE
**city zipCode Date AllMissingDates RecordDates**
marseille 13000 2015-10-23 2015-10-23 2015-10-24
nice 6000 2015-10-23 2015-10-24, 2015-10-19,
2015-10-23 2015-10-19
paris 01 75001 2015-10-23 2015-10-23, 2015-10-19,
2015-10-24 2015-10-19
paris 02 75002 2015-10-24 2015-10-24 2015-10-23
paris 04 75004 2015-10-23 2015-10-24, 2015-10-19,
2015-10-23 2015-10-19
paris 05 75005 2015-10-23 2015-10-23, 2015-10-19,
2015-10-24 2015-10-19
I want to use hg log to generate a brief changelog covering the changes of the latest release. Releases are tagged with a "v" prefix e.g. "v0.9.1" or "v1.0". Is it possible with revsets to select a range between the two last tags that start with "v", not including the older one of the two tags?
As an example if I have:
changeset 0
changeset 1
tag: v0.1
changeset 2
changeset 3
tag: bar
changeset 4
tag: v0.9
changeset 5
tag: foo
changeset 6
changeset 7
tag: v1.0
changeset 8
I'd like to select changesets 5 to 7, if possible without even specifying v0.9 and v1.0 only using the "v" prefix.
IF you really want the answer to the question, "what changed between two revisions" you have to do something a little verbose:
hg log -r 'ancestors(relB) - ancestors(relA)'
This is different than relA::relB in the case where there was branched development.
Consider the following history graph:
$ hg glog
# changeset: 7:cb998461fc2f
| tag: tip
| user: Danny Sadinoff <danny>
| date: Fri Nov 21 09:28:46 2014 +0000
| summary: Added tag relB for changeset b37a8f32de1d
|
o changeset: 6:b37a8f32de1d
|\ tag: relB
| | parent: 5:187092bb7e9b
| | parent: 3:2d5af4e62ad5
| | user: Danny Sadinoff <danny>
| | date: Fri Nov 21 09:27:47 2014 +0000
| | summary: merged
| |
| o changeset: 5:187092bb7e9b
| | user: Danny Sadinoff <danny>
| | date: Fri Nov 21 09:27:21 2014 +0000
| | summary: more branch work
| |
| o changeset: 4:dbfe8f003e51
| | parent: 1:68f933b431ec
| | user: Danny Sadinoff <danny>
| | date: Fri Nov 21 09:26:51 2014 +0000
| | summary: branched dev
| |
o | changeset: 3:2d5af4e62ad5
| | user: Danny Sadinoff <danny>
| | date: Fri Nov 21 09:26:17 2014 +0000
| | summary: Added tag relA for changeset 0ad160ab1455
| |
o | changeset: 2:0ad160ab1455
|/ tag: relA
| user: Danny Sadinoff <danny>
| date: Fri Nov 21 09:25:13 2014 +0000
| summary: mainline dev
|
o changeset: 1:68f933b431ec
| user: Danny Sadinoff <danny>
| date: Fri Nov 21 09:24:18 2014 +0000
| summary: added a line
|
o changeset: 0:4738f4f68f1e
user: Danny Sadinoff <danny>
date: Fri Nov 21 09:23:54 2014 +0000
observe the difference between #Kevin's result and the ancestors() approach:
$ hg log -r 'ancestor(relA, relB)::relB - ancestor(relA, relB)'
changeset: 3:2d5af4e62ad5
user: Danny Sadinoff <danny>
date: Fri Nov 21 09:26:17 2014 +0000
summary: Added tag relA for changeset 0ad160ab1455
changeset: 6:b37a8f32de1d
tag: relB
parent: 5:187092bb7e9b
parent: 3:2d5af4e62ad5
user: Danny Sadinoff <danny>
date: Fri Nov 21 09:27:47 2014 +0000
summary: merged
versus the ancestors approach, which tells the whole story.
$ hg log -r 'ancestors(relB) - ancestors(relA)'
changeset: 3:2d5af4e62ad5
user: Danny Sadinoff <danny>
date: Fri Nov 21 09:26:17 2014 +0000
summary: Added tag relA for changeset 0ad160ab1455
changeset: 4:dbfe8f003e51
parent: 1:68f933b431ec
user: Danny Sadinoff <danny>
date: Fri Nov 21 09:26:51 2014 +0000
summary: branched dev
changeset: 5:187092bb7e9b
user: Danny Sadinoff <danny>
date: Fri Nov 21 09:27:21 2014 +0000
summary: more branch work
changeset: 6:b37a8f32de1d
tag: relB
parent: 5:187092bb7e9b
parent: 3:2d5af4e62ad5
user: Danny Sadinoff <danny>
date: Fri Nov 21 09:27:47 2014 +0000
summary: merged
the actual "greatest common revision" between two revisions seems to be:
ancestor(ancestors(relB) - ancestors(relA))
so a pretty glog of the changes becomes:
$ hg glog -r 'ancestor(ancestors(relB) - ancestors(relA)):: relB'
o changeset: 6:b37a8f32de1d
|\ tag: relB
| | parent: 5:187092bb7e9b
| | parent: 3:2d5af4e62ad5
| | user: Danny Sadinoff <danny#sadinoff.com>
| | date: Fri Nov 21 09:27:47 2014 +0000
| | summary: merged
| |
| o changeset: 5:187092bb7e9b
| | user: Danny Sadinoff <danny#sadinoff.com>
| | date: Fri Nov 21 09:27:21 2014 +0000
| | summary: more branch work
| |
| o changeset: 4:dbfe8f003e51
| | parent: 1:68f933b431ec
| | user: Danny Sadinoff <danny#sadinoff.com>
| | date: Fri Nov 21 09:26:51 2014 +0000
| | summary: branched dev
| |
o | changeset: 3:2d5af4e62ad5
| | user: Danny Sadinoff <danny#sadinoff.com>
| | date: Fri Nov 21 09:26:17 2014 +0000
| | summary: Added tag relA for changeset 0ad160ab1455
| |
o | changeset: 2:0ad160ab1455
|/ tag: relA
| user: Danny Sadinoff <danny#sadinoff.com>
| date: Fri Nov 21 09:25:13 2014 +0000
| summary: mainline dev
|
o changeset: 1:68f933b431ec
| user: Danny Sadinoff <danny#sadinoff.com>
| date: Fri Nov 21 09:24:18 2014 +0000
| summary: added a line
|
If you know the names of the tags off the top of your head:
hg log -r 'v0.9::v1.0 - v0.9'
If you don't, you can find out:
hg log -r 'last(tag("re:^v"), 2)'
The first log command only makes sense if v0.9 is an ancestor of v1.0; if this is not the case, you can use a single colon instead of ::, but the result will probably be total nonsense. In that scenario, you may want something like this instead:
hg log -r 'ancestor(v0.9, v1.0)::v1.0 - ancestor(v0.9, v1.0)'
That will produce a log of all changes starting from the most recent common ancestor of v0.9 and v1.0. If v0.9 is an ancestor of v1.0, this degenerates to the same behavior as the first log command.
Here is what my table looks like
----------------------------+-----------+
| tw_dt | text | ID |
+--------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------+-----------+
| Thu Dec 12 19:14:13 +0000 2013 | #CoSignCountdown airs MON-FRI #7p send in your hottest song to cosigncountdown#gmail.com Original music ONLY!!! #TEAMFOLLOWBACK #HipHopDotCA | 14985388 |
| Thu Dec 12 19:14:12 +0000 2013 | "Get any Beat at http://t.co/R61XJ5EYUQ for $200 each. Exclusive Rights. To pruchase - GummyBeatz#Gmail.com" | 170900539 |
| Thu Dec 12 19:14:09 +0000 2013 | "#iwantmixedbabys PREMO is looking for Models for the SuperBadd fashionshow January10th 3000 EXPECTED email us premopresents#gmail.com" | 343062689 |
| Thu Dec 12 19:14:09 +0000 2013 | mixtape hosting contact . bookdjlyrical#gmail.com | 99644471 |
| Thu Dec 12 19:14:09 +0000 2013 | checkout http://t.co/4f2txyVpLy RIGHT NOW!!!! #Artist send in music and videos to preciseearz#gmail.com #BlogsAreTheNewMixtapes | 27872863 |
| Thu Dec 12 20:01:10 +0000 2013 | ATTENTION ARTISTS: DO YOU NEED US TO HELP YOU PROMOTE YOUR MUSIC?!? EMAIL US FOR OUR PROMO PACKAGES AT VIEWHIPHOP#gmail.com | 357913081 |
| Thu Dec 12 20:01:10 +0000 2013 | RT #ITSMIKESWAGGER: #Mike_Bell1 no doubt my artist appreciates the love mikeswagger#gmail.com hit me up | 165499064 |
| Thu Dec 12 20:01:10 +0000 2013 | #grandst #cmj_333 - swking1964#gmail.com is my Santa - but just needs to be aware of your site in General! Happy Holidays! | 574317429 |
+--------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------+-----------+
I want to extract the email address from the text as it's own column.
Any thoughts on how I accomplish this in MYSQL?
Well, there's this huge regex for matching e-mail addresses. Combined with the regex replace solution found here, you should be good to go.
My repo has two branches: default and stable. I probably messed up somewhere. I am seeing two heads. Is this normal?
Here are the heads:
changeset: 10:b4131c44f968
branch: stable
tag: tip
parent: 8:f06486c8c9f1
parent: 9:135102b0cb32
user: nobody nobody <nobody#nobody.org>
date: Mon Apr 29 00:08:57 2013 -0400
summary: Merged with development on #2
changeset: 9:135102b0cb32
parent: 7:cf9ae7e052dd
parent: 8:f06486c8c9f1
user: nobody nobody <nobody#nobody.org>
date: Mon Apr 29 00:08:20 2013 -0400
summary: BUG: Working on #2 gallery width/height not set.
Here is the graphlog.
nobody#nobody:~/hg/project-js-backup$ hg log -G
o changeset: 10:b4131c44f968
|\ branch: stable
| | tag: tip
| | parent: 8:f06486c8c9f1
| | parent: 9:135102b0cb32
| | user: nobody nobody <nobody#nobody.org>
| | date: Mon Apr 29 00:08:57 2013 -0400
| | summary: Merged with development on #2
| |
| # changeset: 9:135102b0cb32
|/| parent: 7:cf9ae7e052dd
| | parent: 8:f06486c8c9f1
| | user: nobody nobody <nobody#nobody.org>
| | date: Mon Apr 29 00:08:20 2013 -0400
| | summary: BUG: Working on #2 gallery width/height not set.
| |
o | changeset: 8:f06486c8c9f1
|\| branch: stable
| | parent: 6:c8a92230bc6c
| | parent: 7:cf9ae7e052dd
| | user: nobody nobody <nobody#nobody.org>
| | date: Sun Apr 28 23:14:37 2013 -0400
| | summary: Merged with devleopment branch. Fixed #1 data reporting double /beta in url.
| |
| o changeset: 7:cf9ae7e052dd
| | parent: 5:7582497d8a1b
| | user: nobody nobody <nobody#nobody.org>
| | date: Sun Apr 28 23:09:11 2013 -0400
| | summary: BUG: Fixed issue #1.
| |
o | changeset: 6:c8a92230bc6c
|/ branch: stable
| user: nobody nobody <nobody#nobody.org>
| date: Tue Apr 23 13:26:23 2013 -0400
| summary: Created branch stable
|
o changeset: 5:7582497d8a1b
| user: nobody <nobody#nobody.org>
| date: Mon Apr 22 17:54:43 2013 -0300
| summary: Fixed result should return 200 not 201.
|
o changeset: 4:69ddb4892fc7
| user: nobody <nobody#nobody.org>
| date: Mon Apr 22 17:49:50 2013 -0300
| summary: Fixed response.status on line 272.
|
o changeset: 3:b029e0a90db8
| user: nobody <nobody#nobody.org>
| date: Mon Apr 22 17:48:18 2013 -0300
| summary: get rid of response_ok check in other functions.
|
o changeset: 2:9dbccc12d211
| user: nobody <nobody#nobody.org>
| date: Mon Apr 22 17:28:01 2013 -0300
| summary: get rid of response_ok check in postCreateResult
|
o changeset: 1:517b642f7785
| user: nobody nobody <nobody#nobody.org>
| date: Mon Apr 22 16:05:53 2013 -0400
| summary: Initialized ged.js
|
o changeset: 0:b7eb08ae529a
user: nobody <nobody#nobody.org>
date: Mon Apr 22 13:04:36 2013 -0700
summary: Initial commit
If I need to merge, I tried combining them with (base on this http://kiln.stackexchange.com/questions/1696/how-to-fix-multiple-heads/1698#1698)
hg up -C -r 10
hg merge -r 9
but I get abort: merging with a working directory ancestor has no effect.
Idea?
This is completely normal when you use two branches. Each branch has just one head and that means that there's nothing more to merge. Use
$ hg heads default
$ hg heads stable
to double-check this. You'll also notice that hg merge reports that there is nothing to merge: it will only look for a second head on your current branch.
Using two branches allow you to divide the changesets in your repository into two sets: the stable ones and the default ones. You make bugfixes on the stable branch (thus creating more stable changesets). You then merge stable into default to propagate the bugfix back to the default branch where your main development lives. Please see Mercurial's wiki for more info. My guide to named branches might also be useful.
I have a repo in a condition I don't understand. 2 weeks ago, I tagged a release to mark a particular point I may have needed to go back to. Later, I decided to branch, and have also been pulling in changes from another repo (the repo that I originally cloned).
The original rev that is of interest is 52:
changeset: 52:5044a88ba2a9
date: Mon Jan 10 18:09:30 2011 -0500
A few commits later, I branched into "MultiPartition" (I should have done this immediately, but I didn't anticipate needing it).
After some more work, I pull changes from the sister repo (all the changes do not conflict with my work in the branch, so it's safe).
Here's what I see now:
$ hg branches
MultiPartition 75:9fd803c56505
default 72:3939850a77e2 (inactive)
Where I'm working in MultiPartition, and default is the tip from the sister repo.
If I look at the heads:
$ hg heads
changeset: 75:9fd803c56505
branch: MultiPartition
tag: tip
date: Tue Jan 18 18:32:38 2011 -0500
changeset: 72:3939850a77e2
parent: 69:997a5b43216d
date: Tue Jan 18 13:26:48 2011 -0500
changeset: 54:4ad1d36a79aa
date: Thu Jan 13 19:14:57 2011 -0500
there's rev 54 hanging out there, which I didn't (knowingly) mean to leave behind.
Here's where it gets strange: The changeset 52 isn't in my current MultiPartition tip (though it was actually in the source on my disk, as I expected). I've attached a graphlog of the changesets at the bottom.
If I use the hgcontains extension, I see:
$ hg headscontaining 52
changeset: 75:9fd803c56505
branch: MultiPartition
tag: tip
date: Tue Jan 18 18:32:38 2011 -0500
which tells me that the contents of rev 52 (which has new files I want in the current branch) should be in the tip of this branch. However, an hg update -C MultiPartition removes the new files from the directory I want them in.
If I use hgtk log and filter by the directory of interest, I see the 52 changeset which adds the files, but no newer changesets have any files removed from this directory.
The only thing that makes me wonder is this: Changeset 71 was the merge from the original repo. In that repo, those new files don't exist. The log for that changset is:
| o changeset: 71:ba4c67a24185
|/| branch: MultiPartition
| | parent: 70:2dcbf69c325d
| | parent: 69:997a5b43216d
| | date: Mon Jan 17 17:55:10 2011 -0500
Here's my core question:
If parent 70: has what I expected, but parent 69: didn't, how is that resolved?
How can I check for other omissions? Is there a way to see this sort of behavior?
I want to not have multiple heads, but I can't seem to "merge" them. Technically, they are already merged (I think). How should I clean this up?
Sorry if this is complex, but I don't know how else to ask the question except for giving a ton of info.
Full graphlog:
o changeset: 75:9fd803c56505
| branch: MultiPartition
| tag: tip
| date: Tue Jan 18 18:32:38 2011 -0500
|
o changeset: 74:be7df4e2579c
|\ branch: MultiPartition
| | parent: 73:3e7ac80ab37a
| | parent: 72:3939850a77e2
| | date: Tue Jan 18 18:31:24 2011 -0500
| |
| o changeset: 73:3e7ac80ab37a
| | branch: MultiPartition
| | parent: 71:ba4c67a24185
| | date: Tue Jan 18 18:28:51 2011 -0500
| |
o | changeset: 72:3939850a77e2
| | parent: 69:997a5b43216d
| | date: Tue Jan 18 13:26:48 2011 -0500
| |
| o changeset: 71:ba4c67a24185
|/| branch: MultiPartition
| | parent: 70:2dcbf69c325d
| | parent: 69:997a5b43216d
| | date: Mon Jan 17 17:55:10 2011 -0500
| |
| o changeset: 70:2dcbf69c325d
| | branch: MultiPartition
| | parent: 66:79272b7e7c01
| | date: Mon Jan 17 17:42:04 2011 -0500
| |
o | changeset: 69:997a5b43216d
| | date: Mon Jan 17 12:00:09 2011 -0500
| |
o | changeset: 68:b39f8a7af0c5
| | date: Sun Jan 16 20:23:43 2011 -0500
| |
o | changeset: 67:63d3b40427e0
| | parent: 58:29029a74e351
| | date: Sun Jan 16 18:07:49 2011 -0500
| |
| o changeset: 66:79272b7e7c01
| | branch: MultiPartition
| | date: Mon Jan 17 09:43:32 2011 -0500
| |
| o changeset: 65:b33eb978d647
| | branch: MultiPartition
| | date: Mon Jan 17 09:39:54 2011 -0500
| |
| o changeset: 64:1fdafb6d0e84
| | branch: MultiPartition
| | date: Sun Jan 16 17:48:09 2011 -0500
| |
| o changeset: 63:74942ab5113d
| | branch: MultiPartition
| | date: Sun Jan 16 17:46:15 2011 -0500
| |
| o changeset: 62:2cd5a6d9d120
| | branch: MultiPartition
| | date: Sun Jan 16 01:55:23 2011 -0500
| |
| o changeset: 61:acc73e7a35fc
|/| branch: MultiPartition
| | parent: 60:c10e217081f0
| | parent: 58:29029a74e351
| | date: Sun Jan 16 01:53:01 2011 -0500
| |
| o changeset: 60:c10e217081f0
| | branch: MultiPartition
| | date: Sun Jan 16 01:45:16 2011 -0500
| |
| o changeset: 59:2709b82b3ac0
| | branch: MultiPartition
| | parent: 54:4ad1d36a79aa
| | date: Sun Jan 16 01:42:34 2011 -0500
| |
o | changeset: 58:29029a74e351
| | date: Sun Jan 16 01:36:44 2011 -0500
| |
o | changeset: 57:48840b75e37b
| | date: Fri Jan 14 11:04:06 2011 -0500
| |
o | changeset: 56:dab5f0d40be9
| | date: Thu Jan 13 15:51:11 2011 -0500
| |
o | changeset: 55:214ac45834fd
| | parent: 51:7d0a1da31199
| | date: Wed Jan 12 16:49:00 2011 -0500
| |
| # changeset: 54:4ad1d36a79aa
| | date: Thu Jan 13 19:14:57 2011 -0500
| |
| o changeset: 53:8f06d69177d6
| | date: Thu Jan 13 14:02:42 2011 -0500
| |
| o changeset: 52:5044a88ba2a9
| date: Mon Jan 10 18:09:30 2011 -0500
|
o
You actually still have two heads on the default branch, and one head on the MultiPartition branch, as hg heads has shown you. Use hg heads -t to see actual heads, regardless of branch. It looks like you use the graphlog extension, so use hg glog -r "branch(default)" to visualize your default branch.
As for your questions:
If parent 70: has what I expected, but parent 69: didn't, how is that resolved?
You can hg export -r 52 >52.patch then hg import 52.patch at the tip. This will reapply the changes. One of your merges must have dropped the content.
How can I check for other omissions? Is there a way to see this sort of behavior?
Not really. As far as Mercurial is concerned 52 is an ancestor of your tip. If the changes were dropped in a later changeset Mercurial doesn't really know. You can hg diff two different changesets and track down where it got removed (probably in the merge).
I want to not have multiple heads, but I can't seem to "merge" them. Technically, they are already merged (I think). How should I clean this up?
default is typically where you want all your development to end up. You can merge the two default heads, then hg ci --closebranch on MultiPartition and merge it into default.
1: If parent 70: has what I expected, but parent 69: didn't, how is that resolved?
I guess the files got removed in either the 61 or 71 merge. You can check this in hgtk with the "diff to second parent" option.
3: I want to not have multiple heads, but I can't seem to "merge" them. Technically, they are already merged (I think). How should I clean this up?
On your default branch are two anonymous heads (54 and 72, where 72 is the tip of default), and they will stay open as long as the MultiPartition branch is not merged back into default. Depite being later merged in the MultiPartition branch, they are still heads of the default branch, because mercurial does not consider a follow-up branch as a new head of a branch. The reason for this treatment is that you typically want the latest revision the a branch when you hg update branch.
You can get rid of the two default heads when you merge MultiPartition back into default. When you are done with MultiPartition you can also close this branch with hg ci --close-branch (technically you cant remove the MultiPartition head, but when it is closed hg heads wont consider it as active head).