Topic
  • 5 replies
  • Latest Post - ‏2012-08-15T14:42:43Z by SystemAdmin
GKellner
GKellner
259 Posts

Pinned topic Count versions per element

‏2012-08-14T13:41:46Z |
Hello fellows,

does anyone has a idea, how I can create a list like

Name of element | amount of versions
foo.c | 83
foo.bar | 12
and so on?

Either a dump nor a describe helps.

Of course, I can write a script which does a lsvtree -all on each element and count the output lines.

But is there an easier way?

In the graphical vtree the amount of versions is displayes.

greetings georg.
  • Tgefen
    Tgefen
    727 Posts

    Re: Count versions per element

    ‏2012-08-14T14:30:52Z  
    Hi Georg,

    Do you need that to find out how many files have been changed \created between two releases, streams, projects or baselines? If so, I can suggest an easier way...

    We work these days to enhance one of our ClearCase add-ons, R&D Reporter, to provide a similar request. We will provide it as a report in the context of a comparison between two baselines or streams. e.g. compare two streams and get a statistics summary of:
    NNN activities have been created
    MMM elements have been changed or created
    YYY file versions have been created
    ZZZ merged file versions

    Herein an example (screenshot): see here

    We will generate this report to screen (see above, so you can use a context-menu for further investigating properties, version tree, annotating etc.), or you may export it to email, Excel, PDF, XML etc.
    For each file element, you get a parent-child list of all file versions (as his children). We also provide the parent-child list grouped by activities.

    If you want to join our Beta program and get it when it's ready, let me know please.

    Regards,
    Tamir Gefen, GoMidjets
  • SystemAdmin
    SystemAdmin
    47283 Posts

    Re: Count versions per element

    ‏2012-08-14T17:00:09Z  
    GKellner wrote:
    > does anyone has a idea, how I can create a list like
    >
    > Name of element | amount of versions
    > foo.c | 83
    > foo.bar | 12
    > and so on?

    > Of course, I can write a script which does a lsvtree -all on each
    > element and count the output lines.
    >
    > But is there an easier way?

    Easier than that? You are kidding!
    Bash:
    
    echo $e : $(ct lsvtree -all -s 
    "$e" | egrep 
    '/[1-9][0-9]*$' | wc -l)
    

    This avoids 0 versions, and handles spaces in names...
    You have also of course:
    
    foo.c : 42
    

    It is easier at the expense of being correct only every now and then...
    As per the Einstein quote: every problem in the world has a solution which is clear, simple, and false.

    Of course, if you want to deal with many elements, use Perl, if only to save on cleartool invocations:
    
    perl -MClearCase::Argv -e 
    '$ct=new ClearCase::Argv({ipc=>1,autochomp=>1); 
    
    for($ct->find(qw(. -ele !created_since(now) -print)->qx) 
    { print 
    "$_: ", scalar(grep m%/[1-9]\d*$%, $ct->lsvtree([qw(-a -s)],$_)->qx), 
    "\n"; 
    }
    '
    


    You mentioned dump...
    For text files, there is an option of grepping the lines starting with '^V' in the source containers.
    Probably faster indeed.
    Unfortunately, it will require some work for some other element types (starting with the compressed ones)...

    Marc
  • SystemAdmin
    SystemAdmin
    47283 Posts

    Re: Count versions per element

    ‏2012-08-14T17:01:53Z  
    GKellner wrote:
    > does anyone has a idea, how I can create a list like
    >
    > Name of element | amount of versions
    > foo.c | 83
    > foo.bar | 12
    > and so on?

    > Of course, I can write a script which does a lsvtree -all on each
    > element and count the output lines.
    >
    > But is there an easier way?

    Easier than that? You are kidding!
    Bash:
    <pre class="jive-pre"> echo $e : $(ct lsvtree -all -s "$e" | egrep '/[1-9][0-9]*$' | wc -l) </pre>
    This avoids 0 versions, and handles spaces in names...
    You have also of course:
    <pre class="jive-pre"> foo.c : 42 </pre>
    It is easier at the expense of being correct only every now and then...
    As per the Einstein quote: every problem in the world has a solution which is clear, simple, and false.

    Of course, if you want to deal with many elements, use Perl, if only to save on cleartool invocations:
    <pre class="jive-pre"> perl -MClearCase::Argv -e '$ct=new ClearCase::Argv({ipc=>1,autochomp=>1); for($ct->find(qw(. -ele !created_since(now) -print)->qx) { print "$_: ", scalar(grep m%/[1-9]\d*$%, $ct->lsvtree([qw(-a -s)],$_)->qx), "\n"; } ' </pre>

    You mentioned dump...
    For text files, there is an option of grepping the lines starting with '^V' in the source containers.
    Probably faster indeed.
    Unfortunately, it will require some work for some other element types (starting with the compressed ones)...

    Marc
    Marc wrote:
    Somebody stole me a brace...
    
    perl -MClearCase::Argv -e 
    '$ct=new ClearCase::Argv({ipc=>1,autochomp=>1}); ...
    

    Marc
  • GKellner
    GKellner
    259 Posts

    Re: Count versions per element

    ‏2012-08-15T10:57:42Z  
    • Tgefen
    • ‏2012-08-14T14:30:52Z
    Hi Georg,

    Do you need that to find out how many files have been changed \created between two releases, streams, projects or baselines? If so, I can suggest an easier way...

    We work these days to enhance one of our ClearCase add-ons, R&D Reporter, to provide a similar request. We will provide it as a report in the context of a comparison between two baselines or streams. e.g. compare two streams and get a statistics summary of:
    NNN activities have been created
    MMM elements have been changed or created
    YYY file versions have been created
    ZZZ merged file versions

    Herein an example (screenshot): see here

    We will generate this report to screen (see above, so you can use a context-menu for further investigating properties, version tree, annotating etc.), or you may export it to email, Excel, PDF, XML etc.
    For each file element, you get a parent-child list of all file versions (as his children). We also provide the parent-child list grouped by activities.

    If you want to join our Beta program and get it when it's ready, let me know please.

    Regards,
    Tamir Gefen, GoMidjets
    The background for this topic:

    A project complains about bad CC performance.
    The VOBs where moved to a new server, the network was pimped but they keep on complaining.

    So my idea is, not to look for hardware, but to look how they are using CC.
    First thing: Analyzing the db via countdb
    37.000 elements are okay, 500.000 versions are also okay, but the 13.400.000 Version_Label_Links are scary.
    Counting also the directory versions, every element and directory version in this VOB has 25 labels in average.
    THis is the point, where we can stop talking about performance.

    The next thing:
    Analyzing the elements.
    I will check the size of the elements in comparsion with the amount of versions.
    If someone wants to checkout a 100 k file, which has due to its history a source container with 3 or 4 M, he'll has to wait.
    So I want to have the list, mentioned above.

    @marc: I know how to spell the word bash, I know, my Unix admin hates bash.
    That's all I know ;-)
    It's also a Windows VOB.

    greetings georg.
  • SystemAdmin
    SystemAdmin
    47283 Posts

    Re: Count versions per element

    ‏2012-08-15T14:42:43Z  
    • GKellner
    • ‏2012-08-15T10:57:42Z
    The background for this topic:

    A project complains about bad CC performance.
    The VOBs where moved to a new server, the network was pimped but they keep on complaining.

    So my idea is, not to look for hardware, but to look how they are using CC.
    First thing: Analyzing the db via countdb
    37.000 elements are okay, 500.000 versions are also okay, but the 13.400.000 Version_Label_Links are scary.
    Counting also the directory versions, every element and directory version in this VOB has 25 labels in average.
    THis is the point, where we can stop talking about performance.

    The next thing:
    Analyzing the elements.
    I will check the size of the elements in comparsion with the amount of versions.
    If someone wants to checkout a 100 k file, which has due to its history a source container with 3 or 4 M, he'll has to wait.
    So I want to have the list, mentioned above.

    @marc: I know how to spell the word bash, I know, my Unix admin hates bash.
    That's all I know ;-)
    It's also a Windows VOB.

    greetings georg.
    GKellner wrote:
    > @marc: I know how to spell the word bash, I know, my Unix admin hates bash.
    > That's all I know ;-)

    Now I know it too. Until now, you didn't tell.
    The reason I used bash was the '$(...)' syntax instead of the infamous backticks.
    It is not the only pro of bash, There are cons too.
    Maybe your UNIX admin is able to spell his hatred in a more collaborative way?
    Just 'hate' is slightly opaque...

    > It's also a Windows VOB.

    This may be a reason to switch to Perl...
    Or to Cygwin (my CPAN wrapper supports Cygwin).

    'Bad performance' is also a bit opaque...
    Not sure 13M version label links would be dangerous.
    In fact, even if I share your surprise for this labeling disease, I would guess this is a symptom rather than a cause.

    What about the networking?
    What about the branching strategy?
    What exactly is slow?
    Can you narrow it down to individual commands that you could run under mvfstime, in order to make comparisons?

    Marc