I thought hg update (with no arguments) would move me to the end* of the current [unnamed] branch, but I believe it will try crossing branches if the other one is newer, which is not what I want to do.
* I'm deliberately avoiding the word "tip" because "tip" refers to the most recent revision, regardless if that named branch has two or more heads.
I'll give some example.
2 4 (tip)
o------o
/
o---o
\
o---o
1 3
I'm at 1, but I want to update to 3 (the end of the branch I'm on). If I type hg update with no arguments it will actually error with the message "abort: crosses branches (merge branches or update --check to force update)". In some scenarios it might even say "abort: not a linear update (merge or update --check to force update)" but I'm not quite sure what triggers that (if you know, please tell me).
If I do hg update --check it will move me to 4 (the tip of the current named branch), which is not what I want either.
I can check hg log to find out the changeset for 3 and then hg up 3, but I would like to do it in one command because trying to understand the log is tedious.
Perhaps revsets could be of use, but I don't know which one would help me.
So, how can I update to the end of the current unnamed branch?
A plain hg update tries to take you to 4 (not 3) because it always tries to take you to the newest (technically "most tipward") revision on the requested branch, or default if unspecified. So it doesn't matter if you're on 0, 1, or 3, hg update is always saying take me to 4 with the graph above (assuming all revisions are on the same named branch).
Your revset to take you to the greatest descendent of your current revision is great, but if you find yourself navigating between multiple heads on the same named branch often consider dropping a bookmark on each of them. A bookmark is like a tag that auto-advances on commit, so if you do:
hg bookmark -rev 3 mybranch
hg checkout mybranch
you'll end up with the 'bookmark' mybranch that will always move forward as new child changesets are added, and you can always get back to it with hg checkout mybranch
Related
I am trying to achieve the same as these guys did: https://uniswap.org/blog/ipfs-uniswap-interface/
So first I read this:
https://docs.ipfs.io/concepts/ipns/
It says:
IPNS is not the only way to create mutable addresses on IPFS. You can
also use DNSLink, ...
So I went to read https://dnslink.io/, and then added a TXT _dnslink dnslink=/ipfs/<CID> entry to my DNS records.
Works perfectly.
But what about an update to content - won't the CID change? Do I have to update the TXT record every time the content changes? Is there a way to have the dnslink record point to always the last release?
https://uniswap.org/blog/ipfs-uniswap-interface/ says:
That TXT record contains the IPFS hash of the latest release.
So it suggest that it needs to be updated all the time. Maybe there is a programmatic way to update the TXT record so they don't have to go in all the time and change the hash?
Sligthly confused ¯_(ツ)_/¯
You can either:
Update the /ipfs/ CID in the TXT every time, programmatically or otherwise. Or, use an /ipns/ CID. With IPNS, you never need to update the TXT, but you need at least 1 IPFS node with the IPNS key to be online most of the time to regularly publish the IPNS record. If you do use IPNS, I recommend generating a new key for the content, not using the default node keypair. This makes it easier to move / copy the key.
We moved a private MediaWiki site to a new server. Some months later we discovered that one or two users had continued to update the old MediaWiki site. So we have some edits in the old server that need to be copied into the new server.
Does anyone know of a routine or process to (conveniently?) compare and identify edits in the old site?
Per the comments attached to this post, the Recent Changes page might work if that page accepted a starting date. Unfortunately, it is limited to a max of 30 days. In this case, I need to review changes for 12 months.
Identify edits done
Identify and verify edits done by your users since the fork
Using the database (assuming MySQL) and no table prefixes
Give me all the edits done since Dec 01 2018 (including that date):
SELECT rev_id, rev_page, rev_text_id, rev_comment, rev_user, rev_user_text, rev_timestamp
FROM revision
WHERE rev_timestamp > '20181201';
Note that the actual page text is stored in the text table, and the page name in the page table.
Give me all edits done since Dec 01 2018 (including that date) with page name and revision text:
SELECT rev_id, rev_page, page_namespace, page_title, rev_text_id, rev_comment, rev_user, rev_user_text, rev_timestamp, old_text
FROM revision r
LEFT JOIN page p
ON p.page_id = r.rev_page
LEFT JOIN text t
ON t.old_id = r.rev_text_id
WHERE rev_timestamp > '20181201';
Note that with tools like MySQL Workbench you can copy results as MySQL insert statements. Dependent on what users did to the old wiki, you might just need to transfer records of 3 tables; however if there were file uploads, deletions or user right changes involved, it's getting complicated. You can track these changes through the logging table.
Using the Web Interface
It is of course possible to show more changes than just 500 for the last 30 days. The setting that allow you to configure this is $wgRCLinkLimits and $wgRCLinkDays. You can also just open the recent changes page, tap 30 days and change the URL parameters so the URL becomes path/to/index.php?title=Special:RecentChanges&days=90&limit=1500 (limit of 1500 within the last 90 days).
The length that recent changes history is retained for depends on $wgRCMaxAge. It is currently 90 days but you might be in luck if the purge job didn't yet delete older entries.
Logs can be viewed without that limitation. Visit Special:Log in your wiki.
Using the API
list=allrevisions lists all page revisions (i.e. changes).
It allows specifying start timestamps (arvstart) and continuation.
Example: https://commons.wikimedia.org/w/api.php?action=query&list=allrevisions&arvlimit=1000
To see deletions, user right changes, uploads, ... use list=logevents.
Fix the issue
Either using database scripts (don't forget to back-up before) or with Special:Export in the source wiki and Special:Import in the Wiki in need of an update.
Avoid the issue
For a future migration to a new server $wgReadOnly might be your friend, avoiding this issue in the first place by making the old wiki read-only.
There is also Extension:Sync, though I am not sure what it is capable of.
I have a revision system running in one of my projects.
A database table looks like the following:
objectID // (no primary/auto_increment!)
versionID
time
deletionTime
// (additionalFields)
The newest revision always has versionID = 0.
On an update, the entry with versionID = 0 gets updated to MAX(versionID)+1.
The updated entry will then be inserted with versionID = 0.
Also, the time of the insert will be saved.
The revision system works good like it is, but I have some difficulties with the system as it is at the moment:
I have another table with no revision system that is related to the revision table:
ID
parentID // the reference to the revision table
time
If I query entries out of this table, I need to join my revision table and get the revision that was relevant when my entry was created.
This means that I need a subquery to select all revisions with revisionTable.time <= otherTable.time
and then group by the entryID.
This does not seem to be a really good solution to me. There will be always a subquery needed for this.
I used this revision system with the current revision as "versionID = 0" because of the ability to easily query all current revisions over all objects.
My solution for a better revision system is as follows:
ID // primary, auto_increment
objectID // multiple revisions share the same objectID
isRevision // bool, the current revision has it set to 0
time
// (additionalColumns)
With this system, I could still query all current revisions and could use the primary ID of the revisions in my other table.
What do you think? Better ideas?
I've just been doing
hg up mybranch
Until now, which mostly works fine, but we've got a handful of branches that just have numbers for their name. How is up supposed to differentiate between a revision number and a branch name? It doesn't seem to support the -b option and I'm not aware of any other method of updating to a branch by name, so what's the proper way of doing it?
Use the branch() revset operator like this:
$ hg update "branch(123)"
That way you can distinguish between revision numbers, branch names, tags, etc. if you've managed to create an ambiguous name. It's of course discouraged to create such names in the first place, but I'm sure you have figured that out by now :-)
I'm building a revision system similar to the one Stack Overflow has and there's one thing I can't get my head around, what's the best way to the differences in tags between multiple revisions?
The simplest way I can think of is we have 3 tables, revisions, tags and another to link the two.
Each revision then has its own set of tags, the only problem is that when you want to display all revisions, the tags need to be re-compared to find out the differences even though they don't change.
Perhaps an extra field or two could be added to mark tags which have been added or removed from the previous revision.
Is there a better way of doing this?
Do not overcomplicate your schema and do not optimize prematurely. Pair-wise comparison of revision tags is a very cheap operation (provided you have all data in memory) and it can be done while prepararing view model.
I'd say you're on the right track
T1: Revisions
|Item ID|revision ID|more...|
T2: Tags
|Tag ID|Tag fields...|
T3: Tags Per Revision
|Item ID|revision ID|Tag ID| /* This will have multiple rows, 1 per tag) */
To find tag diffs, simply retrieve tags for last 2 revisions and compare using your favorite hashmaps in whatever language you have, or however else your language can implement set differences efficiently.