##// END OF EJS Templates
merge: don't try to merge subrepos twice (issue4988)...
merge: don't try to merge subrepos twice (issue4988) In my patch series ending with rev 25e4b2f000c5 I switched most change/delete conflicts to be handled at the resolve layer. .hgsubstate was the one file that we weren't able to handle, so we kept the old code path around for it. The old code path added .hgsubstate to one of the other lists as the user specifies, including possibly the 'g' list. Now since we did this check after converting the actions from being keyed by file to being keyed by action type, there was nothing that actually removed .hgsubstate from the 'cd' or 'dc' lists. This meant that the file would eventually make its way into the 'mergeactions' list, now freshly augmented with 'cd' and 'dc' actions. We call subrepo.submerge for both 'g' actions and merge actions. This means that if the resolution to an .hgsubstate change/delete conflict was to add it to the 'g' list, subrepo.submerge would be called twice. It turns out that this doesn't cause any adverse effects on Linux due to caching, but apparently breaks on other operating systems including Windows. The fix here moves this to before we convert the actions over. This ensures that it .hgsubstate doesn't make its way into multiple lists. The real fix here is going to be: (1) move .hgsubstate conflict resolution into the resolve layer, and (2) use a real data structure for the actions rather than shuffling data around between lists and dictionaries: we need a hash (or prefix-based) index by file and a list index by action type. There's a very tiny behavior change here: collision detection on case-insensitive systems will happen after this is resolved, not before. I think this is the right change -- .hgsubstate could theoretically collide with other files -- but in any case it makes no practical difference. Thanks to Yuya Nishihara for investigating this.

File last commit:

r22575:d7f7f186 default
r27951:6bce6d92 stable
Show More
dummycert.pem
56 lines | 2.2 KiB | application/pgp-keys | AscLexer
A dummy certificate that will make OS X 10.6+ Python use the system CA
certificate store:
-----BEGIN CERTIFICATE-----
MIIBIzCBzgIJANjmj39sb3FmMA0GCSqGSIb3DQEBBQUAMBkxFzAVBgNVBAMTDmhn
LmV4YW1wbGUuY29tMB4XDTE0MDgzMDA4NDU1OVoXDTE0MDgyOTA4NDU1OVowGTEX
MBUGA1UEAxMOaGcuZXhhbXBsZS5jb20wXDANBgkqhkiG9w0BAQEFAANLADBIAkEA
mh/ZySGlcq0ALNLmA1gZqt61HruywPrRk6WyrLJRgt+X7OP9FFlEfl2tzHfzqvmK
CtSQoPINWOdAJMekBYFgKQIDAQABMA0GCSqGSIb3DQEBBQUAA0EAF9h49LkSqJ6a
IlpogZuUHtihXeKZBsiktVIDlDccYsNy0RSh9XxUfhk+XMLw8jBlYvcltSXdJ7We
aKdQRekuMQ==
-----END CERTIFICATE-----
This certificate was generated to be syntactically valid but never be usable;
it expired before it became valid.
Created as:
$ cat > cn.conf << EOT
> [req]
> distinguished_name = req_distinguished_name
> [req_distinguished_name]
> commonName = Common Name
> commonName_default = no.example.com
> EOT
$ openssl req -nodes -new -x509 -keyout /dev/null \
> -out dummycert.pem -days -1 -config cn.conf -subj '/CN=hg.example.com'
To verify the content of this certificate:
$ openssl x509 -in dummycert.pem -noout -text
Certificate:
Data:
Version: 1 (0x0)
Serial Number: 15629337334278746470 (0xd8e68f7f6c6f7166)
Signature Algorithm: sha1WithRSAEncryption
Issuer: CN=hg.example.com
Validity
Not Before: Aug 30 08:45:59 2014 GMT
Not After : Aug 29 08:45:59 2014 GMT
Subject: CN=hg.example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (512 bit)
Modulus:
00:9a:1f:d9:c9:21:a5:72:ad:00:2c:d2:e6:03:58:
19:aa:de:b5:1e:bb:b2:c0:fa:d1:93:a5:b2:ac:b2:
51:82:df:97:ec:e3:fd:14:59:44:7e:5d:ad:cc:77:
f3:aa:f9:8a:0a:d4:90:a0:f2:0d:58:e7:40:24:c7:
a4:05:81:60:29
Exponent: 65537 (0x10001)
Signature Algorithm: sha1WithRSAEncryption
17:d8:78:f4:b9:12:a8:9e:9a:22:5a:68:81:9b:94:1e:d8:a1:
5d:e2:99:06:c8:a4:b5:52:03:94:37:1c:62:c3:72:d1:14:a1:
f5:7c:54:7e:19:3e:5c:c2:f0:f2:30:65:62:f7:25:b5:25:dd:
27:b5:9e:68:a7:50:45:e9:2e:31