Mercurial > hg
view tests/test-bundle-vs-outgoing @ 10301:56b50194617f
templates: rename `Last change' column in hgwebdir repository list.
This patch changes column headers in the templates that previously
said `Last change' to `Last modified'. Neither code nor functionality
are changed other than that.
For some time now, I have been annoyed by the fact the `Last change'
column didn't list the age of the youngest changeset in the
repository, or at least tip. It just occurred to me that this is
because the wording is slightly misleading; what the column in fact
lists is when the repository was last *modified*, that is, when
changesets was last added or removed from it.
The word `change' can be understood as referring to the changeset
itself. Using `changed' would be ever so slightly less
amigous. However, the standard nomenclature in this case is
`modification date' and `Last modified', which is incidentally entirely
unambigous. Hence, `Last modified' is the wording used.
author | Dan Villiom Podlaski Christiansen <danchr@gmail.com> |
---|---|
date | Sun, 24 Jan 2010 20:51:53 +0100 |
parents | 7d2e9121ef4f |
children |
line wrap: on
line source
#!/bin/sh # this structure seems to tickle a bug in bundle's search for # changesets, so first we have to recreate it # # o 8 # | # | o 7 # | | # | o 6 # |/| # o | 5 # | | # o | 4 # | | # | o 3 # | | # | o 2 # |/ # o 1 # | # o 0 mkrev() { revno=$1 echo "rev $revno" echo "rev $revno" > foo.txt hg -q ci -m"rev $revno" } set -e echo "% setup test repo1" hg init repo1 cd repo1 echo "rev 0" > foo.txt hg ci -Am"rev 0" mkrev 1 # first branch mkrev 2 mkrev 3 # back to rev 1 to create second branch hg up -r1 mkrev 4 mkrev 5 # merge first branch to second branch hg up -C -r5 HGMERGE=internal:local hg merge echo "merge rev 5, rev 3" > foo.txt hg ci -m"merge first branch to second branch" # one more commit following the merge mkrev 7 # back to "second branch" to make another head hg up -r5 mkrev 8 echo "[extensions]" >> $HGRCPATH echo "graphlog=" >> $HGRCPATH echo "% the story so far" hg glog --template "{rev}\n" # check that "hg outgoing" really does the right thing echo "% sanity check of outgoing: expect revs 4 5 6 7 8" hg clone -r3 . ../repo2 # this should (and does) report 5 outgoing revisions: 4 5 6 7 8 hg outgoing --template "{rev}\n" ../repo2 echo "% test bundle (destination repo): expect 5 revisions" # this should bundle the same 5 revisions that outgoing reported, but it # actually bundles 7 hg bundle foo.bundle ../repo2 echo "% test bundle (base revision): expect 5 revisions" # this should (and does) give exactly the same result as bundle # with a destination repo... i.e. it's wrong too hg bundle --base 3 foo.bundle