How to get only the changes done to a file in the sandbox?

Markus Selve

(10●2●3) Feb 18 '15, 10:20 a.m.

I want to find out with lscm what changes I did to a file that I have in my sandbox. I know that I can compare it with 'lscm diff' against the current state in the workspace or in the stream. But that does not only show the changes I did locally in the sandbox, but also those changes to the same file that someone else delivered into the stream or check-in to the workspace (or that I myself delivered or checked-in from another sandbox fixing something else in the same file). But I only want to see my local changes in the sandbox i nquestion. For instance an 'lscm diff' of the local file against how the file was at the point in time when it was loaded into the sandbox, would give the desired information. How do I specify that I want to 'lscm diff' the local file against the files as it was at load time?

Regards, Markus.

0 votes

3 answers

6,870 views

0 votes

Accepted answer

Permanent link

Geoffrey Clemm

FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER (30.1k●3●34●35) Feb 26 '15, 12:28 a.m.

Based on the comments, the central issue here is trying to use the same workspace with more than one sandbox. The answer is simple. Do NOT do that. More details in comments in the previous answer threads.

Markus Selve selected this answer as the correct answer

0 votes

2 other answers

Permanent link

Shashikant Padur

JAZZ DEVELOPER (4.3k●2●7) edited

Feb 18 '15, 11:33 p.m.

lscm diff file <file path> will compare the local changes with that of the latest in the workspace. If your current loaded state was from a baseline then you could use lscm diff file <file path> baseline lt;baseline name/id>. Or if you know the last change set that was accepted (you can run lscm history <file path> and choose the change set based on date/time) you could use lscm diff file <file path> changeset <changeset id>.

By the way, if you have modified the file in the workspace from another sandbox then your current sandbox should report as out of sync.

0 votes

Comments

Markus Selve

Feb 20 '15, 4:37 a.m.

The 'lscm diff' to that changeset from which the file was loaded is what I'm searching for. But how do I know which changeset that was? Does 'lscm load' store this information like in the .jazz5 sub directory? And if so, how do I access this information? Yes, I know that my sandbox is out of sync. That is why I need to load those changes done somewhere else. But I don't want to loose my changes. So I first need to find out what I changed, then to 'lscm load' the changes that were done elsewhere and then apply my changes in order to have both: my changes and the chnages done somewhere else.

Shashikant Padur

JAZZ DEVELOPER Feb 20 '15, 5:53 a.m.

The metadata information in not exposed in the clients. You could run 'lscm status' to figure out what files changed, copy those file into a temporary folder, re-load the workspace and merge those changes back using an external merge tool.

Markus Selve

Feb 23 '15, 10:55 a.m.

I want to merge my changes with the Unix command 'patch'. So I need to know the changes I did. If I would use the difference between the local file and the file in RTC as it is at the current moment, I would reverse the changes that others did. Here is an example what would happen: - I load the file and add, say, line 10 - Someone else loads the file and adds, say, line 20 and delivers this change - I do a 'diff' between my local file and the current version in RTC. The difference is: line 10 added, line 20 removed (because my local file doesn't yet have line 20) - I load the current file and 'patch' the difference: It will add line 10 and remove line 20. As a result I reversed the change that someone else did. That is not what I want to do. Instead I want to keep all changes already delivered by others and put my changes on top. What I want to achieve is what the decades old library system cvs does with a simple 'cvs update'. Not only that RTC isn't offering that out of the box. I even can't write a script to do that, because I can't find out what the file looked like when it was loaded.

Permanent link

Geoffrey Clemm

FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER (30.1k●3●34●35) Feb 23 '15, 1:54 p.m.

Based on the comments, it appears you are trying to preserve your changes from an out-of-sync sandbox.
You might want to add your support to work item:
https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=344701
"Improve handling of resynchronizing a workspace component"

0 votes

Comments

Markus Selve

Feb 24 '15, 4:45 a.m.

I read the description of work item 344701. If I understood it right I'm not sure if I want to support that work item. It seems to suggest to block parallel check-ins to the work space. But that makes using the library more complicated not better. I'm more interested in how to deal with parallel releases to the library. As I already wrote I'm searching for the functionality of 'cvs update' of the decades old library 'cvs'. If I change, say, line 10 and someone else changes, say, line 20 in the same file and delivers it, that is not a conflict, at least not a conflict that needs the attention of the user. That can be merged by tools. Only if I change line 10 and someone else changes line 11, that needs user attention and is a conflict. Other than blocking check-ins as suggested in work item 344701 I rather think that in the sandbox the information is needed from what version of the file (from what change set) it was loaded into the sandbox. With this information the merging by tools can be implemented. Because then one can find out what actually the own changes are and apply them to the newest version of the file.

Geoffrey Clemm

FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Feb 24 '15, 8:35 p.m.

What part of the description of 344701 led you to believe that it would block parallel check-ins? To the contrary, the change set that would be created is what captures the parallel check-ins. But more importantly, what is the use case you are trying to implement? Parallel development is completely automated with RTC (branching, merging, conflict detection, etc.). There is no need to worry about the low level operations being discussed in this thread unless you are doing something unusual, like working on the same workspace in two different sandboxes (which there is no reason to do, but the tool doesn't prevent you from doing it, so if you do it by mistake, you would want the enhancement described in work item 344701). In particular, is your use case maintaining two releases of a library within RTC, one release in RTC and another in a different SCM system, or something else?

Markus Selve

Feb 25 '15, 5:10 a.m.

This part of the description: 'In addition, it would be desirable to give a warning if you are de-synchronizing a workspace component from a sandbox that has unresolved changes to that component. ... Any attempt to modify that workspace component from a client that is not connected to that sandbox would produce a warning (or error), indicating the local pathname of the sandbox that contains those unresolved changes.' If I get an error, that means, I'll not be able to do this? And 'de-synchronizing a workspace' with ' unresolved changes' sounded to me like the situation I was thinking of.

Markus Selve

Feb 25 '15, 5:27 a.m.

No, I don't want to maintain two releases of a library or with a different SCM system. Here is the use case: I 'lscm load' a file because I'm working to implement a new feature. So I start and do some changes to it in the sandbox 1. Now a defect comes in which is more urgent than the new feature. Both, the new feature and the urgent defect to be fixed, are on the same stream So I 'lscm load' the unchanged file again from the same stream into a new sandbox 2. I fix the urgent defect in sandbox 2, check it in, deliver it to the stream. Now I go back to sandbox 1 to continue working on the new feature. The version of the file in sandbox 1 has half of the implementation of the new feature, but it is missing the urgent fix. So I want to merge now or at the end of implementing the new feature the two changes: The urgent fix with the new feature. I just check-in and deliver the new feature? No, this overwrites the urgent fix. I 'lscm load' the urgent fix? No, this overwrites my new feature changes in sandbox 1. And, yes, I tried to do this through one RTC server workspace.

Markus Selve

Feb 25 '15, 6:39 a.m.

I tried to do this through one RTC server workspace as I didn't see the need for using more than one workspace. To me that seemed to be cluttering the server with lots of workspaces. And there are commands 'lscm deregister' and 'lscm register' that seemed to be made for exactly this purpose to bind the current sandbox to the RTC server workspace. But meanwhile I'm intending to do this via an own workspace for each sandbox. As the own workspace is unchanged, I can find out the changes between sandbox and own workspace. Then remove the local file, 'lscm load' the original file in order to be in sync (accept needs this). 'lscm accept' to get the new version into the workspace. Remove the local file again. 'lscm load' the new version. And finally apply the changes that were originally done in sandbox 1 and were saved at the beginning with the Unix command 'patch'.

Geoffrey Clemm

FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Feb 26 '15, 12:47 a.m.

WRT not being able to use the same workspace concurrently with the same sandbox ... that does not block you from doing parallel checkins, it blocks you from doing parallel checkins the wrong way. You can do parallel checkins with a single workspace, but it is by suspending changes, working on other changes, and then resuming the suspended changes. But if you want different configurations loaded in different sandboxes, you should use different workspaces. WRT lscm register/deregister ... they are not for associating different sandboxes with the same workspace ... they are for controlling the association of an lscm daemon with a given sandbox. WRT how to merge changes ... as long as you associate a workspace with a single sandbox, you never remove a local file and load the original file ... you just accept the incoming changes into your workspace, and RTC does all the conflict detection and invoking the appropriate three-way merges automatically. There is no need to use the Unix "patch" command.

Markus Selve

Feb 26 '15, 10:44 a.m.

WRT to merging changes: I think my problems stemmed from two errors of mine: 1. I wanted to use only one server workspace. 2. I wanted to keep one of the two parallel changes in the sandbox and not check it in to the server workspace (as I considered it a longer work and it might be an unfinished implementation. Here is a sequence where RTC merged files automatically. There is a section with tutorials about source control: https://jazz.net/help-dev/clm/index.jsp?re=1&topic=/com.ibm.team.scm.doc/topics/create.html&scope=null Maybe it would be helpful for beginners to have the use case described there. create workspace1 load to sandbox1 create workspace2 load to sandbox2 change in sandbox1 checkin workspace1 deliver workspace1 to stream change in sandbox2 checkin to workspace2: accept stream to workspace2 (sandbox2 is updated automatically) deliver workspace2 to stream

Markus Selve

Feb 26 '15, 10:48 a.m.

Regarding the sequence listed in the last post: Assume change1 is an urgent fix and change2 is a longer running implementation which is not yet finished. I want to have the urgent fix from change1 in sandbox2, but actually I don't want to checkin the half done implementation in sandbox2 already to workspace2. Am I right that there is no way to achieve that? The place where RTC does the merge is the workspace. So the change2 has to be checkin'd to workspace2 in order to benefit from change1, even if change2 is not yet finished and might even not compile?

Geoffrey Clemm

FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Feb 28 '15, 12:20 p.m.

One key thing to keep in mind is that unlike many SCM systems that only provide a single operation, "checkin", to both persist changes on the server and make those changes visible to other team members, RTC provides two operations: "checkin" and "deliver". The checkin operation is just to persist the changes on the server. The deliver operation is to make those changes visible to other team members. So there is no reason to avoid checking in partial changes, no matter what state they are in (partial, does not compile, whatever). In fact, there is a mode you can specify in Eclipse where it automatically checks in your change as soon as you save it (I do not recommend turning on that mode ... there's no reason to hit the server on every change). But if you want to share a change to another one of your workspaces, then a checkin is always the right thing to do (no matter what state that change is in).

Markus Selve

Mar 03 '15, 7:31 a.m.

I did understand the difference between checkin and deliver on an intellectual level immediately, but many years of using other library systems and the typical policy of the development teams not to checkin code that does not compile, created a mental block for me to checkin unfinished code. But of course in RTC it does no harm in the own server workspace. So now that I understand the way to go to get code merged is through the server workspace, I'll use that way. I'm not using Eclipse, but the command line 'lscm'. So I won't do this automatically, but just do 'lscm accept' (or first 'lscm checkin' then 'lscm accept') when ever I want to include the newest code from the stream in my current development. Thanks a lot for your help with RTC!

showing 5 of 10 show 5 more comments

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.

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers

Answers and Comments

Question details

rational-team-concert

× 43,075

usage

× 12,143

Question asked: Feb 18 '15, 10:20 a.m.

Question was seen: 6,870 times

Last updated: Mar 03 '15, 7:31 a.m.

How to get only the changes done to a file in the sandbox?

3 answers

6,870 views

0 votes

Accepted answer

2 other answers

Comments

Comments

Your answer

Follow this question

Question details

Related questions