It's all about the answers!

Ask a question

Incoming file not showing merge when the same file is changed in sandbox


Ram Chundu (18811) | asked Dec 31 '13, 11:18 a.m.
edited Dec 31 '13, 11:18 a.m.
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.

Comments
Geoffrey Clemm commented Dec 31 '13, 12:08 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

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.


Ram Chundu commented Dec 31 '13, 2:48 p.m.

These files are like settings files which are supposed to stay in my sandbox.


Geoffrey Clemm commented Dec 31 '13, 9:47 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

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?

2 answers



permanent link
Sumant Renukarya (1.1k23139) | answered Dec 31 '13, 12:17 p.m.
edited Dec 31 '13, 12:19 p.m.
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. 

permanent link
Geoffrey Clemm (29.4k23035) | 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
Ram Chundu commented Dec 31 '13, 2:47 p.m.

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.


Ram Chundu commented Feb 03 '14, 12:30 p.m.

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.

Your answer


Register or to post your answer.