0

I would like to share a dilemma and hear your feedback.

As part of the new version of R&D Reporter for ClearCase, we began offering "Lines of Code" (LoC) metrics and charts when comparing baselines and composite baselines (Added, Modified and removed lines; attached is an illustration).

Now we've been asked to provide LoC metrics when comparing two UCM streams (e.g. how many files and code lines have been changed between an integration stream and one of its child streams). In order to provide this, we must ask the user to provide a view context (in order to access the files inside the stream).

So far we have asked the user to provide one view only. This is not as convenient for some users**, but it's fair enough. Now we have to ask users to provide TWO view contexts, so we are considering the creation of temporary views (probably dynamics) that live as long as the application is running (after which they will be removed), instead of asking them to provide it twice.

Furthermore, as we provide a "Multiple Pending Change-sets" report that compares multiple streams (e.g. an integration stream with all of its child streams), I have the same doubt—but now it is multiplied by the number of streams…

I'm curious to know what you think about using temporary views:

  1. Do you find it convenient and safe? If so—do you prefer dynamic or snapshot view?
  2. Does your company's policy confirm creation of temporary view by a 3rd-party tool?

Thank you!

Composite Baselines comparison and Lines of Code metrics and chart

** Providing a view context may be inconvenient as the user must choose a folder from the file-system, or even create a new view. Moreover, if the user prefers to provide a snapshot view, he or she must provide the folder where the loaded files are, and sometimes this can be quite difficult to find.

JasonMArcher
  • 14,195
  • 22
  • 56
  • 52
Tamir Gefen
  • 1,128
  • 2
  • 18
  • 35

1 Answers1

1

Do you find it convenient and safe? If so—do you prefer dynamic or snapshot view?

Convenient only if the view is created for the user, not if the user has to create it.

But there is scalability issue (for views with a large number of file):

  • using a dynamic view won't scale well: reading the content of all the files can take too much time, considering said content has to be read through the network (and not locally from the disk)

  • using a snapshot view newly created would take too much time to initialize (load all the files).

Does your company's policy confirm creation of temporary view by a 3rd-party tool?

You generally an create any view you want or need, temporary or otherwise.
The company's policy rarely address or limit that specific point.

I would:

  • create two temporary non-UCM views
  • set their config spec to the ones if the requested Stream(s)

The first initialization will be long (loading of all the files).
But the subsequent initialization (when changing the config spec of one temp view to match another UCM Stream) will be much quicker (only the delta would change).

The main idea remains: the end-user shouldn't have to worry about temporary views, and shouldn't have to create/update/maintain them.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thank you @VonC. Would you mind clarifying, how do you suggest to use temporary views if your company would not allow to set such views? – Tamir Gefen Sep 25 '13 at 09:29
  • @TamirGefen I never heard of a company not allowing to set view, temporary or otherwise. – VonC Sep 25 '13 at 09:32
  • Thx. I now understand your "No" statement. I like your approach, however there could be problems if the user runs two LoC queries concurrently... I have to think about that. Thx again. – Tamir Gefen Sep 25 '13 at 09:51
  • 1
    @TamirGefen yes, you might have to force the sequential aspect of that feature. Or manage a "pool" of temporary views. – VonC Sep 25 '13 at 10:37