Patchwork [1,of,2] test-chg: run only with chg

login
register
mail settings
Submitter Yuya Nishihara
Date May 29, 2016, 1:40 p.m.
Message ID <f4d797228ecddcebfe86.1464529252@mimosa>
Download mbox | patch
Permalink /patch/15238/
State Accepted
Headers show

Comments

Yuya Nishihara - May 29, 2016, 1:40 p.m.
# HG changeset patch
# User Yuya Nishihara <yuya@tcha.org>
# Date 1458511143 25200
#      Sun Mar 20 14:59:03 2016 -0700
# Node ID f4d797228ecddcebfe86a9f726cdd55df49ef874
# Parent  9da137faaa9c9593f821923189316e7fcb38cf67
test-chg: run only with chg

It doesn't make sense to run test-chg.t without chg, so ignore it with vanilla
hg, and specify chg executable explicitly.

test-chg.t can host chg-specific tests.
Pierre-Yves David - June 6, 2016, 5:04 a.m.
On 05/29/2016 03:40 PM, Yuya Nishihara wrote:
> # HG changeset patch
> # User Yuya Nishihara <yuya@tcha.org>
> # Date 1458511143 25200
> #      Sun Mar 20 14:59:03 2016 -0700
> # Node ID f4d797228ecddcebfe86a9f726cdd55df49ef874
> # Parent  9da137faaa9c9593f821923189316e7fcb38cf67
> test-chg: run only with chg
> 
> It doesn't make sense to run test-chg.t without chg, so ignore it with vanilla
> hg, and specify chg executable explicitly.
> 
> test-chg.t can host chg-specific tests.

I'm still a bit puzzle by the mechanism here. In my opinion it would
make sense to test if chg works in all case, that way if someone
introduce something that break the basic chg principle we would detect
it in all cases.

Having this running only if --chg is specify defeat this principle. Are
we building (and making available) chg in all case? or only when we use it?
Yuya Nishihara - June 6, 2016, 2:22 p.m.
On Mon, 6 Jun 2016 07:04:14 +0200, Pierre-Yves David wrote:
> On 05/29/2016 03:40 PM, Yuya Nishihara wrote:
> > # HG changeset patch
> > # User Yuya Nishihara <yuya@tcha.org>
> > # Date 1458511143 25200
> > #      Sun Mar 20 14:59:03 2016 -0700
> > # Node ID f4d797228ecddcebfe86a9f726cdd55df49ef874
> > # Parent  9da137faaa9c9593f821923189316e7fcb38cf67
> > test-chg: run only with chg
> > 
> > It doesn't make sense to run test-chg.t without chg, so ignore it with vanilla
> > hg, and specify chg executable explicitly.
> > 
> > test-chg.t can host chg-specific tests.  
> 
> I'm still a bit puzzle by the mechanism here. In my opinion it would
> make sense to test if chg works in all case, that way if someone
> introduce something that break the basic chg principle we would detect
> it in all cases.
>
> Having this running only if --chg is specify defeat this principle. Are
> we building (and making available) chg in all case? or only when we use it?

chg is built and its setup/cleanup processes are run only when --chg/--with-chg
specified. We could change that, but it will require more work. Also, I don't
think running test-chg.t is enough to say nothing broken.
Jun Wu - June 6, 2016, 4:24 p.m.
We have 3 kinds of tests:

1. Common tests: Tests can be run by either chg or hg. The majority of
   tests are "common tests".
2. hg-only tests. Tests not supported by chg. For example, tests checking
   backtraces.
3. chg-only tests. This is test-chg.t. Tests are specially designed to check
   some chg-only behaviors. They do not make much sense for normal hg.

chg needs to run 1 and 3. hg needs to run 1 and 2.

Hope I have made things a bit clearer.

Excerpts from Pierre-Yves David's message of 2016-06-06 07:04:14 +0200:
> I'm still a bit puzzle by the mechanism here. In my opinion it would
> make sense to test if chg works in all case, that way if someone
> introduce something that break the basic chg principle we would detect
> it in all cases.
> 
> Having this running only if --chg is specify defeat this principle. Are
> we building (and making available) chg in all case? or only when we use it?
Jun Wu - June 7, 2016, 6:44 p.m.
Excerpts from Pierre-Yves David's message of 2016-06-07 20:48:24 +0200:
> Thanks for the clarification, I think it would be a good goal to have
> chg available and tested in all cases. Sure it would only test the
> basis, but that seems important enough to have a short feedback loop here.
> 
> Cheers,
 
Yeah. I'd love to do that too. The hgsubversion stuff is taking much
longer than I expected and I spent some time on the fastannotate
stuff internally. I will try to get some chg patches this week.
Pierre-Yves David - June 7, 2016, 6:48 p.m.
On 06/06/2016 04:22 PM, Yuya Nishihara wrote:
> On Mon, 6 Jun 2016 07:04:14 +0200, Pierre-Yves David wrote:
>> On 05/29/2016 03:40 PM, Yuya Nishihara wrote:
>>> # HG changeset patch
>>> # User Yuya Nishihara <yuya@tcha.org>
>>> # Date 1458511143 25200
>>> #      Sun Mar 20 14:59:03 2016 -0700
>>> # Node ID f4d797228ecddcebfe86a9f726cdd55df49ef874
>>> # Parent  9da137faaa9c9593f821923189316e7fcb38cf67
>>> test-chg: run only with chg
>>>
>>> It doesn't make sense to run test-chg.t without chg, so ignore it with vanilla
>>> hg, and specify chg executable explicitly.
>>>
>>> test-chg.t can host chg-specific tests.  
>>
>> I'm still a bit puzzle by the mechanism here. In my opinion it would
>> make sense to test if chg works in all case, that way if someone
>> introduce something that break the basic chg principle we would detect
>> it in all cases.
>>
>> Having this running only if --chg is specify defeat this principle. Are
>> we building (and making available) chg in all case? or only when we use it?
> 
> chg is built and its setup/cleanup processes are run only when --chg/--with-chg
> specified. We could change that, but it will require more work. Also, I don't
> think running test-chg.t is enough to say nothing broken.

Thanks for the clarification, I think it would be a good goal to have
chg available and tested in all cases. Sure it would only test the
basis, but that seems important enough to have a short feedback loop here.

Cheers,
Pierre-Yves David - June 7, 2016, 7 p.m.
On 06/07/2016 08:44 PM, Jun Wu wrote:
> Excerpts from Pierre-Yves David's message of 2016-06-07 20:48:24 +0200:
>> Thanks for the clarification, I think it would be a good goal to have
>> chg available and tested in all cases. Sure it would only test the
>> basis, but that seems important enough to have a short feedback loop here.
>>
>> Cheers,
>  
> Yeah. I'd love to do that too. The hgsubversion stuff is taking much
> longer than I expected and I spent some time on the fastannotate
> stuff internally. I will try to get some chg patches this week.

No pressure, the goal of this thread was to have an idea of what
direction we want to aim at.

Patch

diff --git a/tests/test-chg.t b/tests/test-chg.t
--- a/tests/test-chg.t
+++ b/tests/test-chg.t
@@ -1,13 +1,15 @@ 
+#require chg
+
 init repo
 
-  $ hg init foo
+  $ chg init foo
   $ cd foo
 
 ill-formed config
 
-  $ hg status
+  $ chg status
   $ echo '=brokenconfig' >> $HGRCPATH
-  $ hg status
+  $ chg status
   hg: parse error at * (glob)
   [255]
 
@@ -26,7 +28,7 @@  alias having an environment variable and
   > printa = log -T "$A\n" -r 0
   > EOF
 
-  $ A=1 hg printa
+  $ A=1 chg printa
   P1
-  $ A=2 hg printa
+  $ A=2 chg printa
   P2