vanessa-behavior 0.4.4
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +7 -0
- data/CONTRIBUTORS.md +4 -0
- data/LICENSE +202 -0
- data/README.md +101 -0
- data/ROADMAP.md +18 -0
- data/bin/keep.me +0 -0
- data/bin/vanessa-behavior.exe +0 -0
- data/config/cucumber.yml +7 -0
- data/features/EpfBehavePleer.feature +5 -0
- data/features/step_definitions/ones_remote_tests.wire +2 -0
- data/features/step_definitions/wire_protocol.epf +0 -0
- data/features/support/env.rb +1 -0
- data/features/wire_protocol.feature +337 -0
- data/lib/TemplateEpf/Temp/ObjectModule_ExampleAccounting.txt +0 -0
- data/lib/TemplateEpf/Temp/ObjectModule_example-accounting.txt +0 -0
- data/lib/TemplateEpf/Temp/ObjectModule_wire_protocol.txt +0 -0
- data/lib/TemplateEpf/Temp/keep.me +0 -0
- data/lib/TemplateEpf/renames.txt +7 -0
- data/lib/TemplateEpf/und/79a499cc-1782-4a2f-abe7-61ea4d49fd5a +37 -0
- data/lib/TemplateEpf/und/7a39ab7a-5023-41fd-ae4c-8d0e903c5cba.0/info +1 -0
- data/lib/TemplateEpf/und/8aa13ab8-188a-4f59-be4f-031aa5450c90.0/info +1 -0
- data/lib/TemplateEpf/und/copyinfo +7 -0
- data/lib/TemplateEpf/und/d4666efc-32c5-4cbe-a642-505988996654 +17 -0
- data/lib/TemplateEpf/und/root +1 -0
- data/lib/TemplateEpf/und/version +3 -0
- data/lib/TemplateEpf/und/versions +1 -0
- data/lib/UnpackV8.exe +0 -0
- data/tasks/developers.start.cmd +13 -0
- data/vanessa-behavior.os +1278 -0
- data/vendor/precommit1c/README.md +89 -0
- data/vendor/precommit1c/copy-to-hook.cmd +11 -0
- data/vendor/precommit1c/ibService/1Cv8.1CD +0 -0
- data/vendor/precommit1c/pre-commit +4 -0
- data/vendor/precommit1c/precommit1c.ini.example +3 -0
- data/vendor/precommit1c/pyv8unpack.py +370 -0
- data/vendor/precommit1c/tests/Fixture.epf +0 -0
- data/vendor/precommit1c/tests/TestFixture.cmd +13 -0
- data/vendor/precommit1c/tests/test_compile.py +113 -0
- data/vendor/precommit1c/v8Reader/LICENSE +202 -0
- data/vendor/precommit1c/v8Reader/README.md +35 -0
- data/vendor/precommit1c/v8Reader/V8Reader.epf +0 -0
- metadata +114 -0
@@ -0,0 +1,337 @@
|
|
1
|
+
@[ИмяФичи]=wire_protocol;\features
|
2
|
+
|
3
|
+
|
4
|
+
Feature: Wire Protocol
|
5
|
+
In order to be allow Cucumber to touch my app in intimate places
|
6
|
+
As a developer on platform which doesn't support Ruby
|
7
|
+
I want a low-level protocol which Cucumber can use to run steps within my app
|
8
|
+
|
9
|
+
#
|
10
|
+
# Cucumber's wire protocol is an implementation of Cucumber's internal
|
11
|
+
# 'programming language' abstraction, and allows step definitions to be
|
12
|
+
# implemented and invoked on any platform.
|
13
|
+
#
|
14
|
+
# Communication is over a TCP socket, which Cucumber connects to when it finds
|
15
|
+
# a definition file with the .wire extension in the step_definitions folder
|
16
|
+
# (or other load path). Note that these files are rendered with ERB when loaded.
|
17
|
+
#
|
18
|
+
# Cucumber sends the following request messages out over the wire:
|
19
|
+
#
|
20
|
+
# * step_matches : this is used to find out whether the wire server has a
|
21
|
+
# definition for a given step
|
22
|
+
# * invoke : this is used to ask for a step definition to be invoked
|
23
|
+
# * begin_scenario : signals that cucumber is about to execute a scenario
|
24
|
+
# * end_scenario : signals that cucumber has finished executing a scenario
|
25
|
+
# * snippet_text : requests a snippet for an undefined step
|
26
|
+
#
|
27
|
+
# Every message supports two standard responses:
|
28
|
+
# * success : which expects different arguments (sometimes none at
|
29
|
+
# all) depending on the request.
|
30
|
+
# * fail : causes a Cucumber::WireSupport::WireException to be
|
31
|
+
# raised.
|
32
|
+
#
|
33
|
+
# Some messages support more responses - see below for details.
|
34
|
+
#
|
35
|
+
# A WirePacket flowing in either direction is formatted as a JSON-encoded
|
36
|
+
# string, with a newline character signaling the end of a packet. See the
|
37
|
+
# specs for Cucumber::WireSupport::WirePacket for more details.
|
38
|
+
#
|
39
|
+
# These messages are described in detail below, with examples.
|
40
|
+
#
|
41
|
+
|
42
|
+
Background:
|
43
|
+
Given a file named 'features/wired.feature' with:
|
44
|
+
"""
|
45
|
+
Feature: High strung
|
46
|
+
Scenario: Wired
|
47
|
+
Given we're all wired
|
48
|
+
|
49
|
+
"""
|
50
|
+
And a file named 'features/step_definitions/some_remote_place.wire' with:
|
51
|
+
"""
|
52
|
+
host: localhost
|
53
|
+
port: 54321
|
54
|
+
|
55
|
+
"""
|
56
|
+
|
57
|
+
|
58
|
+
#
|
59
|
+
# # Request: 'step_matches'
|
60
|
+
#
|
61
|
+
# When the features have been parsed, Cucumber will send a step_matches
|
62
|
+
# message to ask the wire server if it can match a step name. This happens for
|
63
|
+
# each of the steps in each of the features.
|
64
|
+
#
|
65
|
+
# The wire server replies with an array of StepMatch objects.
|
66
|
+
|
67
|
+
Scenario: Dry run finds no step match
|
68
|
+
Given there is a wire server running on port 54321 which understands the following protocol:
|
69
|
+
| request | response |
|
70
|
+
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[]] |
|
71
|
+
When I run 'cucumber --dry-run --no-snippets -f progress'
|
72
|
+
And it should pass with:
|
73
|
+
"""
|
74
|
+
U
|
75
|
+
|
76
|
+
1 scenario (1 undefined)
|
77
|
+
1 step (1 undefined)
|
78
|
+
|
79
|
+
"""
|
80
|
+
|
81
|
+
# When each StepMatch is returned, it contains the following data:
|
82
|
+
# * id - identifier for the step definition to be used later when if it
|
83
|
+
# needs to be invoked. The identifier can be any string value and
|
84
|
+
# is simply used for the wire server's own reference.
|
85
|
+
# * args - any argument values as captured by the wire end's own regular
|
86
|
+
# expression (or other argument matching) process.
|
87
|
+
Scenario: Dry run finds a step match
|
88
|
+
Given there is a wire server running on port 54321 which understands the following protocol:
|
89
|
+
| request | response |
|
90
|
+
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[{"id":"1", "args":[]}]] |
|
91
|
+
When I run 'cucumber --dry-run -f progress'
|
92
|
+
And it should pass with:
|
93
|
+
"""
|
94
|
+
-
|
95
|
+
|
96
|
+
1 scenario (1 skipped)
|
97
|
+
1 step (1 skipped)
|
98
|
+
|
99
|
+
"""
|
100
|
+
|
101
|
+
# Optionally, the StepMatch can also contain a source reference, and a native
|
102
|
+
# regexp string which will be used by some formatters.
|
103
|
+
Scenario: Step matches returns details about the remote step definition
|
104
|
+
Given there is a wire server running on port 54321 which understands the following protocol:
|
105
|
+
| request | response |
|
106
|
+
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[{"id":"1", "args":[], "source":"MyApp.MyClass:123", "regexp":"we.*"}]] |
|
107
|
+
When I run 'cucumber -f stepdefs --dry-run'
|
108
|
+
Then it should pass with:
|
109
|
+
"""
|
110
|
+
-
|
111
|
+
|
112
|
+
we.* # MyApp.MyClass:123
|
113
|
+
|
114
|
+
1 scenario (1 skipped)
|
115
|
+
1 step (1 skipped)
|
116
|
+
|
117
|
+
"""
|
118
|
+
And the stderr should not contain anything
|
119
|
+
|
120
|
+
|
121
|
+
#
|
122
|
+
# # Request: 'invoke'
|
123
|
+
#
|
124
|
+
# Assuming a StepMatch was returned for a given step name, when it's time to
|
125
|
+
# invoke that step definition, Cucumber will send an invoke message.
|
126
|
+
#
|
127
|
+
# The invoke message contains the ID of the step definition, as returned by
|
128
|
+
# the wire server in response to the the step_matches call, along with the
|
129
|
+
# arguments that were parsed from the step name during the same step_matches
|
130
|
+
# call.
|
131
|
+
#
|
132
|
+
# The wire server will normally[1] reply one of the following:
|
133
|
+
# * success
|
134
|
+
# * fail
|
135
|
+
# * pending : optionally takes a message argument
|
136
|
+
#
|
137
|
+
# [1] This isn't the whole story: see also wire_protocol_table_diffing.feature
|
138
|
+
#
|
139
|
+
|
140
|
+
# ## Pending Steps
|
141
|
+
#
|
142
|
+
Scenario: Invoke a step definition which is pending
|
143
|
+
Given there is a wire server running on port 54321 which understands the following protocol:
|
144
|
+
| request | response |
|
145
|
+
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[{"id":"1", "args":[]}]] |
|
146
|
+
| ["begin_scenario"] | ["success"] |
|
147
|
+
| ["invoke",{"id":"1","args":[]}] | ["pending", "I'll do it later"] |
|
148
|
+
| ["end_scenario"] | ["success"] |
|
149
|
+
When I run 'cucumber -f pretty -q'
|
150
|
+
And it should pass with:
|
151
|
+
"""
|
152
|
+
Feature: High strung
|
153
|
+
|
154
|
+
Scenario: Wired
|
155
|
+
Given we're all wired
|
156
|
+
I'll do it later (Cucumber::Pending)
|
157
|
+
features/wired.feature:3:in 'Given we're all wired'
|
158
|
+
|
159
|
+
1 scenario (1 pending)
|
160
|
+
1 step (1 pending)
|
161
|
+
|
162
|
+
"""
|
163
|
+
|
164
|
+
# ## Passing Steps
|
165
|
+
#
|
166
|
+
Scenario: Invoke a step definition which passes
|
167
|
+
Given there is a wire server running on port 54321 which understands the following protocol:
|
168
|
+
| request | response |
|
169
|
+
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[{"id":"1", "args":[]}]] |
|
170
|
+
| ["begin_scenario"] | ["success"] |
|
171
|
+
| ["invoke",{"id":"1","args":[]}] | ["success"] |
|
172
|
+
| ["end_scenario"] | ["success"] |
|
173
|
+
When I run 'cucumber -f progress'
|
174
|
+
And it should pass with:
|
175
|
+
"""
|
176
|
+
.
|
177
|
+
|
178
|
+
1 scenario (1 passed)
|
179
|
+
1 step (1 passed)
|
180
|
+
|
181
|
+
"""
|
182
|
+
|
183
|
+
# ## Failing Steps
|
184
|
+
#
|
185
|
+
# When an invoked step definition fails, it can return details of the exception
|
186
|
+
# in the reply to invoke. This causes a Cucumber::WireSupport::WireException to be
|
187
|
+
# raised.
|
188
|
+
#
|
189
|
+
# Valid arguments are:
|
190
|
+
# * message (mandatory)
|
191
|
+
# * exception
|
192
|
+
# * backtrace
|
193
|
+
#
|
194
|
+
# See the specs for Cucumber::WireSupport::WireException for more details
|
195
|
+
#
|
196
|
+
Scenario: Invoke a step definition which fails
|
197
|
+
Given there is a wire server running on port 54321 which understands the following protocol:
|
198
|
+
| request | response |
|
199
|
+
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[{"id":"1", "args":[]}]] |
|
200
|
+
| ["begin_scenario"] | ["success"] |
|
201
|
+
| ["invoke",{"id":"1","args":[]}] | ["fail",{"message":"The wires are down", "exception":"Some.Foreign.ExceptionType"}] |
|
202
|
+
| ["end_scenario"] | ["success"] |
|
203
|
+
When I run 'cucumber -f progress'
|
204
|
+
Then the stderr should not contain anything
|
205
|
+
And it should fail with:
|
206
|
+
"""
|
207
|
+
F
|
208
|
+
|
209
|
+
(::) failed steps (::)
|
210
|
+
|
211
|
+
The wires are down (Some.Foreign.ExceptionType from localhost:54321)
|
212
|
+
features/wired.feature:3:in 'Given we're all wired'
|
213
|
+
|
214
|
+
Failing Scenarios:
|
215
|
+
cucumber features/wired.feature:2 # Scenario: Wired
|
216
|
+
|
217
|
+
1 scenario (1 failed)
|
218
|
+
1 step (1 failed)
|
219
|
+
|
220
|
+
"""
|
221
|
+
|
222
|
+
# ## Step Arguments
|
223
|
+
#
|
224
|
+
# Imagine we have a step definition like:
|
225
|
+
#
|
226
|
+
# Given /we're all (.*)/ do | what_we_are |
|
227
|
+
# end
|
228
|
+
#
|
229
|
+
# When this step definition matches the step name in our feature, the word
|
230
|
+
# 'wired' will be captured as an argument.
|
231
|
+
#
|
232
|
+
# Cucumber expects this StepArgument to be returned in the StepMatch. The keys
|
233
|
+
# have the following meanings:
|
234
|
+
# * val : the value of the string captured for that argument from the step
|
235
|
+
# name passed in step_matches
|
236
|
+
# * pos : the position within the step name that the argument was matched
|
237
|
+
# (used for formatter highlighting)
|
238
|
+
#
|
239
|
+
Scenario: Invoke a step definition which takes string arguments (and passes)
|
240
|
+
Given there is a wire server running on port 54321 which understands the following protocol:
|
241
|
+
| request | response |
|
242
|
+
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[{"id":"1", "args":[{"val":"wired", "pos":10}]}]] |
|
243
|
+
| ["begin_scenario"] | ["success"] |
|
244
|
+
| ["invoke",{"id":"1","args":["wired"]}] | ["success"] |
|
245
|
+
| ["end_scenario"] | ["success"] |
|
246
|
+
When I run 'cucumber -f progress'
|
247
|
+
Then the stderr should not contain anything
|
248
|
+
And it should pass with:
|
249
|
+
"""
|
250
|
+
.
|
251
|
+
|
252
|
+
1 scenario (1 passed)
|
253
|
+
1 step (1 passed)
|
254
|
+
|
255
|
+
"""
|
256
|
+
|
257
|
+
# ## Multiline Table Arguments
|
258
|
+
#
|
259
|
+
# When the step has a multiline table argument, it will be passed with the
|
260
|
+
# invoke message as a string - a serialized JSON array of array of strings.
|
261
|
+
# In the following scenario our step definition takes two arguments - one
|
262
|
+
# captures the "we're" and the other takes the table.
|
263
|
+
Scenario: Invoke a step definition which takes table arguments (and passes)
|
264
|
+
Given a file named 'features/wired_on_tables.feature' with:
|
265
|
+
"""
|
266
|
+
Feature: High strung
|
267
|
+
Scenario: Wired and more
|
268
|
+
Given we're all:
|
269
|
+
| wired |
|
270
|
+
| high |
|
271
|
+
| happy |
|
272
|
+
"""
|
273
|
+
And there is a wire server running on port 54321 which understands the following protocol:
|
274
|
+
| request | response |
|
275
|
+
| ["step_matches",{"name_to_match":"we're all:"}] | ["success",[{"id":"1", "args":[{"val":"we're", "pos":0}]}]] |
|
276
|
+
| ["begin_scenario"] | ["success"] |
|
277
|
+
| ["invoke",{"id":"1","args":["we're",[["wired"],["high"],["happy"]]]}] | ["success"] |
|
278
|
+
| ["end_scenario"] | ["success"] |
|
279
|
+
When I run 'cucumber -f progress features/wired_on_tables.feature'
|
280
|
+
Then the stderr should not contain anything
|
281
|
+
And it should pass with:
|
282
|
+
"""
|
283
|
+
.
|
284
|
+
|
285
|
+
1 scenario (1 passed)
|
286
|
+
1 step (1 passed)
|
287
|
+
|
288
|
+
"""
|
289
|
+
|
290
|
+
|
291
|
+
#
|
292
|
+
# # Request: 'snippets'
|
293
|
+
#
|
294
|
+
Scenario: Wire server returns snippets for a step that didn't match
|
295
|
+
Given there is a wire server running on port 54321 which understands the following protocol:
|
296
|
+
| request | response |
|
297
|
+
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[]] |
|
298
|
+
| ["snippet_text",{"step_keyword":"Given","multiline_arg_class":"","step_name":"we're all wired"}] | ["success","foo()\n bar;\nbaz"] |
|
299
|
+
| ["begin_scenario"] | ["success"] |
|
300
|
+
| ["end_scenario"] | ["success"] |
|
301
|
+
When I run 'cucumber -f pretty'
|
302
|
+
Then the stderr should not contain anything
|
303
|
+
And it should pass with:
|
304
|
+
"""
|
305
|
+
Feature: High strung
|
306
|
+
|
307
|
+
Scenario: Wired # features/wired.feature:2
|
308
|
+
Given we're all wired # features/wired.feature:3
|
309
|
+
|
310
|
+
1 scenario (1 undefined)
|
311
|
+
1 step (1 undefined)
|
312
|
+
"""
|
313
|
+
And the output should contain:
|
314
|
+
"""
|
315
|
+
|
316
|
+
You can implement step definitions for undefined steps with these snippets:
|
317
|
+
|
318
|
+
foo()
|
319
|
+
bar;
|
320
|
+
baz
|
321
|
+
|
322
|
+
"""
|
323
|
+
|
324
|
+
#
|
325
|
+
# # Bad Response
|
326
|
+
#
|
327
|
+
Scenario: Unexpected response
|
328
|
+
Given there is a wire server running on port 54321 which understands the following protocol:
|
329
|
+
| request | response |
|
330
|
+
| ["begin_scenario"] | ["yikes"] |
|
331
|
+
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[{"id":"1", "args":[]}]] |
|
332
|
+
When I run 'cucumber -f pretty'
|
333
|
+
Then the stdout should contain:
|
334
|
+
"""
|
335
|
+
undefined method 'handle_yikes'
|
336
|
+
"""
|
337
|
+
|
File without changes
|
File without changes
|
File without changes
|
File without changes
|
@@ -0,0 +1,7 @@
|
|
1
|
+
79a499cc-1782-4a2f-abe7-61ea4d49fd5a-->und\79a499cc-1782-4a2f-abe7-61ea4d49fd5a
|
2
|
+
8aa13ab8-188a-4f59-be4f-031aa5450c90.0\info-->und\8aa13ab8-188a-4f59-be4f-031aa5450c90.0\info
|
3
|
+
8aa13ab8-188a-4f59-be4f-031aa5450c90.0\text-->ObjectModule.txt
|
4
|
+
copyinfo-->und\copyinfo
|
5
|
+
root-->und\root
|
6
|
+
version-->und\version
|
7
|
+
versions-->und\versions
|
@@ -0,0 +1,37 @@
|
|
1
|
+
{1,
|
2
|
+
{79a499cc-1782-4a2f-abe7-61ea4d49fd5a},1,
|
3
|
+
{c3831ec8-d8d5-4f93-8a22-f9bfae07327f,
|
4
|
+
{1,
|
5
|
+
{4,1fa267af-3d54-4f70-ac00-718486d7aafd,ed829681-4496-44fd-adeb-667f09d931c3,
|
6
|
+
{0,
|
7
|
+
{0,
|
8
|
+
{0,0,8aa13ab8-188a-4f59-be4f-031aa5450c90},"TemplateEpf",
|
9
|
+
{1,"ru","Template epf"},""}
|
10
|
+
},00000000-0000-0000-0000-000000000000,"",00000000-0000-0000-0000-000000000000},4,
|
11
|
+
{2bcef0d1-0981-11d6-b9b8-0050bae0a95d,0},
|
12
|
+
{3daea016-69b7-4ed4-9453-127911372fe6,0},
|
13
|
+
{d5b0e5ed-256d-401c-9c36-f630cafd8a62,0},
|
14
|
+
{ec6bb5e5-b7a8-4d75-bec9-658107a699cf,1,
|
15
|
+
{
|
16
|
+
{0,
|
17
|
+
{25,
|
18
|
+
{2,
|
19
|
+
{0,
|
20
|
+
{0,0,03f1a2cc-5646-4a21-a16d-f6863c782a20},"Контекст",
|
21
|
+
{1,"ru","Контекст"},""},
|
22
|
+
{"Pattern"}
|
23
|
+
},0,
|
24
|
+
{0},
|
25
|
+
{0},0,"",0,
|
26
|
+
{"U"},
|
27
|
+
{"U"},0,00000000-0000-0000-0000-000000000000,2,0,
|
28
|
+
{5004,0},
|
29
|
+
{3,0,0},
|
30
|
+
{0,0},0,
|
31
|
+
{0},
|
32
|
+
{"S",""},0}
|
33
|
+
},0}
|
34
|
+
}
|
35
|
+
}
|
36
|
+
}
|
37
|
+
}
|
@@ -0,0 +1 @@
|
|
1
|
+
{3,1,0,"",0}
|
@@ -0,0 +1 @@
|
|
1
|
+
{3,1,0,"",0}
|
@@ -0,0 +1,17 @@
|
|
1
|
+
{1,
|
2
|
+
{d4666efc-32c5-4cbe-a642-505988996654},1,
|
3
|
+
{c3831ec8-d8d5-4f93-8a22-f9bfae07327f,
|
4
|
+
{1,
|
5
|
+
{4,5bf81622-16aa-4645-a1d8-509874887e57,f517432b-a7f6-4263-93df-fe0fdadf5791,
|
6
|
+
{0,
|
7
|
+
{0,
|
8
|
+
{0,0,7a39ab7a-5023-41fd-ae4c-8d0e903c5cba},"TemplateEpf",
|
9
|
+
{1,"ru","TemplateEpf"},""}
|
10
|
+
},00000000-0000-0000-0000-000000000000,"",00000000-0000-0000-0000-000000000000},4,
|
11
|
+
{2bcef0d1-0981-11d6-b9b8-0050bae0a95d,0},
|
12
|
+
{3daea016-69b7-4ed4-9453-127911372fe6,0},
|
13
|
+
{d5b0e5ed-256d-401c-9c36-f630cafd8a62,0},
|
14
|
+
{ec6bb5e5-b7a8-4d75-bec9-658107a699cf,0}
|
15
|
+
}
|
16
|
+
}
|
17
|
+
}
|
@@ -0,0 +1 @@
|
|
1
|
+
{2,79a499cc-1782-4a2f-abe7-61ea4d49fd5a,}
|
@@ -0,0 +1 @@
|
|
1
|
+
{1,7,"",957ec74c-a1dc-4a1f-a270-c36c0f9f4a04,"8aa13ab8-188a-4f59-be4f-031aa5450c90.0",19f79066-4b2c-4d0d-831e-732c45f6209a,"root",2c064e3e-498c-4a6a-849b-b6d3887cbc3f,"79a499cc-1782-4a2f-abe7-61ea4d49fd5a",2b64eb12-7485-488d-8ba0-80b8dc3a912e,"copyinfo",9d1835f3-6ec1-4d6d-ae08-4115907229fc,"versions",c2df9ea6-94a4-40de-88ee-0063bfcff47d,"version",9fb14ed9-b9b2-4b46-bd4b-8ec1ec984ab1}
|
data/lib/UnpackV8.exe
ADDED
Binary file
|
@@ -0,0 +1,13 @@
|
|
1
|
+
@echo off
|
2
|
+
|
3
|
+
@echo sync and update precommit1c hook
|
4
|
+
|
5
|
+
cd .\..\vendor\precommit1c\
|
6
|
+
|
7
|
+
xcopy .\ibService .\..\..\.git\hooks\ibService\ /Y /E /F
|
8
|
+
xcopy .\pre-commit .\..\..\.git\hooks\ /Y /F
|
9
|
+
xcopy .\v8Reader .\..\..\.git\hooks\v8Reader\ /Y /F
|
10
|
+
xcopy .\pyv8unpack.py .\..\..\.git\hooks\ /Y /F
|
11
|
+
|
12
|
+
cd .\..\..\
|
13
|
+
git config --local core.quotepath false
|