It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Follow this question
Question details

×42,787

question asked: Nov 03 '11, 11:16 a.m.
question was seen: 4,091 times
last updated: Aug 14 '13, 6:17 a.m.

Related questions

FAQ - How this Forum works

Why not keep the original date of modification of the source

0
Leandro Leal (146●1●42●45) | asked Nov 03 '11, 11:16 a.m.
Hi!!!!
Why not keep the original date of modification of the source when charging these to a local workspace?

That is the last date of modification of the sources found in the streams is correct but when you download the sources that are a component of a current date of the downloaded font changes, sources have now as the date of last modification the date on which the charge made to my local workspace.

Thanks!

6 answers

Most liked answers ↑|Newest answers|Oldest answers

0
permanent link
Tim Mok (6.6k●3●8) | answered Nov 03 '11, 5:08 p.m.
JAZZ DEVELOPER
Hi!!!!
Why not keep the original date of modification of the source when charging these to a local workspace?

That is the last date of modification of the sources found in the streams is correct but when you download the sources that are a component of a current date of the downloaded font changes, sources have now as the date of last modification the date on which the charge made to my local workspace.

Thanks!

https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/83718

I think that work item is probably what you want. Please voice your opinion in the work item to show that it is important to you.
0
permanent link
Leandro Leal (146●1●42●45) | answered Nov 15 '11, 9:01 a.m.
Good Day we need to know which version will be ready this Enhancement?
0
permanent link
Leandro Leal (146●1●42●45) | answered Nov 15 '11, 10:41 a.m.
We have the 3.0.1 version, or if there is a fix for this problem?.
0
permanent link
Tim Mok (6.6k●3●8) | answered Nov 15 '11, 11:08 a.m.
JAZZ DEVELOPER
We have the 3.0.1 version, or if there is a fix for this problem?.
If you look at the work item, it is marked for backlog (not targeted for a release). If this is important to you, add your support to the work item.
0
permanent link
Leandro Leal (146●1●42●45) | answered Nov 15 '11, 3:52 p.m.
As we deploy to production without changing the date of modification? there another way? this is of great importance for the production pass in our organization
0
permanent link
Davyd Norris (202●2●10●14) | answered Aug 13 '13, 10:23 a.m.
This little nugget of brokenness has just bitten me big time......

I am currently doing some volunteer work for an organisation and am modifying some Open Source code for an application. Being an IBM Rational employee I of course decided to use RTC for my own SCM solution.

The situation I have is that I am taking an active development team's source code, bringing in a release baseline, modifying it for my local client, and then deploying it. In doing this I am finding and fixing my own defects and doing my own enhancements, and am also accepting defect fixes and enhancements from the third party.

I have set up my streams and baselines as per this article: https://jazz.net/library/article/214

I have successfully exported the release baseline from the third party's SCM complete with original file modification timestamps, and have imported it and created my own baseline in RTC (BTW, it's a Python web app and I am using the RTC Eclipse 4.2 client with PyDev loaded). I have now exported a new baseline from the third party's SCM tool that includes a range of defect fixes and enhancements, and have gone to apply them to my vendor stream, only to find that almost EVERY file is flagged as changed in RTC client because the timestamps do not match!! I have gone through all the files in the compare view and the only thing that has changed is the timestamp in RTC :-(

While this is really annoying in the vendor stream, it is impossible in my own local modification stream!! I now have every single file being flagged for a merge when I accept changes from the vendor stream into my own!

I have read all the arguments about timestamps and why the Jazz SCM developers think it's a Bad Idea (tm) to keep them set to the original modification date, despite so many other SCM tools doing it, and frankly I don't really care, but if you are going to mess with the time stamps then you really need to make sure your file comparisons do not include them as the basis for flagging a delta!! Even if the Eclipse client does, RTC should not and should do some sort of hash to determine that the files are actually identical, and then not check them in a second time!!!

It's taken me a week to figure out that it's not the third party SCM exporting badly, it's not my messed up import, it's the Jazz SCM tool messing with the file timestamps (and what is really weird it doesn't seem to be all of them either - it seems to be just the ones that Eclipse knows are text based) and flagging tons of incorrect deltas that mess up everything else downstream.

Please somebody tell me they have found a way around this? Do I have to unload the workspace and 'reshare' the project every single time as per the article? Given I am getting daily changes from the vendor, including my own I am submitting back, this situation is not just untenable, it's ridiculous.

Yup - feeling VERY frustrated right now :-(
Comments
Tim Mok commented Aug 13 '13, 10:37 a.m.
JAZZ DEVELOPER

This sounds like a different problem. Your files shouldn't be marked as unresolved changes when the mod timestamp is the only change. I have made changes locally before and undone them in an editor to find that Pending Changes knows the file hasn't changed.

Davyd Norris commented Aug 13 '13, 5:32 p.m.

Thanks Tim,

I would love this to be a different problem! At the moment I am stumped - the thing that's really strange is that not every file is marked as changed, just most of them.

Does anybody have any suggestions as to how I can start to troubleshoot this issue?

Davyd Norris commented Aug 14 '13, 6:17 a.m.

I think I may be onto something...

I kept thinking about why some but not all files were showing up wrongly as being changed, and I realised all the files that were being wrongly detected were files that Eclipse/RTC knew were text. Files that were unknown or known as binary did not get marked as changed, and not all text files were marked either.

So I had a look, and the third party code appears to have been developed on a Unix system, and the line terminator character is just LF. I'm developing on Windows and so RTC seems to be converting them all to CRLF (following the Platform convention) when they are added to source control.

So it appears when I bring in a new code baseline, the difference in line terminators are throwing the compare off and causing the bogus compare flags.

Since I am submitting code back to the third party vendor, I think I'll have to continue to use Unix style line terminators - is there a way to tell RTC not to change them on import, or to disregard them somehow??

Your answer

Register or to post 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.