MantisBT
Mantis Bug Tracker Workflow

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0025748Open CASCADE[OCCT] OCCT:Foundation Classespublic2015-01-23 19:272019-09-04 21:53
Reporterabv 
Assigned Tomsv 
PrioritynormalSeverityminor 
StatusassignedResolutionopen 
PlatformOSOS Version
Product Version 
Target Version[OCCT] 7.5.0*Fixed in Version 
Summary0025748: Foundation Classes - Parallel version of progress indicator
DescriptionIn order to provide progress indication functionality in algorithms working in parallel mode (BOP, BRepMesh), it is necessary to make progress indicator (classes Message_Progress*) capable of working in parallel threads.
Steps To Reproduceperf fclasses progress_par
TagsNo tags attached.
Test case number
Attached Filesxlsx file icon bug25478_perf.xlsx (11,510 bytes) 2019-08-31 18:01

- Relationships
related to 0025113assignedoan Community Mesh - Progress indication and user break functionality for BRepMesh component 
related to 0030697newkgv Open CASCADE Draw Harness - Draw_Printer should not be set to Message::DefaultMessenger() by default 
related to 0025896assignedabv Community Modeling Algorithms - UserBreak raising uncatchable exception in boolean operations 
related to 0030871assignedabv Community Data Exchange - Add a minimal progress indication for writing STEP and IGES files 
related to 0025482assignedabv Open CASCADE Data Exchange - Usage of progress indicator by a translation process of a STEP file into DECAF document 

-  Notes
(0076845)
git (administrator)
2018-06-20 11:54

Branch CR25748 has been created by msv.

SHA-1: 21a68e71d603039611304c2a68b385c37287b968


Detailed log of new commits:

Author: msv
Date: Wed Jun 20 11:54:41 2018 +0300

    0025748: Parallel version of progress indicator
    
    The fix revises the progress indication mechanism. Now, the class Handle(Message_ProgressIndicator) performs the only function of calling back to user application. It just accumulates the progress provided by progress scopes.
    
    The new class Message_ProgressScope serves to represent a scope of execution. The new instance of it is created to provide progress advancement of a new coming operation. The scopes are nested to each other to reflect the nested nature of operations.
    
    All codes involving progress indication have been updated to new API.
(0076866)
git (administrator)
2018-06-21 13:05

Branch CR25748 has been updated by msv.

SHA-1: df083f1fd8a7647b189776260534167270ec0f0d


Detailed log of new commits:

Author: msv
Date: Thu Jun 21 13:04:43 2018 +0300

    # Improved version of indicator and scope.
    # More codes are moved to new API.

(0077434)
git (administrator)
2018-07-10 20:53

Branch CR25748_1 has been created by msv.

SHA-1: c89b4b85c527c84e723f42e8d8079a9f5d2d6c8a


Detailed log of new commits:

Author: msv
Date: Wed Jun 20 11:54:41 2018 +0300

    0025748: Parallel version of progress indicator
    
    The fix revises the progress indication mechanism. Now, the class Handle(Message_ProgressIndicator) performs the only function of calling back to user application. It just accumulates the progress provided by progress scopes. The counter is protected by mutex for thread-safety.
    
    The new class Message_ProgressScope serves to represent a scope of execution. The new instance of it is created to provide progress advancement of a new coming operation. The scopes are nested to each other to reflect the nested nature of operations. Each instance of progress scope can call the method Increment of the progress indicator concurrently with other scopes, which make the work of the overall mechanism thread-safe.
    
    All OCCT algorithms involving progress indication have been updated to new API.
    
    Improvements in Draw_ProgressIndicator:
    
    - Console mode has been added in order to make possible to put the progress into cout instead of draw interpreter.
    - Treatment of Ctrl-Break signal has been added. Now any operation can be aborted by Ctrl-C or Ctrl-Break keystroke.
(0077439)
git (administrator)
2018-07-10 23:14

Branch CR25748_1 has been updated by msv.

SHA-1: 5d09214f94d19fd57f2283fd9d11646b7b7ba9db


Detailed log of new commits:

Author: msv
Date: Tue Jul 10 23:13:53 2018 +0300

    #correct compilation error

(0077529)
git (administrator)
2018-07-12 15:20

Branch CR25748_1 has been updated forcibly by msv.

SHA-1: 4fd60394052d7ea81389416d68011bdcc46cc423
(0077561)
git (administrator)
2018-07-13 08:40

Branch CR25748_1 has been updated forcibly by msv.

SHA-1: 63d200d4d3c1e03c1ba0062ed899bcc79d53903e
(0077588)
git (administrator)
2018-07-13 18:19

Branch CR25748_1 has been updated forcibly by msv.

SHA-1: 05365f941b15c0e2714dd705221d820a28243e81
(0077652)
git (administrator)
2018-07-16 12:52

Branch CR25748_2 has been created by msv.

SHA-1: 87033320e01ee9f7a56c73bc59153afc0e7c356d


Detailed log of new commits:

Author: msv
Date: Wed Jun 20 11:54:41 2018 +0300

    0025748: Parallel version of progress indicator
    
    The fix revises the progress indication mechanism. Now, the class Handle(Message_ProgressIndicator) performs the only function of calling back to user application. It just accumulates the progress provided by progress scopes. The counter is protected by mutex for thread-safety.
    
    The new class Message_ProgressScope serves to represent a scope of execution. The new instance of it is created to provide progress advancement of a new coming operation. The scopes are nested to each other to reflect the nested nature of operations. Each instance of progress scope can call the method Increment of the progress indicator concurrently with other scopes, which make the work of the overall mechanism thread-safe.
    
    All OCCT algorithms involving progress indication have been updated to new API.
    
    Improvements in Draw_ProgressIndicator:
    
    - Console mode has been added in order to make possible to put the progress into cout instead of draw interpreter.
    - Treatment of Ctrl-Break signal has been added. Now any operation can be aborted by Ctrl-C or Ctrl-Break keystroke.
(0077747)
git (administrator)
2018-07-17 17:33

Branch CR25748_2 has been updated forcibly by msv.

SHA-1: c201ed8ca8bae7307ecd21d4c9e70541b3412452
(0077749)
msv (developer)
2018-07-17 17:42

Please review the branches in occt and products.
Jenkins tests are now executed http://jenkins-test-11.nnov.opencascade.com:8080/view/CR25748_2-CR25748_1-msv/view/COMPARE/ [^]
(0084216)
git (administrator)
2019-05-07 11:19

Branch CR25748_3 has been created by msv.

SHA-1: 92d57ddcdcd47bfce8ade716a42d2eda07998c42


Detailed log of new commits:

Author: msv
Date: Wed Jun 20 11:54:41 2018 +0300

    0025748: Parallel version of progress indicator
    
    The fix revises the progress indication mechanism. Now, the class Handle(Message_ProgressIndicator) performs the only function of calling back to user application. It just accumulates the progress provided by progress scopes. The counter is protected by mutex for thread-safety.
    
    The new class Message_ProgressScope serves to represent a scope of execution. The new instance of it is created to provide progress advancement of a new coming operation. The scopes are nested to each other to reflect the nested nature of operations. Each instance of progress scope can call the method Increment of the progress indicator concurrently with other scopes, which makes the work of the overall mechanism thread-safe.
    
    All OCCT algorithms involving progress indication have been updated to new API.
    
    Improvements in Draw_ProgressIndicator:
    
    - Console mode has been added in order to make possible to put the progress into cout instead of draw interpreter.
    - Treatment of Ctrl-Break signal has been added. Now any operation can be aborted by Ctrl-C or Ctrl-Break keystroke.
(0084232)
msv (developer)
2019-05-07 17:24

Please review.
(0084233)
msv (developer)
2019-05-07 17:25

Tests results http://jenkins-test-12.nnov.opencascade.com/view/CR25748-CR25748-MSV/view/COMPARE/ [^]
(0084293)
kgv (developer)
2019-05-12 17:26

   // Print textual progress info
-  if ( myTextMode )
+  if (myConsoleMode)
+    cout << text << endl;
+  else if (myTextMode)
     Message::DefaultMessenger()->Send (text, Message_Info);

Do we have any use cases, where printing progress to Draw_Printer instead of std::cout will be of any use apart from synthetic test case bugs/fclasses/bug28478?

+  if (OSD_Thread::Current() != myThreadId)
+    // avoid showing in another thread

What are consequences of this check - no any progress in case if algorithm performs all jobs in non-main thread (or unpredictable progress from main thread when using OSD_Parallel::For())?
I suppose that the main purpose for this check is a crash on using Tcl-interpretor from multiple threads (which is not that a blocking issue in case of std::cout).

+  const Message_ProgressScope& GetRootScope() const
+  {
...
+  //! Returns the name of the scope (may be null)
+  Standard_CString GetName() const
+
+  //! Returns parent scope (null for top-level scope)
+  const Message_ProgressScope* GetParent() const
+
+  //! Returns the maximal value of progress in this scope
+  Standard_Real GetMax() const
+
+  //! Returns the current value of progress in this scope
+  Standard_Real GetValue() const
+
+  //! Get start position of this scope on total progress scale
+  Standard_Real GetStart() const
+
+  //! Get end position of this scope on total progress scale
+  Standard_Real GetEnd() const

Shouldn't this be RootScope()/End()/Parent()/Start()?

+  //! Sets the name of the scope.
+  Standard_EXPORT void SetName(Standard_CString theName);
..
+
+  //! Creates a sub-scope covering current step of the parent scope, 
+  //! and selects parameters of the current scale. The top most scope 
+  //! must be got using the method GetRoopScope() of Message_ProgressIndicator.
+  Standard_EXPORT Message_ProgressScope(const Message_ProgressScope& theParent,
+                                        Standard_CString theName,
+                                        Standard_Real theMin = 0, Standard_Real theMax = 100,
+                                        Standard_Real theStep = 1, Standard_Boolean isInfinite = false)

...
+  Standard_CString   myName;        //!< Name of the operation being done in this scope, or null


This should be well-documented that the given name will NOT be copied, hence application should never pass string from a temporary variable.

+public: //! @name Destrucion, allocation

Destrucion

+  mutable Standard_Real myPosBySS;  //!< Current position reserved by sub-scopes
+  mutable Standard_Integer myNbChild; //!< Number of children - used to control code consistency


I suppose that the main reason for these fields to be mutable is to pass Message_ProgressScope as const reference, which in turn is done to allow defining default argument value "const Message_ProgressScope& theProgress = Message_ProgressScope()". I think its worth to be documented.
(0084294)
kgv (developer)
2019-05-12 22:37
edited on: 2019-05-12 22:38

Example of usage in parallel process:
+//!
+//! @code{.cpp}
+//! struct Task
+//! {
+//!   Data* Data;
+//!   Message_ProgressScope Progr;
+//!
+//!   Task(const Data& theData, Message_ProgressScope& theProgr)
+//!     : Data(theData), Progr(theProgr, NULL, 0, 1, 1) {}
+//!
+//!   void operator()(Task& theTask) const
+//!   {
+//!     if (theTask.Progr.More())
+//!     {
+//!       // ... process data
+//!       theTask.Progr.Next();
+//!     }
+//!   }
+//! };
+//! {
+//!   std::vector<Data*> aData; // somehow got data
+//!   std::vector<Task> aTasks;
+//!
+//!   Message_ProgressScope aPS(aRootPS, "Data processing", 0, aData.size(), 1);
+//!   for (Standard_Integer i = 0; i < aData.size(); ++i)
+//!     aTasks.push_back(Task(aData[i], aPS));
+//!   
+//!   OSD_Parallel::ForEach(aTasks.begin(), aTasks.end(), Task());
+//! }
+//! @endcode
...
+void Message_ProgressIndicator::Increment(const Standard_Real theStep,
+                                          const Message_ProgressScope& theScope)
 {
+  Standard_Mutex::Sentry aSentry(myMutex);
+  myPosition = Min(myPosition + theStep, 1.);
+  Show(Standard_False, theScope);

Since proposed API requires explicit barrier at spawning and passing to multiple threads, I would expect this mutex NOT to be used by default - it is unneeded by majority of algorithms / waste of time. Instead, the parallelization can be assigned to Progress Indicator first time algorithm is about to spawn working threads and forking progress to them.

The new parallelization design relies on the idea that enumerated entities are of significant size to spawn individual Progress Sentry for each such task - the main thread-safety idea is possibility to sub-divide Progress Sentry further within nested algorithms. But this mechanism cannot be used for OSD_Parallel::For() on big amount of small elements due to extra overhead of individual Progress Sentries and serialization via global mutex in Progress Indicator itself. For such small tasks with unpredictable balancing (within perfect balancing algorithm might spawn Progress Sentry per working thread by equally splitting full range), thread-safe updating of single shared Progress Sentry will be still responsibility of local to algorithm code - in exactly the same way, as existing Progress Indicator API.

(0084407)
git (administrator)
2019-05-16 17:47

Branch CR25748_3 has been updated forcibly by msv.

SHA-1: 864a80af9414e0b3b351b69e30745b83899f2fa2
(0084411)
git (administrator)
2019-05-17 09:31

Branch CR25748_3 has been updated forcibly by msv.

SHA-1: 2f2d36be0b37a6ea656dadfd077756dd77f4fa17
(0084436)
msv (developer)
2019-05-17 22:16

I have updated the code according to KGV's remarks.
New test results are here: http://jenkins-test-12.nnov.opencascade.com/view/CR25748-CR25748-MSV2/view/COMPARE/ [^]
(0084469)
msv (developer)
2019-05-20 09:25

Dear Andrey, please review the current version.
(0086518)
git (administrator)
2019-08-29 11:52

Branch CR25748_4 has been created by abv.

SHA-1: 76bf385d511d8d94238e75769b13d0c5fcadc771


Detailed log of new commits:

Author: abv
Date: Thu Aug 29 08:11:25 2019 +0300

    Restored description of the changes in Upgrade Guide

Author: abv
Date: Wed Aug 28 19:57:56 2019 +0300

    Further revision:
    
    - Virtual methods of Message_ProgressIndicator (Show(), UserBreak(), Reset()) are made protected since they are for call by the class itself and its friend ProgressScope only
    - Method Message_ProgressIndicator::Show() is made returning void since its return value is not specified and not used anywhere
    - For scopes that are advanced by sub-scoping rather than direct calls to Next(), method Message_ProgressScope::Value() returns current value estimated from value of global progress
    - Restored support of infinite scopes for sub-scoping
    - Copy constructor and assignment operator are prohibited for Message_ProgressScope
    - Documentation comments revised

Author: abv
Date: Tue Aug 27 18:56:22 2019 +0300

    # Amendments to the original version:
    
    1. Method RootScope() is replaced by method Start() that now also calls Reset(), to improve semantics (make it clear that this method should be called only once to start progress tracking).
    2. Arguments of method Show() are swapped to allow progress scope to be passed with second argument being default; additional method Show() w/o argument is added for compatibility (if someone called it that way).
    3. Method IsProgress() renamed to IsActive() to improve semantics.
    4. Counter field Message_ProgressScope::myNbChild and method removeScope() are removed -- it is not thread safe if children can be destroyed in another thread. Same-purpose check is made comparing myProgess field of this and parent scopes.
    5. Restored DRAW command OCC25748 for measuring performance of progress indicator on empty cycles (borrowed from initial commit circa 2018).

Author: abv
Date: Tue Aug 27 14:09:46 2019 +0300

    Rename of Message_ProgressSentry to Message_ProgressScope is recorded in upgrade.dat

Author: abv
Date: Tue Aug 27 15:34:29 2019 +0300

    # Unification of names: theProgr -> theProgress

Author: abv
Date: Tue Aug 27 14:10:28 2019 +0300

    # Unification of names: thePI -> theProgress

Author: abv
Date: Tue Aug 27 14:08:50 2019 +0300

    # Upgrade after rebasing on current master

Author: msv
Date: Thu May 16 17:39:47 2019 +0300

    #Considering remarks

Author: msv
Date: Wed Jun 20 11:54:41 2018 +0300

    0025748: Parallel version of progress indicator
    
    The fix revises the progress indication mechanism. Now, the class Handle(Message_ProgressIndicator) performs the only function of calling back to user application. It just accumulates the progress provided by progress scopes. The counter is protected by mutex for thread-safety.
    
    The new class Message_ProgressScope serves to represent a scope of execution. The new instance of it is created to provide progress advancement of a new coming operation. The scopes are nested to each other to reflect the nested nature of operations. Each instance of progress scope can call the method Increment of the progress indicator concurrently with other scopes, which makes the work of the overall mechanism thread-safe.
    
    All OCCT algorithms involving progress indication have been updated to new API.
    
    Improvements in Draw_ProgressIndicator:
    
    - Console mode has been added in order to make possible to put the progress into cout instead of draw interpreter.
    - Treatment of Ctrl-Break signal has been added. Now any operation can be aborted by Ctrl-C or Ctrl-Break keystroke.
    
    # Conflicts:
    # src/Draw/Draw_ProgressIndicator.cxx
    # src/GeomPlate/GeomPlate_BuildPlateSurface.cxx
    # src/TopTools/TopTools_ShapeSet.cxx
    # src/TransferBRep/TransferBRep_Reader.cxx
    # src/ViewerTest/ViewerTest_ViewerCommands.cxx
    # src/XSDRAWSTEP/XSDRAWSTEP.cxx
(0086544)
git (administrator)
2019-08-30 02:46

Branch CR25748_4 has been updated by abv.

SHA-1: c109b1d4535b2d6b18da026a6f73df07d3b7377e


Detailed log of new commits:

Author: abv
Date: Thu Aug 29 19:43:04 2019 +0300

    Compatibility with VS 2010

(0086546)
git (administrator)
2019-08-30 09:01

Branch CR25748_4 has been updated by abv.

SHA-1: cf2bda848878b507d1220c2e8b71f17d3fcf88d6


Detailed log of new commits:

Author: abv
Date: Fri Aug 30 08:58:32 2019 +0300

    # fix compiler warnings (order of initialization of class fields in constructor)

(0086549)
git (administrator)
2019-08-30 12:49

Branch CR25748_4 has been updated by abv.

SHA-1: 9dd702ae4346ca5bcd9d61281d6587248d68a6eb


Detailed log of new commits:

Author: abv
Date: Fri Aug 30 12:45:50 2019 +0300

    Attempt to avoid rounding problems on Linux

(0086562)
git (administrator)
2019-08-30 23:19

Branch CR25748_4 has been updated by abv.

SHA-1: f2dba2f2068ff1df1a4df9d5ad8410e01ce09d99


Detailed log of new commits:

Author: abv
Date: Fri Aug 30 23:16:22 2019 +0300

    Correction of build issues; public method Show() is moved to Message_ProgressScope

(0086569)
git (administrator)
2019-08-31 12:35

Branch CR25748_4 has been updated forcibly by abv.

SHA-1: e29a148a09fd9b31f428d3e196e2e95c61fa807c
(0086574)
abv (manager)
2019-08-31 17:22
edited on: 2019-08-31 18:04

Mikhail, I have reviewed ans amended the patch - please see branch CR25748_4 (and CR25748_3) on master. It is not squashed yet so you can inspect my changes.

This version passed Jenkins tests, see job CR25748_4.

There is a slow down reported on synthetic test case perf fclasses progress:
Linux: 6.24 / 2.64 [+136.36%]
Windows: 3.8125 / 2.921875 [+30.48%]
This could be expected (due to progress counter protected by mutex) and can be considered OK.

Attached Excel file contains measurements of effect of progress indicator on synthetic test case consisting of many (10 M) simple tasks, executed in both sequential and parallel modes (test command OCC25748 restored from initial version of the patch). Conclusion is that changes did not lead to noticeable decrease of performance (they are within measurement error) even on such small tasks.

(0086590)
git (administrator)
2019-09-01 11:22

Branch CR25748_4 has been updated by abv.

SHA-1: 3b996e4b4e91f9cfef0066bbc9b381a4ff569a7a


Detailed log of new commits:

Author: abv
Date: Sun Sep 1 11:14:59 2019 +0300

    Progress indicator is added in StlAPI_Writer

Author: abv
Date: Sun Sep 1 11:14:47 2019 +0300

    Redundant arguments Start and Step (almost always used to be 0 and 1, respectively) are removed from Message_ProgressScope constructor

Author: abv
Date: Sat Aug 31 18:02:45 2019 +0300

    Test command OCC25748 is improved to report total time

(0086592)
git (administrator)
2019-09-01 13:17

Branch CR25748_4 has been updated forcibly by abv.

SHA-1: a87070338f5eacdef0bd31f5891439b600e46a82
(0086600)
git (administrator)
2019-09-01 23:35

Branch CR25748_4 has been updated forcibly by abv.

SHA-1: fabc05333584096f78681e4134e0cf5cad278fb7
(0086605)
abv (manager)
2019-09-02 07:50

Hello Mikhail,

The patch has been slighly updated (see above); Jenkins tests are OK (CR25748-abv).

Yet I still have a doubt regarding whether the current implementation is sufficietly good to be considered as final (by API). I feel and observe in practice that its logic is not clear and it is difficult to use it properly.

The main problem in my mind is that ProgressScope can be incremented by two different methods: calling Next() and creation of sub-scopes, and it is not obvious at all that when you create sub-scope this has the same effect as Next(). Even more, when you pass scope to a function, you cannot know if it will use it (creating sub-scope) or not, thus you must call Next() explicitly in addition (to be on the safe side). Within implementation of the function you can easily create more than one sub-scope, which will result in multiple steps of the passed scope.

The possibility to improve could be:
- Make Next() the only way to advance project scope
- Next() should not advance immediately but return temporary object (say, ProgressRange) that takes responsibility of making the specified step at its destruction
- ProgressScope shall require ProgressRange as argument to its constructor. When constructed from range, it shall disarm the range object (so it will not advance the progress) and thus take responsibility of advancement.

The API will then change as follows:
- Method Start() of ProgressIndicator will return ProgressRange
- "const ProgressRange&" will be used to pass progress object to functions
- Method Next() shall be used (possibly with an argument denoting step) whenever sub-scope is created or function with progress support is called
- Method SetStep() and relevant field can be removed from ProgressScope class

Let's discuss this
(0086668)
msv (developer)
2019-09-02 18:46

Upon discussion we decided to move target to 7.5.0, as the current version of the patch needs to be improved further.

- Issue History
Date Modified Username Field Change
2015-01-23 19:27 abv New Issue
2015-01-23 19:27 abv Assigned To => abv
2015-01-23 19:27 abv Relationship added related to 0025113
2015-03-27 21:35 abv Target Version 6.9.0 => 7.1.0
2016-11-01 06:41 abv Target Version 7.1.0 => 7.2.0
2017-07-27 09:43 abv Target Version 7.2.0 => 7.4.0
2018-06-19 15:49 msv Relationship added related to 0029872
2018-06-20 11:54 git Note Added: 0076845
2018-06-20 11:55 msv Assigned To abv => msv
2018-06-20 11:55 msv Status new => assigned
2018-06-20 11:55 kgv Summary Parallel version of progress indicator => Foundation Classes - Parallel version of progress indicator
2018-06-21 13:05 git Note Added: 0076866
2018-07-10 20:53 git Note Added: 0077434
2018-07-10 23:14 git Note Added: 0077439
2018-07-12 15:20 git Note Added: 0077529
2018-07-13 08:40 git Note Added: 0077561
2018-07-13 18:19 git Note Added: 0077588
2018-07-16 12:52 git Note Added: 0077652
2018-07-17 17:33 git Note Added: 0077747
2018-07-17 17:42 msv Note Added: 0077749
2018-07-17 17:42 msv Assigned To msv => abv
2018-07-17 17:42 msv Status assigned => resolved
2018-07-17 17:42 msv Steps to Reproduce Updated View Revisions
2019-05-07 09:03 msv Assigned To abv => msv
2019-05-07 09:03 msv Status resolved => assigned
2019-05-07 11:19 git Note Added: 0084216
2019-05-07 17:24 msv Note Added: 0084232
2019-05-07 17:24 msv Assigned To msv => kgv
2019-05-07 17:24 msv Status assigned => resolved
2019-05-07 17:25 msv Note Added: 0084233
2019-05-12 16:46 kgv Relationship added related to 0030697
2019-05-12 17:26 kgv Note Added: 0084293
2019-05-12 22:37 kgv Note Added: 0084294
2019-05-12 22:38 kgv Note Edited: 0084294 View Revisions
2019-05-13 12:25 kgv Assigned To kgv => abv
2019-05-16 17:47 git Note Added: 0084407
2019-05-17 09:31 git Note Added: 0084411
2019-05-17 22:16 msv Note Added: 0084436
2019-05-20 09:25 msv Note Added: 0084469
2019-08-29 11:52 git Note Added: 0086518
2019-08-30 02:46 git Note Added: 0086544
2019-08-30 09:01 git Note Added: 0086546
2019-08-30 12:49 git Note Added: 0086549
2019-08-30 23:19 git Note Added: 0086562
2019-08-31 12:35 git Note Added: 0086569
2019-08-31 17:22 abv Note Added: 0086574
2019-08-31 17:22 abv Assigned To abv => msv
2019-08-31 17:22 abv Status resolved => feedback
2019-08-31 18:01 abv File Added: bug25478_perf.xlsx
2019-08-31 18:04 abv Note Edited: 0086574 View Revisions
2019-09-01 11:22 git Note Added: 0086590
2019-09-01 13:17 git Note Added: 0086592
2019-09-01 23:35 git Note Added: 0086600
2019-09-02 07:50 abv Note Added: 0086605
2019-09-02 18:46 msv Note Added: 0086668
2019-09-02 18:46 msv Status feedback => assigned
2019-09-02 18:46 msv Target Version 7.4.0 => 7.5.0*
2019-09-02 18:51 abv Relationship added related to 0021264
2019-09-04 12:22 kgv Relationship added related to 0025896
2019-09-04 21:49 abv Relationship added related to 0030871
2019-09-04 21:53 abv Relationship added related to 0025482


Copyright © 2000 - 2019 MantisBT Team
Powered by Mantis Bugtracker