<html><head><title>VCP::Filter::sort - Sort revs by field, order</title></head><body><h1><a name="NAME">NAME
</a></h1><p>VCP::Filter::sort - Sort revs by field, order
<p><hr><h1><a name="SYNOPSIS">SYNOPSIS
</a></h1><pre> ## From the command line:
vcp <source> sort: name ascending rev_id ascending -- <dest>
</pre><pre> ## In a .vcp file:
</pre><pre> Sort:
name ascending
rev_id ascending
</pre><p><hr><h1><a name="DESCRIPTION">DESCRIPTION
</a></h1><p>NOTE: this filter is primarily for development and testing, it is not
designed for large datasets (it can use a lot of RAM if fed enough data).
<p>Useful with the revml: destination to get RevML output in a
desired order. Otherwise the sorting built in to the change
aggregator should suffice.
<p>The default sort spec is "name,rev_id" which is what is handy to
VCP's test suite as it puts all revisions in a predictable order
so the output revml can be compared to the input revml.
<p>NOTE: this is primarily for development use; not all fields may work
right. All plain string fields should work right as well as name,
rev_id, change_id and their source_... equivalents (which are parsed and
compared piece-wise) and time, and mod_tome (which are stored as
integers internally).
<p>Plain case sensitive string comparison is used for all fields other than
those mentioned in the preceding paragraphs.
<p>This sort may be slow for extremely large data sets; it sorts things
by comparing revs to eachother field by field instead of by generating
indexes and VCP::Rev is not designed to be super fast when accessing
fields one by one. This can be altered if need be.
<p><hr><h1><a name="How_rev_id_and_change_id_are_sorted">How rev_id and change_id are sorted
</a></h1><p><code>change_id</code> or <code>rev_id</code> are split in to segments
suitable for sorting.
<p>The splits occur at the following points:
<pre> 1. Before and after each substring of consecutive digits
2. Before and after each substring of consecutive letters
3. Before and after each non-alpha-numeric character
</pre><p>The substrings are greedy: each is as long as possible and non-alphanumeric
characters are discarded. So "11..22aa33" is split in to 5 segments:
( 11, "", 22, "aa", 33 ).
<p>If a segment is numeric, it is left padded with 10 NUL characters.
<p>This algorithm makes 1.52 be treated like revision 1, minor revision 52, not
like a floating point <code>1.52</code>. So the following sort order is maintained:
<pre> 1.0
1.0b1
1.0b2
1.0b10
1.0c
1.1
1.2
1.10
1.11
1.12
</pre><p>The substring "pre" might be treated specially at some point.
<p>(At least) the following cases are not handled by this algorithm:
<pre> 1. floating point rev_ids: 1.0, 1.1, 1.11, 1.12, 1.2
2. letters as "prereleases": 1.0a, 1.0b, 1.0, 1.1a, 1.1
</pre><p><hr><h1><a name="LIMITATIONS">LIMITATIONS
</a></h1><p>Stores all metadata in RAM.
<p><hr><h1><a name="AUTHOR">AUTHOR
</a></h1><p>Barrie Slaymaker <barries@slaysys.com>
<p><hr><h1><a name="COPYRIGHT">COPYRIGHT
</a></h1><p>Copyright (c) 2000, 2001, 2002 Perforce Software, Inc.
All rights reserved.
<p>See <a>VCP::License</a> (<code>vcp help license</code>) for the terms of use.
<p><hr><i><font size="-1">Last updated: Fri Jun 4 14:21:32 2004</font></i></body></html>