Software-update: Mercurial 4.0.2

Mercurial is een programma voor onder andere software- en projectontwikkelaars waarmee beheer en versiecontrole over data en broncode kunnen worden uitgevoerd. Het programma kan worden gezien als een directe concurrent voor het welbekende svn of subversion. Mercurial wordt bijvoorbeeld gebruikt door NetBeans en Roundup Issue Tracker. Versie 4.0.2 is sinds kort beschikbaar met de volgende lijst aanpassingen:

Mercurial 4.0.2

This is a regularly-scheduled bugfix release.

• demandimport: do not raise ImportError for unknown item in fromlist
• posix: make poll() restart on interruption by signal (issue5452)
• hgweb: add missing slash to file log url in rss style

Mercurial 4.0.1

This is a regularly-scheduled bugfix release.

• hgweb: cache fctx.parents() in annotate command (issue5414)
• vfs, scmutil: ignore EPERM at os.utime, which avoids ambiguity (issue5418)

Mercurial 4.0

Features:

• The following commands now also have experimental formatter support: 'hg version', 'hg grep' and 'hg config'
• New template keywords and functions: termwidth, mod(a, b), relpath(path)
• Basic arithmetic operations in template such as termwidth - 10
• follow() revset takes new startrev parameter
• Bash completion now allows skipping potentially expensive status call for completing 'hg status' arguments, using $HGCOMPLETE_NOSTATUS environment variable

Improvements

• A number of changes were made to move and copy tracking, to make sure move and copy information is not lost during commands like 'hg graft'
• Compound revset expression is now properly ordered
• Performance of client-side application of bundle data for generaldelta repos has been significantly improved. This makes 'hg clone', 'hg pull', and 'hg unbundle' operations faster. Cloning the Firefox repository now consumes 70+s less CPU time and completes over a minute faster (when not network or I/O bound).
• The storage and transfer of changeset data has been optimized to improve read performance
• Python 3 support has received a lot of improvements (but will take a lot of additional work)
• zlib performance in hgweb is improved, and it's now possible to control zlib compression level using server.zliblevel option
• Various improvements for largefiles extension related to executable bit tracking and removing files, better recovery from an interrupted state

Versienummer	4.0.2
Releasestatus	Final
Besturingssystemen	Windows 7, Linux, BSD, macOS, Solaris, UNIX, Windows Server 2008, Windows Server 2012, Windows 8, Windows 10
Website	Mercurial
Download	https://www.mercurial-scm.org/downloads
Licentietype	GPL

Reacties (12)

[:murb:]

Ik heb het idee dat Mercurial eigenlijk alleen op plekken wordt gebruikt waar men op het verkeerde paard heeft gewed; de rest van de wereld draait toch op Git? (of ze moeten nog coderen door te spijkeren in steentabletten en SVN gebruiken, de horror)

Dat gezegd hebbende: een gedistribueerd versiebeheer systeem (zoals Git, maar ook zoals Mercurial) is altijd beter dan een niet-gedistribueerd versiebeheer systeem (zoals SVN, of CVS)), en de noodzaak om te switchen naar Git is er dan ook niet echt wanneer je Mercurial gebruikt... al helpt het niet echt om twee bijna dezelfde systemen (Git en Mercurial) door elkaar te moeten gebruiken als ontwikkelaar (vanuitgaande dat er altijd wel iets vanuit een Git repository gebruikt wordt (OSS)).

[Reactie gewijzigd door :murb: op 24 juli 2024 08:12]

[jeroen_o]

Zoals ik het eens van een collega heb gehoord: "met Git kun je je eigen versiebeheersysteem bouwen, Mercurial is gewoon een versiebeheersysteem".
Ik ben zelf heel erg blij met Mercurial, nooit gekke issues, supergoeie branching en vooral merging ondersteuning, ook voor hooks.
Vanuit mijn perspectief is Git juist nodeloos ingewikkeld, maar dat is misschien ook omdat ik al die geavanceerde features van git nooit gebruik (rebase, reset etc) en er binnen Mercurial ook nooit de behoefte voor heb gehad. Je kunt met Mercurial inmiddels ook mooi 'shelven', dus changes opsparen die je nog niet wilt committen, maar ook dat is voor mij niet vaak nodig.

[latka]

Ik snap niet waarom mensen zo 'hung up' zijn aan gedistribueerde versie systemen. Ja het is leuk dat het kan, maar de noodzaak ontbreekt steeds meer met over en altijd online. Wellicht dat iemand mij kan vertellen wat de meerwaarde is als je altijd online bent.

[Ed Vertijsment]

Als je centrale source server down gaat om wat voor reden dan ook kan je niet 123 met de code van een collega verder, waar je met decentrale systemen gewoon een andere "origin" pakt en verder gaat.

[latka]

Dat geld voor allerlei soorten diensten. Maar bij versiebeheer lijkt het een soort religie te zijn om gedistribueerd te gaan.

[Ed Vertijsment]

Ik dat het er meer op neerkomt dat oudere versiebeheer systemen gewoon "outdated" zijn in vergelijking met Mercurial of Git. Als je de vraag stelt waarom kom je nou eenmaal op het decentrale uit wat het meest kenmerkende karakter is.

Zelf vind ik het grootste voordeel van Git de aanwezigheid van Github en het ecosysteem, ik ben minder bekend met Mercurial dus daar kan ik niet veel van zeggen.

[latka]

Ik gebruik svn en git afhankelijk van het project. Heb wel gemerkt dat in teams het svn model veel eenvoudiger uit te leggen is. In git teams zijn het vaak techneuten die het willen gebruiken om de historie zo 'mooi mogelijk' te maken inclusief history rewrites etc. Heb het niet gemeten maar ik schat in dat git zo'n 5% productieve uren kost door dat soort geneuzel.

[Verwijderd]

Mozilla gebruikt Mercurial…

[Katsunami]

Mercurial en Git zijn ongeveer even oud.

Het grote verschil is dat Git in het begin niet op Windows draaide, terwijl Mercurial in de eerste plaats voor Windows is ontwikkeld.

Mensen die Linux gebruiken op de een of andere manier, gebruiken meestal Git; en de bom is natuurlijk Github voor mensen die zich bezig houden met open source. Echter, mensen die primair met Windows werken, gebruiken vaak Mercurial.

[Reactie gewijzigd door Katsunami op 24 juli 2024 08:12]

[P_Tingen]

Mwoa, of ze op het verkeerde paard gewed hebben weet ik zo net niet. Wij werken ook met GIT maar laat ik het zo zeggen: het heeft bij ons tot op heden veel creativiteit naar boven gebracht. Vooral creativiteit op het gebied van vloekwoorden. Ja, GIT is prachtig, het kan alles en - oh ja - het is vooral gedistribueerd want je wil toch niks anders?

Me neus, als bij ons de GIT server down gaat, dan krijgt de systeembeheerder een doodschop om zo snel mogelijk de rommel weer up te krijgen. Als je het al hebt over wedden op verkeerde paarden dan denk ik dat wij beter op een ander paard hadden kunnen wedden. GIT is op het oog simpel, maar dat is het vooral als je een klein project hebt. Mijn persoonlijke meuk staat ook op GitHub en daar is het perfect voor, maar zodra je met een team van 20 man op 1 GIT repository gaat zitten, moet je de zaak goed voor elkaar hebben. Veel ontwikkelaars kennen GIT niet goed en rommelen maar wat aan. Probeer het dan nog maar eens goed te krijgen. Groot voordeel van GIT is dat je je best moet doen om spul echt kwijt te raken; meestal als je de boel ver&^%(%& hebt, zit het nog wel /ergens/ in de repo.

Ik ben geen Apple fan, maar ik heb vaak verzucht dat ik graag een Appleversie van versiebeheer zou willen hebben; iets als iVersion of zo. Dat zou dan maar op 1 voorgedefinieerde manier werken; lekker overzichtelijk.

[jbijnens]

Ik begin zo stilaan de indruk te krijgen dat de discussie over revision control systems begint te lijken op een discussie tussen godsdiensten met het nodige bekeerfundamentalisme. Om het met de woorden van opperguru Linus te zeggen : you are allowed to disagree with me, but then again I consider you ugly and stupid.

[latka]

Ja, nu we weten dat een tab 4spaties is en emacs beter is dan Vi was het tijd voor een nieuwe non-discussie.