<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: Thu Jul 15 01:02:43 2004</font></i></body></html>
# | Change | User | Description | Committed | |
---|---|---|---|---|---|
#1 | 6119 | Dimitry Andric | Create branch from //public/revml, changelist 5088, since I originally started making changes to this version. | ||
//guest/perforce_software/revml/product/release/0.90/html/VCP/Filter/sort.html | |||||
#1 | 4344 | alan_teague |
Revised productization files updating to latest perl modules and normalizing scripts to work on both linux and bsd platforms. |