Why did my branches completely merge? - version-control

I'm new to mercurial. I try to work on 2 versions of my software. I have named 2 branches : one is "v8" (old/stable) other is "default".
I thought I understood things but now I seem to have merged both versions.
This is what it looks like (removed info from before branch) :
o changeset: 39:1e72986020bd
| tag: tip
| parent: 37:406b8e897030
| user: ME <me#example.com>
| date: Thu Jan 16 09:53:55 2014 +0100
| summary: Suppression des DCU
|
| o changeset: 38:7381e3f2309b
|/| branch: v8
| | parent: 31:611a4416e4a5
| | parent: 37:406b8e897030
| | user: ME <me#example.com>
| | date: Wed Jan 15 19:21:58 2014 +0100
| | summary: fixforbrowser sur impressiondecomptes
| |
o | changeset: 37:406b8e897030
| | user: ME <me#example.com>
| | date: Wed Jan 15 19:02:18 2014 +0100
| | summary: fixforbrowser sur impressiondecomptes
| |
o | changeset: 36:d7c0feaad38a
| | user: ME <me#example.com>
| | date: Wed Jan 15 18:57:44 2014 +0100
| | summary: Cosmétique
| |
o | changeset: 35:d2b4c3130b61
| | user: ME <me#example.com>
| | date: Sun Jan 12 14:38:36 2014 +0100
| | summary: Cosmétique encore
| |
o | changeset: 34:5447f904a336
| | user: ME <me#example.com>
| | date: Fri Jan 10 03:51:33 2014 +0100
| | summary: projet
| |
o | changeset: 33:f48c4023d822
| | user: ME <me#example.com>
| | date: Fri Jan 10 03:50:06 2014 +0100
| | summary: cosmétique (beaucoup de fiches)
| |
o | changeset: 32:cc6b2de08004
| | parent: 30:5b4bef6aad09
| | user: ME <me#example.com>
| | date: Fri Jan 10 02:12:59 2014 +0100
| | summary: cosmétique
| |
| # changeset: 31:611a4416e4a5
| | branch: v8
| | parent: 29:0c47053f9a7b
| | user: ME <me#example.com>
| | date: Fri Jan 10 02:11:01 2014 +0100
| | summary: purge deleted ?
| |
o | changeset: 30:5b4bef6aad09
|\| parent: 25:74d793961989
| | parent: 29:0c47053f9a7b
| | user: ME <me#example.com>
| | date: Fri Jan 10 02:09:04 2014 +0100
| | summary: v9 after fixes
| |
| o changeset: 29:0c47053f9a7b
| | branch: v8
| | parent: 27:79855eedf019
| | user: ME <me#example.com>
| | date: Fri Jan 10 01:57:22 2014 +0100
| | summary: 8.084 ok?
| |
+---o changeset: 28:e60a7447adf4
| |/ branch: v8
| | parent: 25:74d793961989
| | parent: 27:79855eedf019
| | user: ME <me#example.com>
| | date: Fri Jan 10 01:41:05 2014 +0100
| | summary: 8.084 ??
| |
| o changeset: 27:79855eedf019
| | branch: v8
| | user: ME <me#example.com>
| | date: Wed Jan 08 16:57:12 2014 +0100
| | summary: fix detection des fichiers de récap sur imports feuillets
| |
| o changeset: 26:19d2f4b2d867
| | branch: v8
| | parent: 23:14219f06bc1d
| | user: ME <me#example.com>
| | date: Wed Jan 08 16:49:35 2014 +0100
| | summary: fix qpdep et qpdrm sur imports feuillets
| |
o | changeset: 25:74d793961989
| | user: ME <me#example.com>
| | date: Wed Jan 08 16:44:30 2014 +0100
| | summary: premieres modifs v9
| |
o | changeset: 24:1af3020ba120
| | parent: 22:7307bc3e87ba
| | user: ME <me#example.com>
| | date: Thu Dec 26 15:47:20 2013 +0100
| | summary: Initial v9
| |
| o changeset: 23:14219f06bc1d
|/ branch: v8
| user: ME <me#example.com>
| date: Thu Dec 26 15:41:55 2013 +0100
| summary: Branche stable v8
|
o changeset: 22:7307bc3e87ba
| user: ME <me#example.com>
| date: Fri Dec 20 18:50:50 2013 +0100
| summary: 8.083
Rev 31 seems to be the last "good" v8
then I did hg update default and worked on "default" branch.
I committed up to rev 36 because I knew I had to make a fix I would want to merge with stable/v8
I did the change, committed (rev 37)
then I switched to v8 with hg update v8
then I tried to merge the change from default with hg merge 406b8e897030
then I committed (rev 38)
I did a last commit after removing 3 binary (DCU) files that were in one of the repository although *.dcu are .hgignored.
Now, when I switch branches, I see no file change. I can go back to rev 31 with hg update v8 (probably useless) and hg update --rev 31 but I would like :
to understand what I did wrong
to get 2 clean branches back
If you know of a clear explanation of how branches and merge work, I'd love to read it.


Branches stores diverged history of changes in sources (of anything)
Merging branches brings to target branch fro source branch all changes, appeared from latest divergence point: it can be branchpoint or latest mergeset's parent
If you have to port only subset of changes from branch to branch (1+ changeset, but < ALL), you have to hg graft only these changesets

Related

Window function to achieve running sum that resets in Postgres SQL [duplicate]

I wrote a query that creates two columns: the_day, and the amount_raised on that day. Here is what I have:
And I would like to add a column that has a running sum of amount_raised:
Ultimately, I would like the sum column to reset after it reaches 1 million.
The recursive approach is above my pay grade, so if anyone knows a way to reset the sum without creating an entirely new table, please comment (maybe with a RESET function?). Thank you

I'd like to thank Juan Carlos Oropeza for providing a script and SQLFiddle with the test data. George, you should have done that.
The query itself it rather simple.
At first calculate a simple running sum (CTE_RunningSum) and divide it by 1,000,000 to get number of whole millions.
Then calculate the running sum again with partitioning by the number of millions.
SQL Fiddle
I included the columns RunningSum and Millions in the final result to illustrate how the query works.
WITH
CTE_RunningSum
AS
(
SELECT
ID
,day_t
,collect
,SUM(collect) OVER(ORDER BY day_t, id) AS RunningSum
,(SUM(collect) OVER(ORDER BY day_t, id)) / 1000000 AS Millions
FROM myTable
)
SELECT
ID
,day_t
,collect
,RunningSum
,Millions
,SUM(collect) OVER(PARTITION BY Millions ORDER BY day_t, id) AS Result
FROM CTE_RunningSum
ORDER BY day_t, id;
Result
| id | day_t | collect | runningsum | millions | result |
|-----|-----------------------------|---------|------------|----------|---------|
| 90 | March, 11 2015 00:00:00 | 69880 | 69880 | 0 | 69880 |
| 13 | March, 25 2015 00:00:00 | 69484 | 139364 | 0 | 139364 |
| 49 | March, 27 2015 00:00:00 | 57412 | 196776 | 0 | 196776 |
| 41 | March, 30 2015 00:00:00 | 56404 | 253180 | 0 | 253180 |
| 99 | April, 03 2015 00:00:00 | 59426 | 312606 | 0 | 312606 |
| 1 | April, 10 2015 00:00:00 | 65825 | 378431 | 0 | 378431 |
| 100 | April, 27 2015 00:00:00 | 60884 | 439315 | 0 | 439315 |
| 50 | May, 11 2015 00:00:00 | 39641 | 478956 | 0 | 478956 |
| 58 | May, 11 2015 00:00:00 | 49759 | 528715 | 0 | 528715 |
| 51 | May, 17 2015 00:00:00 | 32895 | 561610 | 0 | 561610 |
| 15 | May, 19 2015 00:00:00 | 50847 | 612457 | 0 | 612457 |
| 66 | May, 29 2015 00:00:00 | 66332 | 678789 | 0 | 678789 |
| 4 | June, 04 2015 00:00:00 | 46891 | 725680 | 0 | 725680 |
| 38 | June, 09 2015 00:00:00 | 64732 | 790412 | 0 | 790412 |
| 79 | June, 14 2015 00:00:00 | 62843 | 853255 | 0 | 853255 |
| 37 | June, 28 2015 00:00:00 | 54315 | 907570 | 0 | 907570 |
| 59 | June, 30 2015 00:00:00 | 34885 | 942455 | 0 | 942455 |
| 71 | July, 08 2015 00:00:00 | 46440 | 988895 | 0 | 988895 |
| 31 | July, 10 2015 00:00:00 | 39649 | 1028544 | 1 | 39649 |
| 91 | July, 12 2015 00:00:00 | 65048 | 1093592 | 1 | 104697 |
| 57 | July, 14 2015 00:00:00 | 60394 | 1153986 | 1 | 165091 |
| 98 | July, 20 2015 00:00:00 | 34481 | 1188467 | 1 | 199572 |
| 3 | July, 26 2015 00:00:00 | 58672 | 1247139 | 1 | 258244 |
| 95 | August, 19 2015 00:00:00 | 52393 | 1299532 | 1 | 310637 |
| 74 | August, 20 2015 00:00:00 | 37972 | 1337504 | 1 | 348609 |
| 20 | August, 27 2015 00:00:00 | 36882 | 1374386 | 1 | 385491 |
| 2 | September, 07 2015 00:00:00 | 39408 | 1413794 | 1 | 424899 |
| 14 | September, 09 2015 00:00:00 | 40234 | 1454028 | 1 | 465133 |
| 6 | September, 17 2015 00:00:00 | 65957 | 1519985 | 1 | 531090 |
| 93 | September, 29 2015 00:00:00 | 47213 | 1567198 | 1 | 578303 |
| 35 | September, 30 2015 00:00:00 | 49446 | 1616644 | 1 | 627749 |
| 86 | October, 11 2015 00:00:00 | 34291 | 1650935 | 1 | 662040 |
| 75 | October, 12 2015 00:00:00 | 31448 | 1682383 | 1 | 693488 |
| 19 | October, 14 2015 00:00:00 | 48509 | 1730892 | 1 | 741997 |
| 56 | October, 26 2015 00:00:00 | 30072 | 1760964 | 1 | 772069 |
| 48 | October, 28 2015 00:00:00 | 58527 | 1819491 | 1 | 830596 |
| 40 | November, 05 2015 00:00:00 | 67293 | 1886784 | 1 | 897889 |
| 33 | November, 09 2015 00:00:00 | 41944 | 1928728 | 1 | 939833 |
| 34 | November, 11 2015 00:00:00 | 35516 | 1964244 | 1 | 975349 |
| 85 | November, 20 2015 00:00:00 | 43920 | 2008164 | 2 | 43920 |
| 18 | November, 23 2015 00:00:00 | 44925 | 2053089 | 2 | 88845 |
| 62 | December, 24 2015 00:00:00 | 34678 | 2087767 | 2 | 123523 |
| 67 | December, 25 2015 00:00:00 | 35323 | 2123090 | 2 | 158846 |
| 81 | December, 28 2015 00:00:00 | 37071 | 2160161 | 2 | 195917 |
| 54 | January, 02 2016 00:00:00 | 32330 | 2192491 | 2 | 228247 |
| 70 | January, 06 2016 00:00:00 | 47875 | 2240366 | 2 | 276122 |
| 28 | January, 23 2016 00:00:00 | 40250 | 2280616 | 2 | 316372 |
| 65 | January, 25 2016 00:00:00 | 49404 | 2330020 | 2 | 365776 |
| 73 | January, 26 2016 00:00:00 | 65879 | 2395899 | 2 | 431655 |
| 5 | February, 05 2016 00:00:00 | 53953 | 2449852 | 2 | 485608 |
| 32 | February, 11 2016 00:00:00 | 44988 | 2494840 | 2 | 530596 |
| 53 | February, 25 2016 00:00:00 | 68948 | 2563788 | 2 | 599544 |
| 83 | March, 11 2016 00:00:00 | 47244 | 2611032 | 2 | 646788 |
| 8 | March, 25 2016 00:00:00 | 51809 | 2662841 | 2 | 698597 |
| 82 | March, 25 2016 00:00:00 | 66506 | 2729347 | 2 | 765103 |
| 88 | April, 06 2016 00:00:00 | 69288 | 2798635 | 2 | 834391 |
| 89 | April, 14 2016 00:00:00 | 43162 | 2841797 | 2 | 877553 |
| 52 | April, 23 2016 00:00:00 | 47772 | 2889569 | 2 | 925325 |
| 7 | April, 27 2016 00:00:00 | 33368 | 2922937 | 2 | 958693 |
| 84 | April, 27 2016 00:00:00 | 57644 | 2980581 | 2 | 1016337 |
| 17 | May, 17 2016 00:00:00 | 35416 | 3015997 | 3 | 35416 |
| 61 | May, 17 2016 00:00:00 | 64603 | 3080600 | 3 | 100019 |
| 87 | June, 07 2016 00:00:00 | 41865 | 3122465 | 3 | 141884 |
| 97 | June, 08 2016 00:00:00 | 64982 | 3187447 | 3 | 206866 |
| 92 | June, 15 2016 00:00:00 | 58684 | 3246131 | 3 | 265550 |
| 23 | June, 26 2016 00:00:00 | 46147 | 3292278 | 3 | 311697 |
| 46 | June, 30 2016 00:00:00 | 61921 | 3354199 | 3 | 373618 |
| 94 | July, 03 2016 00:00:00 | 55535 | 3409734 | 3 | 429153 |
| 60 | July, 07 2016 00:00:00 | 63607 | 3473341 | 3 | 492760 |
| 45 | July, 20 2016 00:00:00 | 51965 | 3525306 | 3 | 544725 |
| 96 | July, 20 2016 00:00:00 | 46684 | 3571990 | 3 | 591409 |
| 29 | August, 09 2016 00:00:00 | 37707 | 3609697 | 3 | 629116 |
| 69 | August, 11 2016 00:00:00 | 37194 | 3646891 | 3 | 666310 |
| 80 | August, 19 2016 00:00:00 | 62673 | 3709564 | 3 | 728983 |
| 36 | August, 28 2016 00:00:00 | 48237 | 3757801 | 3 | 777220 |
| 39 | August, 29 2016 00:00:00 | 48159 | 3805960 | 3 | 825379 |
| 25 | August, 30 2016 00:00:00 | 60958 | 3866918 | 3 | 886337 |
| 68 | September, 04 2016 00:00:00 | 50167 | 3917085 | 3 | 936504 |
| 55 | September, 08 2016 00:00:00 | 31193 | 3948278 | 3 | 967697 |
| 64 | September, 10 2016 00:00:00 | 31157 | 3979435 | 3 | 998854 |
| 42 | September, 14 2016 00:00:00 | 52878 | 4032313 | 4 | 52878 |
| 43 | September, 15 2016 00:00:00 | 54728 | 4087041 | 4 | 107606 |
| 77 | September, 18 2016 00:00:00 | 65320 | 4152361 | 4 | 172926 |
| 12 | September, 23 2016 00:00:00 | 43597 | 4195958 | 4 | 216523 |
| 30 | September, 26 2016 00:00:00 | 32764 | 4228722 | 4 | 249287 |
| 10 | September, 27 2016 00:00:00 | 47038 | 4275760 | 4 | 296325 |
| 47 | October, 08 2016 00:00:00 | 46280 | 4322040 | 4 | 342605 |
| 26 | October, 10 2016 00:00:00 | 69487 | 4391527 | 4 | 412092 |
| 63 | October, 30 2016 00:00:00 | 49561 | 4441088 | 4 | 461653 |
| 78 | November, 15 2016 00:00:00 | 40138 | 4481226 | 4 | 501791 |
| 27 | November, 27 2016 00:00:00 | 57378 | 4538604 | 4 | 559169 |
| 21 | December, 01 2016 00:00:00 | 35336 | 4573940 | 4 | 594505 |
| 16 | December, 03 2016 00:00:00 | 39671 | 4613611 | 4 | 634176 |
| 22 | December, 13 2016 00:00:00 | 34574 | 4648185 | 4 | 668750 |
| 72 | January, 29 2017 00:00:00 | 55084 | 4703269 | 4 | 723834 |
| 44 | January, 30 2017 00:00:00 | 36742 | 4740011 | 4 | 760576 |
| 24 | February, 01 2017 00:00:00 | 31061 | 4771072 | 4 | 791637 |
| 76 | February, 12 2017 00:00:00 | 35059 | 4806131 | 4 | 826696 |
| 9 | February, 27 2017 00:00:00 | 39767 | 4845898 | 4 | 866463 |
| 11 | February, 28 2017 00:00:00 | 66007 | 4911905 | 4 | 932470 |

I took a look again and couldnt solve it with a Windows Function so I took the recursive aproach
SQL Fiddle Demo
Sample Data: 100 rows random dates between 2015-2017 amounts between 10k - 70k
DROP TABLE IF EXISTS "myTable";
CREATE TABLE "myTable" (
id SERIAL PRIMARY KEY,
day_t varchar(255),
collect integer NULL
);
INSERT INTO "myTable" (day_t,collect) VALUES ('2015-04-10',65825),('2015-09-07',39408),('2015-07-26',58672),('2015-06-04',46891),('2016-02-05',53953),('2015-09-17',65957),('2016-04-27',33368),('2016-03-25',51809),('2017-02-27',39767),('2016-09-27',47038);
INSERT INTO "myTable" (day_t,collect) VALUES ('2017-02-28',66007),('2016-09-23',43597),('2015-03-25',69484),('2015-09-09',40234),('2015-05-19',50847),('2016-12-03',39671),('2016-05-17',35416),('2015-11-23',44925),('2015-10-14',48509),('2015-08-27',36882);
INSERT INTO "myTable" (day_t,collect) VALUES ('2016-12-01',35336),('2016-12-13',34574),('2016-06-26',46147),('2017-02-01',31061),('2016-08-30',60958),('2016-10-10',69487),('2016-11-27',57378),('2016-01-23',40250),('2016-08-09',37707),('2016-09-26',32764);
INSERT INTO "myTable" (day_t,collect) VALUES ('2015-07-10',39649),('2016-02-11',44988),('2015-11-09',41944),('2015-11-11',35516),('2015-09-30',49446),('2016-08-28',48237),('2015-06-28',54315),('2015-06-09',64732),('2016-08-29',48159),('2015-11-05',67293);
INSERT INTO "myTable" (day_t,collect) VALUES ('2015-03-30',56404),('2016-09-14',52878),('2016-09-15',54728),('2017-01-30',36742),('2016-07-20',51965),('2016-06-30',61921),('2016-10-08',46280),('2015-10-28',58527),('2015-03-27',57412),('2015-05-11',39641);
INSERT INTO "myTable" (day_t,collect) VALUES ('2015-05-17',32895),('2016-04-23',47772),('2016-02-25',68948),('2016-01-02',32330),('2016-09-08',31193),('2015-10-26',30072),('2015-07-14',60394),('2015-05-11',49759),('2015-06-30',34885),('2016-07-07',63607);
INSERT INTO "myTable" (day_t,collect) VALUES ('2016-05-17',64603),('2015-12-24',34678),('2016-10-30',49561),('2016-09-10',31157),('2016-01-25',49404),('2015-05-29',66332),('2015-12-25',35323),('2016-09-04',50167),('2016-08-11',37194),('2016-01-06',47875);
INSERT INTO "myTable" (day_t,collect) VALUES ('2015-07-08',46440),('2017-01-29',55084),('2016-01-26',65879),('2015-08-20',37972),('2015-10-12',31448),('2017-02-12',35059),('2016-09-18',65320),('2016-11-15',40138),('2015-06-14',62843),('2016-08-19',62673);
INSERT INTO "myTable" (day_t,collect) VALUES ('2015-12-28',37071),('2016-03-25',66506),('2016-03-11',47244),('2016-04-27',57644),('2015-11-20',43920),('2015-10-11',34291),('2016-06-07',41865),('2016-04-06',69288),('2016-04-14',43162),('2015-03-11',69880);
INSERT INTO "myTable" (day_t,collect) VALUES ('2015-07-12',65048),('2016-06-15',58684),('2015-09-29',47213),('2016-07-03',55535),('2015-08-19',52393),('2016-07-20',46684),('2016-06-08',64982),('2015-07-20',34481),('2015-04-03',59426),('2015-04-27',60884);
Create a row_number to perform the recursion need consecutive ID's
CREATE TABLE sortDates as
SELECT day_t,
collect,
row_number() over (order by day_t) rn
FROM "myTable";
Recursive Query
If you see the CASE if previous total m.collect is bigger than 1 million the total is reset.
WITH RECURSIVE million(rn, day_t, collect) AS (
(
SELECT rn, day_t, collect
FROM sortDates
WHERE rn = 1
)
UNION
(
SELECT s.rn, s.day_t, CASE WHEN m.collect > 1000000 THEN s.collect
ELSE m.collect + s.collect
END as collect
FROM sortDates s
JOIN million m
ON s.rn = m.rn + 1
)
)
SELECT *
FROM million
WHERE collect > 1000000
Finally just bring the rows where you break the 1 million limit.
OUTPUT
| rn | day_t | collect |
|----|------------|---------|
| 19 | 2015-07-10 | 1028544 |
| 41 | 2015-11-23 | 1024545 |
| 62 | 2016-05-17 | 1027511 |
| 82 | 2016-09-15 | 1006441 |

Symfony2 Query to find last working date from Holiday Calender

I had a calender entity in my project which manages the open and close time of business day of the whole year.
Below is the record of a specific month
id | today_date | year | month_of_year | day_of_month | is_business_day
-------+---------------------+------+---------------+-------------+---------------+
10103 | 2016-02-01 00:00:00 | 2016 | 2 | 1 | t
10104 | 2016-02-02 00:00:00 | 2016 | 2 | 2 | t
10105 | 2016-02-03 00:00:00 | 2016 | 2 | 3 | t
10106 | 2016-02-04 00:00:00 | 2016 | 2 | 4 | t
10107 | 2016-02-05 00:00:00 | 2016 | 2 | 5 | t
10108 | 2016-02-06 00:00:00 | 2016 | 2 | 6 | f
10109 | 2016-02-07 00:00:00 | 2016 | 2 | 7 | f
10110 | 2016-02-08 00:00:00 | 2016 | 2 | 8 | t
10111 | 2016-02-09 00:00:00 | 2016 | 2 | 9 | t
10112 | 2016-02-10 00:00:00 | 2016 | 2 | 10 | t
10113 | 2016-02-11 00:00:00 | 2016 | 2 | 11 | t
10114 | 2016-02-12 00:00:00 | 2016 | 2 | 12 | t
10115 | 2016-02-13 00:00:00 | 2016 | 2 | 13 | f
10116 | 2016-02-14 00:00:00 | 2016 | 2 | 14 | f
10117 | 2016-02-15 00:00:00 | 2016 | 2 | 15 | t
10118 | 2016-02-16 00:00:00 | 2016 | 2 | 16 | t
10119 | 2016-02-17 00:00:00 | 2016 | 2 | 17 | t
10120 | 2016-02-18 00:00:00 | 2016 | 2 | 18 | t
I want the get the today_date of last 7 working date. Supporse today_date is 2016-02-18 and date of last 7 working dates as 2016-02-09.

You can use row_number() for this like this:
SELECT * FROM
(SELECT t.*,row_number() OVER(order by today_date desc) as rnk
FROM Calender t
WHERE today_date <= current_date
AND is_business_day = 't')
WHERE rnk = 7
This will give you the row of the 7th business day from todays date

I see that you tagged your question with Doctrine, ORM and Datetime. Were you after a QueryBuilder solution? Maybe this is closer to what you want:
$qb->select('c.today_date')
->from(Calendar::class, 'c')
->where("c.today_date <= :today")
->andWhere("c.is_business_day = 't'")
->setMaxResults(7)
->orderBy("c.today_date", "DESC")
->setParameter('today', new \DateTime('now'), \Doctrine\DBAL\Types\Type::DATETIME));

Recursive formulaes in org-mode tables

I have the following table:
| Year (Beginn) | Price | Increase |
|---------------+----------+----------|
| 2016 | 20000.00 | 1000.00 |
| 2017 | | 1000.00 |
| 2018 | | 1000.00 |
| 2019 | | 1000.00 |
| 2020 | | 1000.00 |
| 2021 | | 1000.00 |
| 2022 | | 1000.00 |
| 2023 | | 1000.00 |
| 2024 | | 1000.00 |
| 2025 | | 1000.00 |
| 2026 | | 1000.00 |
| 2027 | | 1000.00 |
| 2028 | | 1000.00 |
| 2029 | | 1000.00 |
| 2030 | | 1000.00 |
|---------------+----------+----------|
I want to compute the price recursively such that the final table looks like this:
| Year (Beginn) | Price | Increase |
|---------------+----------+----------|
| 2016 | 20000.00 | 1000.00 |
| 2017 | 22000.00 | 1000.00 |
| 2018 | 24000.00 | 1000.00 |
| 2019 | 26000.00 | 1000.00 |
| 2020 | 28000.00 | 1000.00 |
| 2021 | 30000.00 | 1000.00 |
| 2022 | 32000.00 | 1000.00 |
| 2023 | 34000.00 | 1000.00 |
| 2024 | 36000.00 | 1000.00 |
| 2025 | 38000.00 | 1000.00 |
| 2026 | 40000.00 | 1000.00 |
| 2027 | 42000.00 | 1000.00 |
| 2028 | 44000.00 | 1000.00 |
| 2029 | 46000.00 | 1000.00 |
| 2030 | 48000.00 | 1000.00 |
|---------------+----------+----------|
After reading a related SO question I tried the formula
#+TBLFM: #<<<..>$2=#<<..>>$2+2*$3
but it doesn't work. It gives an error and also seems to operate on column one instead of the specified column two. Any idea how to correctly compute column two? I am using org-mode version 8.2.5c with Emacs version 24.5.1.

I recommend using the following range formula:
| Year (Beginn) | Price | Increase |
|---------------+----------+----------|
| 2016 | 20000.00 | 1000.00 |
| 2017 | | 1000.00 |
| 2018 | | 1000.00 |
| 2019 | | 1000.00 |
| 2020 | | 1000.00 |
| 2021 | | 1000.00 |
| 2022 | | 1000.00 |
| 2023 | | 1000.00 |
| 2024 | | 1000.00 |
| 2025 | | 1000.00 |
| 2026 | | 1000.00 |
| 2027 | | 1000.00 |
| 2028 | | 1000.00 |
| 2029 | | 1000.00 |
| 2030 | | 1000.00 |
|---------------+----------+----------|
#+TBLFM: #<<<$2..#>$2=#<<$0+2*vsum(#<<$3..#-1$3);%.2f
You could write a recursive formula, but that would propogate one row at a time. Even org-table-iterate (C-u C-u C-c * on any table cell) would have to be called more than once, since it stops after 10 iterations.

Cognos Calculate Variance Crosstab (Relational)

I have a simple crosstab such as this:
Trans | Pants | Shirts |
| 2013 | 2014 | 2013 | 2014 |
---------------------------------------
Jan | 33 | 37 | 41 | 53 |
Feb | 31 | 33 | 38 | 43 |
Mar | 26 | 29 | 51 | 56 |
Pants and Shirt belong to the data item: Category
Years belong to the data item: Years
Months belong to the data item: Months
Trans (transactions) belongs to the data item: Trans
Here is what is looks like in report studio:
Trans | <#Category#> | <#Category#> |
| <#Years#> | <#Years#> | <#Years#> | <#Years#> |
-----------------------------------------------------------
<#Months#>| <#1234#> | <#1234#> | <#1234#> | <#1234#> |
I want to be able to calculate the variance of pants and shirts between the years. To get something like this:
Trans | Pants | Shirts |
| 2013 | 2014 | YOY Variance | 2013 | 2014 | YOY Variance |
---------------------------------------------------------------------
Jan | 33 | 37 | 12.12 | 41 | 53 | 29.27 |
Feb | 31 | 33 | 6.45 | 38 | 43 | 13.16 |
Mar | 26 | 29 | 11.54 | 51 | 56 | 9.80 |
I've tried inserting a data item for YOY Variance with the expression below just to see if I can even get the 2014 value but cannot, some odd reason it only returns the 2013 values:
Total([Trans] for maximum[Year],[Category],[Months])
Any ideas? Help?

(I'm assuming you don't have a DMR.)
There is no easy/clean way to do this in Cognos. In your query, you'll have to build a calculation for each year in your output. So, something like this for 2013:
total (if [Years] = 2013) then ([Trans]) else (0))
And basically the same for 2014.
Cut the Trans piece out of your crossab. Then you'll nest those two calcs under your years. To get rid of all the zeroes or nulls, select the two columns. From the menu, select Data,
Suppress,Suppress Columns Only.
Finally, you will drop a calc in next to your Years in the crosstab (not under them). The expression will be ([2014 trans] - [2013 trans])/[2014 trans] (or whatever you end up naming your calcs). Format it as a percent, and you should be good to go.
Told you it was a pain!

Release management in Mercurial - [major].[minor].[bugfix] versioning with supporting older major versions

I have been exploring different answers about release management in Mercurial and almost found the right way of doing it. However, I just need a bit of help to get it right so that everything clicks nicely in my head.
Here is what our company needs:
1) Will be using versioning scheme {major.minor.patch} for development
2) Named branches and tags will be used for managing releases (as opposed to cloning repositories for example)
3) While working on release 3.0 we might need to support older major releases. For example if a bug is found in release 2.1 we will need to fix it (in release 2.1.1) and merge all the way back to the current release 3.0
Having researched different options and answers, the following great answer from Steve Losh (just copied the changeset tree below) is probably what we need but I can't get how you can work on 2.1.1 and merge all the way back to 3.0 in default if the latter has already been tagged?
$ hg glog -l 1000
# changeset: 25:efc0096f47c0 tip
| summary: Added tag 3.0 for changeset d1a7fc3d7d77
|
o changeset: 24:d1a7fc3d7d77 3.0
|\ summary: Merge in the redesign changes.
| |
| o changeset: 23:b5b69d24c8f7 3.0-dev
| | summary: Finish 3.0 redesign.
| |
| o changeset: 22:4c2f98fac54b 3.0-dev
|/| summary: Merge in the latest changes to 2.1/mainline.
| |
o | changeset: 21:37df04521032
| | summary: Added tag 2.1 for changeset 39ecc520fc0a
| |
o | changeset: 20:39ecc520fc0a 2.1
|\ \ summary: 2.1 development is done.
| | |
| o | changeset: 19:208f3f9236af 2.1-dev
| | | summary: Finish the 2.1 work.
| | |
| | o changeset: 18:4a024009a9d6 3.0-dev
| | | summary: More redesign work.
| | |
| | o changeset: 17:00c416888c25 3.0-dev
| |/| summary: Merge in changes from the 2.1 branch to keep the redesign current.
| | |
| o | changeset: 16:a57e781a0db1 2.1-dev
| | | summary: More 2.1 work.
| | |
| | o changeset: 15:ddeb65402a61 3.0-dev
| | | summary: More redesign work.
| | |
+---o changeset: 14:90f5d7a8af9a 3.0-dev
| | | summary: Merge in the fire fixes.
| | |
| o | changeset: 13:78a949b67bb9 2.1-dev
|/| | summary: Merge in the fire fixes.
| | |
o | | changeset: 12:6dfe9d856202
| | | summary: Oh no everything is on fire, fix it in the mainline.
| | |
| o | changeset: 11:86767671dcdb 2.1-dev
| | | summary: Smaller changes for 2.1.
| | |
| | o changeset: 10:25dec81d2546 3.0-dev
| | | summary: Work more on the redesign.
| | |
+---o changeset: 9:42c7d689fb24 3.0-dev
| | summary: Start working on a complete redesign.
| |
| o changeset: 8:3da99186ca7d 2.1-dev
|/ summary: Start working on 2.1.
|
o changeset: 7:9ba79361827d
| summary: Added tag 2.0 for changeset 755ed5c5e291
|
o changeset: 6:755ed5c5e291 2.0
|\ summary: Merge in the dev branch for 2.0.
| |
| o changeset: 5:44a833fcc838 2.0-dev
| | summary: Finish work on 2.0.
| |
| o changeset: 4:d7ba6aae1651 2.0-dev
|/| summary: Merge in the critical fix.
| |
o | changeset: 3:968049f1b33a
| | summary: Fix a critical bug on the main branch.
| |
| o changeset: 2:917869609b25 2.0-dev
| | summary: More work on the new version.
| |
| o changeset: 1:f95798b9cb2e 2.0-dev
|/ summary: Start working on version 2.0.
|
o changeset: 0:8a3fb044d3f4
summary: Initial commit.
In other words, with the above changeset tree/releases, is it possible to work on 2.1.1 fix while we already started working on 3.0? I mean how would we merge 2.1.1 back into default if the 3.0 has been tagged already? Am I missing something here? if not, is there a more suitable way for us to manage releases as per our requirments? It would be great if you could provide a similar snapshot of the changeset tree for the scenario.
Thanks very much in advance. You guys rock.

Based upon your requirement to maintain multiple release versions, I would consider a different branching strategy which uses the default branch for development and has a branch for each major version. This is described on this page - it also has a section on what to do about big fixes.
I've worked an example similar to the one above:
# changeset: 13:3d6ac57cce61
|\ tag: tip
| | parent: 9:5953138c3f87
| | parent: 12:9691c48d79f2
| | user: steve.kaye
| | date: Tue Jun 26 08:39:42 2012 +0100
| | summary: Merge bug fix
| |
| o changeset: 12:9691c48d79f2
| | branch: V3
| | user: steve.kaye
| | date: Tue Jun 26 08:35:23 2012 +0100
| | summary: Added tag 3.1 for changeset e49d9a6bb459
| |
| o changeset: 11:e49d9a6bb459
| |\ branch: V3
| | | tag: 3.1
| | | parent: 7:5354c406c68a
| | | parent: 8:00dfa7869e8c
| | | user: steve.kaye
| | | date: Tue Jun 26 08:35:20 2012 +0100
| | | summary: Merge bug fix
| | |
| | | o changeset: 10:a84c532ce507
| | |/ branch: V2
| | | parent: 8:00dfa7869e8c
| | | user: steve.kaye
| | | date: Tue Jun 26 08:31:09 2012 +0100
| | | summary: Added tag 2.1 for changeset 00dfa7869e8c
| | |
o | | changeset: 9:5953138c3f87
| | | parent: 5:80b80eb9581b
| | | user: steve.kaye
| | | date: Tue Jun 26 08:30:41 2012 +0100
| | | summary: Start work on next version
| | |
| | o changeset: 8:00dfa7869e8c
| | | branch: V2
| | | tag: 2.1
| | | parent: 4:6c4a68f3c073
| | | user: steve.kaye
| | | date: Tue Jun 26 08:29:56 2012 +0100
| | | summary: Fixed a bug in V2
| | |
| o | changeset: 7:5354c406c68a
| | | branch: V3
| | | user: steve.kaye
| | | date: Tue Jun 26 08:24:52 2012 +0100
| | | summary: Added tag 3.0 for changeset 3f3a006aacdd
| | |
| o | changeset: 6:3f3a006aacdd
|/ / branch: V3
| | tag: 3.0
| | user: steve.kaye
| | date: Tue Jun 26 08:23:54 2012 +0100
| | summary: Version 3.0 ready for release
| |
o | changeset: 5:80b80eb9581b
| | parent: 2:21cf96f3ed91
| | user: steve.kaye
| | date: Tue Jun 26 08:22:47 2012 +0100
| | summary: Start work on next version
| |
| o changeset: 4:6c4a68f3c073
| | branch: V2
| | user: steve.kaye
| | date: Tue Jun 26 08:20:07 2012 +0100
| | summary: Added tag 2.0 for changeset 666cc4453281
| |
| o changeset: 3:666cc4453281
|/ branch: V2
| tag: 2.0
| user: steve.kaye
| date: Tue Jun 26 08:19:43 2012 +0100
| summary: Version 2.0 ready for release
|
o changeset: 2:21cf96f3ed91
| user: steve.kaye
| date: Tue Jun 26 08:18:31 2012 +0100
| summary: More work on the new version
|
o changeset: 1:6177b193da7c
| user: steve.kaye
| date: Tue Jun 26 08:18:06 2012 +0100
| summary: Start work on version 2.0
|
o changeset: 0:51cc3c0590f9
user: steve.kaye
date: Tue Jun 26 08:17:27 2012 +0100
summary: Initial commit
As you can see, I have three branches. default is where the new development was done then I decided that it was ready for release so I created a V2 branch and tagged it 2.0. I then continued work on default until I decided that it was ready for release when I branched to V3 and tagged it as 3.0. I then discovered a bug and found that it was introduced in version 2 so I fixed it on the V2 branch and tagged it 2.1. I then merged that fix into V3 and tagged it 3.1 and then merged V3 to default to get the fix in the development code.
It is easier to port the fixes between branches if you start in the oldest version. This allows you to merge that fix to the newer branches more easily. If you were to fix it in default first, you couldn't merge that fix to V2 or V3 because you'd get all the new features in the older versions as well as the bug fix.
Notice that you still have as many heads as the other branching strategy - one default one for V2 and one for V3 but they will be arranged more neatly if you are maintaining multiple releases. To get the latest release of version 2 of your software you just need to do hg up V2 whereas before you'd need to find out what the latest version 2 is and then update to that.

The second paragraph of your linked question says:
Once you're done with 2.0, merge 2.0-dev into default and tag the result as 2.0.
From this, I think that the idea is that you wouldn't tag 3.0 until you are ready to release it. If you have released it, then the fix for 2.1.1 wouldn't go into 3.0, it would go into 3.0.1 and you wouldn't have a problem with your workflow.
Also, you can move tags so if you do find that you tagged 3.0 too early you can move it using the -f flag to hg tag.