The "Updated" timestamp is a property of each project, so you don't need to look into logs for that information.
In the GUI, it is in the project properties window, and it can probably also be found using a CLI command, so you can make a script.
On CM Synergy Server, is there a way to log all the client requests to the CM Synergy server on the Server?
I need to know if there is a way to log all the client requests to the CM Synergy server on the Server. I know that the Client maintains a log, but is there a way to log them on the server as well.
I need to specifically know when each user last updated the source code.
Regards,
Shival
Tags:
5 Answers
Hi Shival,
Could you elaborate on what you meant by "when each user last updated the source code"?
The question is more complex than you might think.
Users can modify the contents of work areas directly using standard operating system commands and tools. In a copy-based work area, this gives rise to work area conflicts. Synergy will not know about such work area conflicts until you do either of the following: [ul][li]Perform an explicit operation like Sync. However, it is only when you resolve the work area conflict by pushing the changed file contents from the work area to the database that the object's properties will be updated.[/li][li]Perform an operation such as task complete or a file check in that implicitly performs a work area conflict detection and pushes any such changes to the database.[/li][/ul]So while there are work area conflicts that have not been resolved, there will be no data in Synergy to say that the "source code has changed".
Related to this is that when a file is checked out, the [i]source_modify_time[/i] attribute is not a reliable indicator of when the source contents were changed. It's only when the file is checked in (and becomes immutable) that the [i]source_modify_time[/i] will accurately reflect when that source code was last changed.
If you are looking to see when the source code was changed for static objects, then you can query for and/or view the [i]source_modify_time[/i] attribute.
However, if you want to cover checked out objects, this is likely to be problematic. A working source file might be present in a user's working project, and the work area for that project may not be visible from the client on which you are trying to query or view data.
Perhaps a better starting point for this discussion is to describe what you are trying to achieve and why.
Regards,
David.
David, mdc,
Well, I think my question is a little unclear. I will present the scenario that might make it a little easier to understand.
In my project there are around 11 engineers, all using CM Synergy as the CM tool. There are 3 other sites where development is happening in parallel.
There are instances where the engineers do not perform an "Update Members" for days/weeks together. The engineering management needs to ensure that the engineers update their work-area with the latest changes at least once in 2 days so that they are working with the latest source base.
For the same, I was looking at creating some sort of an automated script that I could run on the CM Synergy server, which would provide me
1. Name of the CM Synergy user
2. Date and Time when they had last performed an "Update Members"
3. Details of the Project(s) on which the update was performed (I think the instance name of the Project would suffice here)
I hope this gives you a better picture of what i really need.
Regards,
Shival
Hi Shival,
Thinking laterally, another way of looking at this is that you want to detect which projects have versions of objects that have successors that update might consider as candidates. In a simple usage case where the developers are working on changes for release R, and the update properties get the completed tasks for release R, you should be able to write a nested query that:
1. Queries for the recursive non-project members of a developer's project hierarchy.
2. Queries for any successors of those members.
3. Queries for the associated completed tasks for release R of those successors.
The query result would be a list of completed tasks for release R whose changes were missing from that developer's project hierarchy.
You might also want to take a look at the
ccm pg|project_grouping -pubt|-preview_update_baseline_and_tasks -include_automatic_tasks] project_grouping_spec...[command.
The help describes this as: "This subcommand performs a preview update of the baseline and tasks for specified project groupings. Use the output to view the baseline and tasks that the project grouping would use if you performed an update members operation."
David.
One additional thought. Best practice for developers is to perform an update members:[ol][li]Before starting work on a new task.[/li][li]Before completing a task.[/li][/ol]The first practice ensures that users start work with the latest completed stuff. The second practice is important to ensure that the changes being made have been unit tested against the latest changes, not just those versions that were used when they started work on that changed. This improves the stability of integration testing builds.
Projects record the date/time at which they were last updated. If an average task takes 2 days to complete, any project that has not been updated for more than, say, 3 days probably warrants closer inspection to see if its owner is following best practices.
David.
CMCrossroads is a TechWell community.
Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.