|
Size: 2370
Comment:
|
Size: 3352
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 2: | Line 2: |
| Line 5: | Line 4: |
| Mercurial features you should consider avoiding | Mercurial features you should consider avoiding. |
| Line 10: | Line 9: |
| Line 18: | Line 16: |
| These features are all at odds with Mercurial's core design assumptions, and will therefore always present difficulties in terms of performance, ease-of-use, and integration. As such, when using them, you won't get the best possible Mercurial experience. | These features exist for supporting some (usually legacy) use cases, but are not considered best practice. These features are all at odds with Mercurial's core design, and will therefore always present some difficulties in terms of performance, ease of use, and integration. As such, when using them, you won't get the best possible Mercurial experience. Due to our [[CompatibilityRules|compatibility rules]], these features will continue to exist — but we want to make you aware that there are often better alternatives. |
| Line 24: | Line 24: |
| Line 28: | Line 27: |
| Line 31: | Line 29: |
| Alternatives are usually community specific. * Python * [[http://pypi.python.org/pypi|PyPI]] and [[http://www.pip-installer.org/en/latest/index.html|pip]] ([[http://article.gmane.org/gmane.comp.version-control.mercurial.general/31303|Example]]) * [[https://bitbucket.org/hstuart/repoman|repoman]]: Mercurial-based repository forest manager * Non-Mercurial: [[http://en.wikipedia.org/wiki/Repo_(script)|Repo tool by Google:]] used by the Android project, written in python, specific to git * Java * [[http://maven.apache.org/|Maven]], [[http://ant.apache.org/ivy/|Ivy]], [[http://www.jfrog.com|Artifactory]], etc (package sub-project or dependency as a .jar file) |
|
| Line 32: | Line 39: |
| Line 36: | Line 42: |
| This will only give acceptable performance on very small projects. There are plenty of [[MercurialHosting|free or inexpensive alternatives]]. | |
| Line 37: | Line 44: |
| This will only give acceptable performance on very small projects. There are plenty of [[MercurialHosting|free or inexpensive alternatives]]. | == See also == * UnlovedFeatures |
Features of Last Resort
Mercurial features you should consider avoiding.
Contents
1. What is a feature of last resort?
"Features of last resort" include:
These features exist for supporting some (usually legacy) use cases, but are not considered best practice.
These features are all at odds with Mercurial's core design, and will therefore always present some difficulties in terms of performance, ease of use, and integration. As such, when using them, you won't get the best possible Mercurial experience. Due to our compatibility rules, these features will continue to exist — but we want to make you aware that there are often better alternatives.
![/!\](/moin-static/modernized/img/alert.png "/!\"){kind=small}
You should give careful consideration to alternatives when first deploying Mercurial.
2. But I need keyword and EOL handling!
Don't be so sure. Plenty of projects larger and more important than yours don't use them. These legacy features were very intentionally excluded from the Mercurial design because their cost/benefit ratio was exceptionally bad. But if external forces dictate that these features are mandatory for using Mercurial, they're available as extensions.
3. But I need to have managed subprojects!
Again, don't be so sure. Significant projects like Mozilla that have tons of dependencies do just fine without using subrepos. Most smaller projects will almost certainly be better off without using subrepos. This is not true for all projects, however, so we've made them available as an option. Be sure to follow our recommendations for best results.
Alternatives are usually community specific.
- Python
repoman: Mercurial-based repository forest manager
Non-Mercurial: Repo tool by Google: used by the Android project, written in python, specific to git
- Java
Maven, Ivy, Artifactory, etc (package sub-project or dependency as a .jar file)
4. But I need to manage lots of large files!
This is certainly true for some projects, but not for most. Mercurial does fine with the binary file needs of most projects where source code dominates, but can run into trouble on projects with gigabytes of binary assets. Using the largefiles extension will help some projects, but will also bring in significant new complexities and rough edges. Again, you should probably only use this feature if testing shows that you can't realistically use Mercurial without it.
5. But I need to host my project on a static HTTP server!
This will only give acceptable performance on very small projects. There are plenty of free or inexpensive alternatives.
6. See also