My apologies: When I said developers would want to see all changes, I meant all items that have changed.
Original Message:
Sent: Sep 11, 2024 05:11 AM
From: Balakrishna Shantamurthy
Subject: WorkAreas and Concurrent Update
Hi Jarus Bosman,
Thanks for the quick update.
The comparison list shows all versions and it would be possible to compare only one version at a time either with trunk or other branch version.
Even if we use third party tools like Winmerge , it would be helpful for a 3 way comparison only.
The option that the developers will want to see all changes made by other developers and not just one at a time is not possible in workarea/workspace.
Another option exists which can be used within the workbench itself i.e List Version process to be used with options Show Change Description and Show actual change
Steps:
1.From workbench ,say for a base version 0 , three branch versions for the same file are created by multiple developers
- Dev1 using pack1 creates version 0.1.1
- Dev2 using pack1 creates version 0.2.1
- Dev3 using pack3 creates version 0.3.1
2. Navigate to the repository path in the view path of the repository from workbench and select all files i.e version 0 ,0.1.1, 0.2.1 and 0.3.1 all in one go.
3.Right click and navigate to the List versions process(List versions is a process with public access and will be available to all developers unless explicitly removed by the administrator)
4.Choose the options "Show Change Description" and "Show actual change"
5.Click on OK
The output log pane will show a comparison of the files with actual change and change description .
It will show multiple other attributes as well
Sample output:
*** \Prod2\DOCS\HPGL2PS.TXT;0.1.1
Description:
Size: 4228
Package: pack1_DEV
State: Development
Project: Production
Creator : user1
Version Creation Time: Sep 10, 2024, 6:15:32 PM
Version Modification Time: Sep 10, 2024, 6:15:46 PM
File Creation Time: 2024-09-10 18:15:32
File Modification Time: 2024-09-10 18:15:40
Version Status: N
Previous Item Name: ---
Previous Full Parent Path Name: ---
Full Parent Path Name: \Prod2\DOCS
Previous Version Status: N1c1
Same kind of details will be displayed for all files to be reviewed for comparison.
Please review and let us know if it is helpful to your developer comparison requirements
This may not be a visually enriching comparison but will help the need is our understanding.
For a detailed understanding of the List version process details ,please refer to the tech docops page from here
If you need further support on this ,please let us know and we can have a meeting scheduled to be able to help your use case.
Regards,
Balakrishna
Original Message:
Sent: Sep 11, 2024 02:35 AM
From: Jarus Bosman
Subject: WorkAreas and Concurrent Update
Hi Balakrishna,
Thank you for your response.
Option 1 is not sufficient, because the developer won't know who made changes and with which package - There might be multiple developers and multiple packages.
Option 2 is not sufficient either, because the developers will want to see all changes made by other developers and not just one at a time.
At this stage, they are happy to merge changes in the Merge state (see my update in the original post on this thread). I think we might be able to achieve what I need by doing a Checkout for Browse with the Synchronize option.
------------------------------
Jarus Bosman
Senior Software Developer
State Information Technology Agency
South Africa
Original Message:
Sent: Sep 10, 2024 02:32 PM
From: Balakrishna Shantamurthy
Subject: WorkAreas and Concurrent Update
Hi Jarus Bosman,
Thanks for the ask here.
Our understanding of your requirement is summarized as below.
1. Workspaces are created from Development state
2. You are able to do concurrent check out(s) from this development state from the workspace using a package say for ex: pack_dev1
3. There is a limitation that you have mentioned that changes made to production are seen only when the merge is resolved and promoted to production
4. Your requirement is to see other developer's changes (they have also done concurrent update of their versions using their own package say for ex : pack_dev2_ Is this a correct understanding.?)
5. The developers would like to see other developers' changes while still in development:
Option#1:
If you want to see the versions in the SYNCHONISER VIEW of the workspace/workarea
You may change the context of the workspace settings and change it to the package name used by the developer 2
If you do this and then apply the synchronize action ,the changes made by the developer 2 will be visible from the synchronizer view for the versions which are already checked in as branch versions by the developer 2
Option#2:
You may choose to use compare with version in repository to view the changes committed by other developers
Option is illustrated in the below screenshot:
a. Click on the version in the workspace and navigate to Compare with version in repository
b. This will open up list of versions for the same item changed by other developers
c. Double click on the version to be able to open the comparison pane thereby viewing the version content of the other developers which is your requirement.
Please follow these steps and let us know if this is helpful to resolve the requirements.
Regards,
Balakrishna
Original Message:
Sent: Sep 06, 2024 02:40 AM
From: Jarus Bosman
Subject: WorkAreas and Concurrent Update
Hi,
I've created a project where the Development and Production states share the same view (created from the supplied Production Model template). The lifecycle is Development -> Merge -> Test -> Staging -> Production. My users use WorkSpaces because it is a Java project, so they want a copy of all the source code on their local PC. I'm able to do concurrent checkouts, but changes made by other developers only become visible in the WorkArea once their changes are promoted to Production (because they get merged in the Merge state). The interactive merge works in the Merge state when both developers' changes reach the Merge state.
HOWEVER
The developers would like to see other developers' changes while still in development. Is the only way to see these changes in the WorkArea to change the Development state to have its own view?
Kind regards
UPDATE:
I've decided to let developers move to Merge first, then allow other developers to get the latest development code from there by changing their WorkArea context to point to the Merge state.
------------------------------
Jarus Bosman
Senior Software Developer
State Information Technology Agency
South Africa
------------------------------