Mercurial > hg
view tests/test-convert-cvs-synthetic @ 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 | 56a5f80556f5 |
children | 6e4cf8319f54 |
line wrap: on
line source
#!/bin/sh # This feature requires use of builtin cvsps! "$TESTDIR/hghave" cvs || exit 80 set -e echo "[extensions]" >> $HGRCPATH echo "convert = " >> $HGRCPATH echo "graphlog = " >> $HGRCPATH echo % create cvs repository with one project mkdir cvsrepo cd cvsrepo CVSROOT=`pwd` export CVSROOT CVS_OPTIONS=-f export CVS_OPTIONS cd .. filterpath() { eval "$@" | sed "s:$CVSROOT:*REPO*:g" } cvscall() { echo cvs -f "$@" cvs -f "$@" 2>&1 } # output of 'cvs ci' varies unpredictably, so just discard it cvsci() { echo cvs -f ci "$@" cvs -f ci "$@" >/dev/null 2>&1 } filterpath cvscall -d "$CVSROOT" init mkdir cvsrepo/proj cvscall -q co proj echo % create file1 on the trunk cd proj touch file1 cvscall -Q add file1 cvsci -m"add file1 on trunk" file1 echo % create two branches cvscall -q tag -b v1_0 cvscall -q tag -b v1_1 echo % create file2 on branch v1_0 cvscall -Q up -rv1_0 touch file2 cvscall -Q add file2 cvsci -m"add file2" file2 echo % create file3, file4 on branch v1_1 cvscall -Q up -rv1_1 touch file3 touch file4 cvscall -Q add file3 file4 cvsci -m"add file3, file4 on branch v1_1" file3 file4 echo % merge file2 from v1_0 to v1_1 cvscall -Q up -jv1_0 cvsci -m"MERGE from v1_0: add file2" # Step things up a notch: now we make the history really hairy, with # changes bouncing back and forth between trunk and v1_2 and merges # going both ways. (I.e., try to model the real world.) echo "% create branch v1_2" cvscall -Q up -A cvscall -q tag -b v1_2 echo "% create file5 on branch v1_2" cvscall -Q up -rv1_2 touch file5 cvs -Q add file5 cvsci -m"add file5 on v1_2" echo "% create file6 on trunk post-v1_2" cvscall -Q up -A touch file6 cvscall -Q add file6 cvsci -m"add file6 on trunk post-v1_2" echo "% merge file5 from v1_2 to trunk" cvscall -Q up -A cvscall -Q up -jv1_2 file5 cvsci -m"MERGE from v1_2: add file5" echo "% merge file6 from trunk to v1_2" cvscall -Q up -rv1_2 cvscall up -jHEAD file6 cvsci -m"MERGE from HEAD: add file6" echo % cvs rlog output filterpath cvscall -q rlog proj | egrep '^(RCS file|revision)' echo "% convert to hg (#1)" cd .. filterpath hg convert --datesort proj proj.hg echo "% hg glog output (#1)" hg -R proj.hg glog --template "{rev} {desc}\n" echo "% convert to hg (#2: with merge detection)" filterpath hg convert \ --config convert.cvsps.mergefrom="\"^MERGE from (\S+):\"" \ --datesort \ proj proj.hg2 echo "% hg glog output (#2)" hg -R proj.hg2 glog --template "{rev} {desc}\n"