Tagging is so passe'

Tagging is so passe'.

Manually adding keywords to stuff you do.

What we need is "tag suggestion" software.  Software that looks at what you have written, compares it to a corpus - perhaps your stuff, but perhaps stuff from others - and gives you the choice.

---

Automatic email folder classification rules are so passe'...

---

Gmail's labels are so passe'.  Same reasons.

(Plus the absolute lack of structure.)

---

I have played around with Bayesian codes, for determining if tags or labels should apply.

---

Gmail's "important" filter is a step.  But more needed.  Plus, a more personal classification system.

---

I remember GNUS gnus-topic-mode.el  in EMACS fondly.  Realizes that at different times of the day, or in different modes, I may prioritize things differehntly.

THERE ARE NO FIXED PRIORITIES for personal information management.

My priorities when I am reading email on vacation, or in the evening at home, are different than in the day at work.

---

Why tag?

Why not just use search?

Tagging is a crystallization of information content.  E.g. it records the fact that, at some time, you decided that a post was about VCS, Version Control Software, even though it might not contain the phrase in a way that seach would turn up.

Tags make it easier to track [[terminology drift]].  (TBD, need to write a wiki/blog on that).

E.g. what we call now VCS (Version Control) might have been called REvision Control years ago, or CM (Configuration Management).

Terminology drifts over time.  Tags make it easier to track such drift, although even tags drift.

AAdvantage versus Account Aggregation

I just learned that American Airlines' AAdvantage frequent flyer program has sent cease and desist letters to account aggregators.

(This shows how often I check my AAdvantage miles balance - only when I am planning vacation.  It also shows exactly why I depend on an account aggregator - for all of these bleeding accounts...)

Now, perhaps I am exposing myself to hackers because I admit that I use an account aggregator.  Single point of failure, and all that.

(By the way, I would be much happier if the aggregators had read-only access to my accounts - if they could only see balances, but not change passwords.)

But the overall thing is: there are, I have, too many bleeding accounts. Too many blinking passwords.

Account aggregators are one major tool to manage this.

If a company will not let *any* account aggregator access them, well, then I do not need to be a customer of that company.

I was considering dropping American Airlines anyway, because of their financial position. This is just more incentive.

---

Heck, if AAdvantage was implementing better security, such as captchas, I would be happy.But sending "cease and desist" letters - that's garbage.

Branch purpose commit message

I would still like to have a commit message that I write at the time I generate a branch, saying why I am bothering tio generate a named branch.

VCS thoughts

Some fast, probably cryptic, thoughts after a day merging with a "I wasn't familiar with it originally but I am painfully familiar with it now" VCS tool.

•  Merges are branches.
• Mercurial tracks merge workflow in a workspace, assuming that a merge will be a single commit.
• But today I had a complicated enough merge that I started a named branch off just for it. Accomplished the merge between my tasj branch and the trunk. And then merged back from this "merge branch" to the trunk.
• Worked fine, but it would have been nice to have some workflow tracking along the branch. Like "hg resolve", but "hg resolve" stops at the first commit boundary.
• Had to fall back to tracking things by hand, in a text file.

• Mercurial 's names are awkard
• "hg revert" isn't revert
• "hg revert -r REV file" isn't "revert".  It is "include this revision of the file in the candidate commit that you are building in your workspace.
• hg revert corresponds to cvs update
• "hg update" isn't update
• "hg update -r REVorBRABCH" isn't "update". It is "switch the revision or branch that the candidate commit you are building ijn the workspace will be applied to as a child."
• hg update corresponds to cvs checkout, although cvs is pretty sucky there too.  
• It's rather like a rebase when you have no revisions checked in yet
• Mercurial's branchs are not branches.
• They are floating tags
• Not necessarily lines of evolution.
• What would be a better name? "Stream of development?" "Genealogy line"?
• I'd like to have evolutionary branch0lines, as well as what Mercurial has.

• Tags should be versioned. 
• At least Mercurial got that right.
• But old tag versions should be visible in the log.
• And it should be possible to refer to an old tag version, something like "last week's official release"

• Mercurial's anonymous branches rule
• See, I am not purely dissing hg
• But "hg tip" has obviously not been brought up0 to date with named branches

• Can anyone tell me how to do the equivalent of "cvs update -j branch-base -j branch" in Mercurial?
• Without using an external patch
• Hint: "hg merge -r branch" doesn't work, if you have anti-patches on the branch

• I want to be able to "pull onto a branch" or "push a branch".  Not just "push or pull all the branches in the repository".  I.e. I want branch renaming or mapping in pull and push

• Mercurial doesn't do partial checkouts or checkins?
• Maybe not everywhere
• But you can screw yourself up in the same way with "hg ci incomplete list of files"
• I'm not suggesrting denying hg ci files partial
• But I'd like to do it in general.
• 
  
• Partial checkins and checjkourts should correspond to brancges, with merging actively encouraged.
• I've talked about this many times.

Enough already.

"system/command" versus "system command"

A lot of tools have a master command with subcommands. For example

hg clone ...
hg merge

cvs co
cvs update

git clomne
...

I think that the first place I encountered this was with mh. Or, since my friend MH says that mh did not have subcommands, I may have made the following change myself for mh. Why subcommands? I think mainly to avoid name collisions in the bin. Years ago, I kluged - I think it may have been the shell, whoever processes PATH - to search not just for "executable" on the PATH, but also "dir/executable". I.e. instead of saying

hg update

I colud have said

hg/update

Not much of a difference. But it makes it easier for guys to code systems that have lots of subcommands. Also, for users of shells like bash and csh: !hg/update works, whereas "!hg update" doesn't (unless your shell has tweaks.

Mercurial whine:

hg merge -r tip

is NOT the same as

hg merge -r default

Because Mercurial's tip may be on a branch. tip is just the most recent changeset, anywhere. I have hit bugs caused by following hg recipes that talk about using -r tip. Sigh.

Tentative checkin for branch only, not to be merged?

Here's another: Working on a branch, I just did a pull, and merged from trunk onto the beranch. I notice that somebody else has a minor bug on the trunk: it looks like they forgot to check in a test reference pattern, although it is also possible that the test has been checked in before the golden behavior is established. I report the bug. But I would like to silence the error, at least on my branch. I can make the change to the reference patterns. However, I do not know if that change is goosd. I just want to silence it, or mark it as a known error. I don't want my change to propagate back to the trunk when eventually I merge and push. I.e. my branch now contains some tentative stuff, as well as some stuff that I am confident will soon be merghed. On CVS I would create a per file branch for the reference, and work off a merged directory. Eventually, I would update to the main branch, ahnd not get5 my patched test. Unclear how to do this in Mercurial, apart from remembering that I have to delete it eventually. Oh, here's a way:

// working on branch B
hg pull
hg merge -r tip
make test
// make change to silence test error
hg branch Bb
// somehow copy old version of patched file to pre brahnch
hg ci // on Bb
hg update -r B
// now work
// when ready to merge, do the usual
hg pull
hg merge
make test
// now do the extra step to be confident that you aren't pushing anything broken
hg update -r Bb
hg merge -r B
// now should have B, except for that one change that was tenative
make test
// see if the bug was fixed by someone else...
// ok, now merge to default branch, and then push
// - since I am paranoid, I might pull and test again
hg update -r default
hg merge -r Bb
make test
hg push

Works, but is complicated. I am quite likely to forget that I am supposed to merge from branch B onto Bb before merging to the trunk. {{Category-VCS}}{{Category-hg}}