Incoming file not showing merge when the same file is changed in sandbox
I have a file modified in sandbox but not checked-in/delivered yet. But the same file has been modified by another developer and got delivered. So I see that file in incoming changes. I was expecting it to show something like the file is changed in sandbox also. Unless I see both Unresolved and Incoming folders, I dont realize that same file is modified in sandbox. This could possibly cause issues when developers Accept the changes without realizing that same file is changed in Sandbox. My local file can't be checked-in/delivered yet. How can we see that Incoming file is modified in sandbox also without actually looking at Unresolved folder which is very hard when there are lot of files modified in Sandbox.
|
2 answers
Geoffrey Clemm (30.1k●3●30●35)
| answered Dec 31 '13, 2:04 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
I've created work item In Pending Changes view, show conflicts between unresolved and incoming changes (295970) for this request.
Note that these conflicts are displayed in the Package Explorer view. Also note that whenever you execute an Accept when you have Unresolved changes in your sandbox, the GUI will pop-up a warning advising you to checkin your changes before performing the accept, or your Unresolved changes may be overwritten by the Accept. I personally believe it should refuse to do the Accept if it will in fact overwrite Unresolved changes ... I've submitted another work item requesting that behavior: When accepting changes when there are unresolved changes, the GUI should check whether you actually will overwrite any changes (295971) Comments Thanks. I agree for second work item 295971. For first work item 295970, How can we see that in package explorer. I beleive package explorer shows only the files.
Geoffrey Clemm
commented Dec 31 '13, 9:51 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
The icons for a file in the package explorer indicate whether there are incoming changes, outgoing changes, or both (i.e., a conflict) for that file.
When is this bug planned to be delivered?
Geoffrey Clemm
commented Feb 03 '14, 5:54 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
In general, to find out when/whether a given work item is being planned for delivery, just click on the link to that work item, and look at the "Planned For" field in that work item. If it is just Backlog, then it is not in plan for the next release. If you'd like to advocate for it to be added to a release, some of the things you can do include adding a comment to that work item, indicating your support, and participating in the quarterly "VoiCE" on-line forums to try to bump its priority.
|
Hello Ram
When there is an incoming change, you need to look into the unresolved folder, look for the conflicting files, resolve the conflict as appropriately.
Accepting the changes will get the latest changeset into the repository workspace only yet and not into the sandbox. Only when you load, will this file get loaded into the sandbox where you are modifying the same file.
http://pic.dhe.ibm.com/infocenter/clmhelp/v4r0/index.jsp?topic=%2Fcom.ibm.team.scm.doc%2Ftopics%2Fc_csets_conflict.html
It is a good practice to check-in the contents to the repository workspace often.
http://pic.dhe.ibm.com/infocenter/clmhelp/v4r0/index.jsp?topic=%2Fcom.ibm.jazz.repository.web.admin.doc%2Ftopics%2Ft_backup_commercial_db.html
I do not believe there is a way to see that incoming file is modified in sandbox as well, without looking at unresolved folder. This perhaps is because the contents in sandbox is not within RTC source control yet, until it is checked in.
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.
Comments
Just for interest's sake, why don't you want to check-in your partially completed work? RTC is designed to make it easy/fast to do so, to make sure that your repository contains a back-up of your partial work in case something goes wrong on your local disk, or if you need to access that partial work from another machine.
These files are like settings files which are supposed to stay in my sandbox.
Normally, a file that is supposed to stay in your sandbox should be added to the "ignored" list, so it doesn't appear in the "Unresolved" list. But in that case, you get no warning if that file is going to be overwritten by an incoming change (work item Accepting change to ignored file could prompt before overwriting or present as a conflict (57560) requests that a warning be generated). Since these files should be local to a sandbox, why are there incoming changes that would overwrite them?