佘艳：天堂有你更美丽

天堂有你更美丽

 

    有一个美丽的小女孩，她的名字叫做佘艳，她有一双亮晶晶的大眼睛，她有一颗透亮的童心。她是一个孤儿，她在这个世界上只活了8年，她留在这个世界上最后的话是“我来过我很乖”。她希望死在秋天，纤瘦的身体就像一朵花自然开谢的过程。在遍地黄花堆积，落叶空中旋舞时候，她会看见横空远行雁儿们。她自愿放弃治疗，把全世界华人捐给她的54万元救命钱分成了7份，把生命当成希望的蛋糕分别给了7个正徘徊在生死线的小朋友。

 

    1、我自愿放弃治疗

 

    她一出生就不知亲生父母，她只有收养她的“爸爸”。

    1996年11月30日，那是当年农历10月20日，因为“爸爸”佘仕友在永兴镇沈家冲一座小桥旁的草丛中发现被冻得奄奄一息的这个新生婴儿时，发现她的胸口处插着一张小纸片，上面写着：“10月20日晚上12点。”

    家住四川省双流县三星镇云崖村二组的佘仕友当时30岁，因为家里穷一直找不到对象，如果要收养这个孩子，恐怕就更没人愿意嫁进家门了。看着怀中小猫一样嘤嘤哭泣的婴儿，佘仕友几次放下又抱起，转身走又回头，这个小生命已经浑身冰冷哭声微弱，再没人管只怕随时就没命了！咬咬牙，他再次抱起婴儿，叹了一口气：“我吃什么，你就跟我吃什么吧。”

    佘仕友给孩子取名叫佘艳，因为她是秋天丰收季节出生的孩子。单身汉当起了爸爸，没有母乳，也买不起奶粉，就只好喂米汤，所以佘艳从小体弱多病，但是非常乖巧懂事。春去春又回，如同苦藤上的一朵小花，佘艳一天天长大了，出奇得聪明乖巧，乡邻都说捡来的娃娃智商高，都喜欢她。尽管从小就多病，在爸爸的担惊受怕中，佘艳慢慢地长大了。

    命苦的孩子的确不一般，从5岁起，她就懂得帮爸爸分担家务，洗衣、煮饭、割草她样样做得好，她知道自己跟别家的孩子不一样，别家的孩子有爸爸有妈妈，自己的家里只有她和爸爸，这个家得靠她和爸爸一起来支撑，她要很乖很乖，不让爸爸多一点点忧心生一点点气。

    上小学了，佘艳知道自己要好学上进要考第一名，不识字的爸爸在村里也会脸上有光，她从没让爸爸失望过。她给爸爸唱歌，把学校里发生的趣事一样一样讲给爸爸听，把获得的每一朵小红花仔仔细细贴在墙上，偶尔还会调皮地出道题目考倒爸爸……每当看到爸爸脸上的笑容，她会暗自满足：“虽然不能像别的孩子一样也有妈妈，但是能跟爸爸这样快乐地生活下去，也很幸福了。”

    2005年5月开始，她经常流鼻血。有一天早晨，佘艳正欲洗脸，突然发现一盆清水变得红红的，一看，是鼻子里的血正向下滴，不管采用什么措施，都止不住。实在没办法，佘仕友带她去乡卫生院打针，可小小的针眼也出血不止，她的腿上还出现大量“红点点”，医生说，“赶快到大医院去看！”来到成都大医院，可正值会诊高峰，她排不上轮次。独自坐在长椅上按住鼻子，鼻血像两条线直往下掉，染红了地板。他觉得不好意思，只好端起一个便盆接血，不到10分钟，盆子里的血就盛了一半。

    医生见状，连忙带孩子去检查。检查后，医生马上给他开了病危通知单。她得了“急性白血病”！这种病的医疗费是非常昂贵的，费用一般需要30万元！佘仕友懵了。看着病床上的女儿，他没法想太多，他只有一个念头：救女儿！借遍了亲戚朋友，东拼西凑的钱不过杯水车薪，距离30万实在太远，他决定卖掉家里唯一还能换钱的土坯房。可是因为房子太过破旧，一时找不到买主。

    看着父亲那双忧郁的眼睛和日渐消瘦的脸，佘艳总有一种酸楚的感觉。一次，佘艳拉着爸爸的手，话还未出口眼泪却冒了出来：“爸爸，我想死……”

    父亲一双惊愕的眼睛看着她：“你才8岁，为啥要死？”

   “我是捡来的娃娃，大家都说我命*，害不起这病，让我出院吧……”

    6月18日，8岁的佘艳代替不识字的爸爸，在自己的病历本上一笔一画地签字：“自愿放弃对佘艳的治疗。”

 

    2、8岁女孩乖巧安排后事

 

    当天回家后，从小到大没有跟爸爸提过任何要求的佘艳，这时向爸爸提出两个要求：她想穿一件新衣服，再照一张相片，她对爸爸解释说：“以后我不在了，如果你想我了，就可以看看照片上的我。”

    第二天，爸爸叫上姑姑陪着佘艳来到镇上，花30元给佘艳买了两套新衣服，佘艳自己选了一套粉红色的短袖短裤，姑姑给她选了一套白色红点的裙子，她试穿上身就舍不得脱下来。三人来到照相馆，佘艳穿着粉红色的新衣服，双手比着V字手势，努力地微笑，最后还是忍不住掉下泪来。

    她已经不能上学了，她长时间背着书包站在村前的小路上，目光总是湿漉漉的。

    如果不是《成都晚报》的一个叫傅艳的记者，佘艳将像一片悄然滑落的树叶一样，静静地从风中飘下来。

    记者阿姨从医院方面得知了情况，写了一篇报道，详尽叙说佘艳的故事。旋即，《8岁女孩乖巧安排后事》的故事在蓉城传开了，成都被感动了，互联网也被感动了，无数市民为这位可怜的女孩心痛不已，从成都到全国乃至全世界，现实世界与互联网空间联动，所有爱心人士开始为这个弱小的生命捐款，“和谐社会”成为每个人心中的最强音。短短10天时间，来自全球华人捐助的善款就已经超过56万元，手术费用足够了，小佘艳的生命之火被大家的爱心再次点燃！宣布募捐活动结束之后，仍然源源不断收到全球各地的捐款。所有的钱都到位了，医生也尽自己最大努力，一个接一个的治疗难关也如愿地一一闯过！大家沉着地微笑着等待成功的那一天！有网友如是写道：“佘艳，我亲爱的孩子！我希望你能健康的离开医院；我祈祷你能顺利的回到学校；我盼望你能平安的长大成人；我幻想我能高兴的陪你出嫁。佘艳，我亲爱的孩子……”

    6月21日，放弃治疗回家等待死神的佘艳被重新接到成都，住进了市儿童医院。钱有了，卑微的生命有了延续下去的希望和理由。

    佘艳接受了难以忍受的化疗。玻璃门内，佘艳躺在病床上输液，床头旁边放着一把椅子，椅子上放一个塑料盆，她不时要侧身呕吐。小女孩的坚强令所有人吃惊。她的主治医生徐鸣介绍，化疗阶段胃肠道反应强烈，佘艳刚开始时经常一吐就是大半盆，可她“连吭都没吭一声”。刚入院时做骨髓穿刺检查，针头从胸骨刺入，她“没哭，没叫，眼泪都没流，动都不动一下”。

    佘艳从出生到死亡，没有得到一丝母爱的关照。当徐鸣医生提出：“佘艳，给我当女儿吧！”佘艳眼睛一闪，泪珠儿一下就涌了出来。第二天，当徐鸣医生来到她床前的时候，佘艳竟羞羞答答地叫了一声：“徐妈妈。”徐鸣开始一愣，继而笑逐颜开，甜甜地回了一声：“女儿乖。”

    所有的人都期待奇迹发生，所有的人都在盼望佘艳重生的那一刻。很多市民来到医院看望佘艳，网上很多网民都在问候这位可怜的孩子，她的生命让陌生的世界撒满了光明。那段时间，病房里堆满了鲜花和水果，到处弥漫着醉人的芬芳。

    两个月化疗，佘艳陆续闯过了9次“鬼门关”，感染性休克、败血症、溶血、消化道大出血……每次都逢凶化吉。由省内甚至国内权威儿童血液病专家共同会诊确定的化疗方案，效果很好，“白血病”本身已经被完全控制了！所有人都在企盼着佘艳康复的好消息。但是，化疗药物使用后可能引起的并发症非常可怕。而与别的很多白血病孩子比较，佘艳的体质差很多。经此手术后她的体质更差了。

    8月20日清晨，她问傅艳：“阿姨，你告诉我，他们为什么要给我捐款？”

   “因为，他们都是善良人。”

   “阿姨，我也做善良人。”

   “你自然是善良人。善良的人要相互帮助，就会变得更加善良。”

    佘艳从枕头下摸出一个数学作业本，递给傅艳：“阿姨，这是我的遗书……”

    傅艳大惊，连忙打开一看，果然是小佘艳安排的后事。这是一个年仅8岁的垂危孩子，趴在病床上用铅笔写了三页纸的《遗书》。由于孩子太小，有些字还不会写，且有个别错别字。看得出整篇文章并不是一气呵成写完的，分成了六段。开头是“傅艳阿姨”，结尾是“傅艳阿姨再见”，整篇文章“傅艳阿姨”或“傅阿姨”共出现7次，还有9次简称记者为“阿姨”。这16个称呼后面，全部是关于她离世后的“拜托”，以及她想通过记者向全社会关心她的人表达“感谢”与“再见”。

   “阿姨再见，我们在梦中见。傅艳阿姨，我爸爸房子要垮了。爸爸不要生气，不要跳楼。傅阿姨你要看好我爸爸。阿姨，医我的钱给我们学校一点点，多谢阿姨给红十字会会长说。我死后，把剩下的钱给那些和我一样病的人，让他们的病好起来……”

    这封遗书，让傅艳看得泪流满面，泣不成声。

   

    3、我来过，我很乖

 

    8月22日，由于消化道出血，几乎一个月不能吃东西而靠输液支撑的佘艳，第一次“偷吃东西”，她掰了一块方便面塞进嘴里。很快消化道出血加重，医生护士紧急给她输血、输液……看着佘艳腹痛难忍、痛苦不堪的样子，医生护士都哭了，大家都愿意帮她分担痛苦，可是，想尽各种办法还是无济于事。

    8岁的小佘艳终于远离病魔的摧残，安详离去。

    所有人都无法接受这个事实：那个美丽如诗、纯净如水的“小仙女”真的去了另一个世界吗？记者傅艳抚摸着佘艳渐渐冰冷的小脸，泣不成声，再也不能叫他阿姨了，再也不能笑出声来了……

    四川在线等网站沉浸在泪海里，互联网被泪水打湿透了，“心痛到不能呼吸”。每个网站的消息帖子下面都有上万条跟帖，花圈如山，悼词似海，一位中年男士喃喃低语：“孩子，你本来就是天上的小天使，张开小翅膀，乖乖地飞吧……” 8月26日，她的葬礼在小雨中举行，成都市东郊殡仪馆火化大厅内外站满了热泪盈眶的市民。他们都是8岁女孩佘艳素不相识的“爸爸妈妈”。为了让这个一出生就被遗弃、患白血病后自愿放弃自己的女孩，最后离去时不至于太孤单，来自四面八方的“爸爸妈妈们”默默地冒雨前来送行。

她墓地有她一张笑吟吟的照片，碑文正面上方写着：“我来过，我很乖(1996.11.30.--2005.8.22)”

    后面刻着关于佘艳身世的简单介绍，最后两句是：“在她有生之年，感受到了人世的温暖。小姑娘请安息，天堂有你更美丽。”

    遵照小佘艳的遗愿，把剩下的54万元医疗费当成生命的馈赠留给其他患白血病的孩子。这7个孩子分别是杨心琳、徐黎、黄志强、刘灵璐、张雨婕、高健、王杰。这七个可怜的孩子，年龄最大的19岁，最小的只有2岁，都是家境非常困难，挣扎在死亡线上的贫困子弟。

    9月24日，第一个接受佘艳生命馈赠的女孩徐黎在华西医大成功进行手术后，她苍白的脸上挂上了一丝微笑：“我接受了你生命赠与，谢谢佘艳妹妹，你一定在天堂看着我们。请你放心，以后我们的墓碑上照样刻着：我来过，我很乖……”

在中国不知有多少这样不幸的家庭？！谁是我们的摩西？指引我们，让我们看到希望?!

祝所有善良的人们幸福平安！！！

Undo a Deliver Operation

Undo a Deliver Operation

 

Any time before completing the deliver operation, you can undo changes made as a result of the operation. This undo procedure is valid only if you have started a deliver operation, have not checked in modifications in the target view, and have not completed the deliver operation.

 

An undo deliver command is provided, which cancels all checkouts in the integration view and removes all merge arrows created during the current deliver operation.

 

If you checked in any versions to the integration view, using the undo deliver command is not sufficient to undo the deliver operation. In this case, you must either complete the operation (recommended) or use cleartool rmver -xhlink to remove the versions you checked in before canceling the operation. Because rmver erases part of your organizational development history, your organization may not allow individual developers to use it. Be very conservative in using this command, especially with the -xhlink option, which may have unintended consequences.

File Merge Algorithm

File Merge Algorithm

 

A merge combines the contents of two or more versions into a single new version. Before know how the merge works, we need know below terms:

 

• The source contributors: one version from your development stream and one version from the target stream.
• The base contributors: the common ancestor of the source versions.
• The destination version: the merge output, which in a deliver operation becomes a new version in the target stream and in a rebase operation becomes a new version in the development stream

How files and directory are merged

To merge files and directories:

1. The base contributor is identified.
2. Each contributor is compared with the base contributor using the Rational ClearCase merge algorithm.
3. For any line that is unchanged between the base contributor and any other contributor, the line is copied to the merge output file.
4. For any line that has changed between the base contributor and one other contributor, the change in the contributor is accepted. Depending on how you started the merge operation, the change may be copied to the merge output file. However, you can disable the automated merge capability for any merge operation. If you disable the capability, you must approve each change to the merge output file.
5. For any line that has changed between the base contributor and more than one other contributor, you are required to resolve the conflicting difference manually.

About Baseline Considerations in the Deliver Operation

About Baseline Considerations in the Deliver Operation

 

If the foundation baseline of the source stream is different from that of the target stream, the deliver operation includes activities in the foundation baseline plus all activities created after the foundation baseline. This baseline difference prevents you from delivering only selected changes.

 

S1. For example, the Feature stream in figure below is configured with baseline 0. The developer working in the Developer1 stream delivers activity Activity1 to the Feature stream.

 

 

 

The owner of the Feature stream creates baseline 1 in that stream. Activity1 is included in baseline 1. The developer in the Developer1 stream continues working on a new activity and delivers activity Activity2 to the Feature stream.

 

If the integrator of the Feature stream delivers work to the Integration stream, the deliver operation includes Activity2 plus the activities in included in baseline 1. The integrator can not deliver only Activity2.

 

 

S2. Another baseline consideration arises when you deliver to an alternative target stream, as shown in the figure below.

The Developer1 stream delivers Activity1 to an alternative target, the Integration2 stream. As an intermediate step, the deliver operation creates a hidden baseline D (referred to as a deliver baseline) in the Developer1 stream. If the Developer1 stream next tries to deliver only Activity2 to the Integration1 stream, the deliver operation requires that the changes associated with the deliver baseline (Activity1) be delivered. In this case, you can not deliver only activity2, but must deliver Activity1 (which is included in the deliver baseline) also.

Handling Elements That Are Not Visible During a deliver (or rebase) Operation

Handling Elements That Are Not Visible

 

During a deliver (or rebase) operation, you might see the following warning message about elements not being visible in the integration view:

 

1 elements were skipped because they are not visible. You should determine why they are not visible before you complete this deliver or rebase operation. If these elements should be visible, cancel this operation, fix the problem, and re-run the operation

 

Do not ignore this message. The deliver operation found versions of elements in the development stream that need to be considered for merging to the target stream, but does not find the elements in the target stream. The following cases are some reasons for this situation:

 

• A new element was added to source control, but the directory that catalogs the element is not checked in. In this case, cancel this deliver (or rebase) operation, check in the directory, and start a new deliver (or rebase) operation.

 

• While a change to the element was being made(in the development stream, for a deliver operation; in the stream from which you are rebasing, for a rebase operation), someone operated on the element ( in the target stream, for a deliver operation; in the development stream, for a rebase operation), as follows:

 

®      The name of the element or the name of a VOB symbolic link to the element was removed.

®      The element itself or the VOB symbolic link to the element was removed.

In either of these cases, decide whether the removal was appropriate. If the removal was appropriate, you can allow the deliver (or rebase) operation to ignore the element.

 

• The change may be obsolete because you intended or remove the name of the element or the element itself.

 

Because the cause of the problem can not be determined by the deliver or rebase operation, you must find the cause, fix the problem, cancel the current deliver9or rebase)operation, and start a new operation.

 

About Higacked Files

What is HiJacked Files

The hijacked file is the file which is modified but without checked-out. In the ClearCase, only checked-out files can be edited and saved after updating.  All elements in CC source control are give the file attribute of read-only. When the file is checked out, the ready-only attribute is cleared and it can be modified then. In Dynamic List view, the file attribute can not be changed while it can in snapshot view somehow. So the hijaced file is only for Snapshot view.

 

 

Hijacked Files Operations when Update The Snapshot View

When you update the snapshot view, you have these choices for the hijacked files:

• Leave hijacked files in place
• Rename the hijacked files and load the selected version form the VO
• Delete hijacked files and load the selected version from the VOB

 

 

The procedure of the deliver operation

The procedure of the deliver operation

 

The deliver operation proceeds in the following order:

 

1. When you start the deliver operation, your development stream is placed in the deliver-in-progress state.  
2. Dependencies between versions in the change sets of the activities that are as yet undelivered in the target stream are checked.  
3. Each directory in your development stream is evaluated sequentially. Versions are checked out and changes are merged to the target stream when needed. If a reserved directory checkout is encountered in the target stream, the deliver operation stops. Any successful directory merges are retained.  
4. An attempt is made to check out each element that requires a merge. If an element that cannot be checked out is encountered (for example because another team member’s deliver operation has already checked out the element), the element is skipped and more attempts are made to check out the remaining elements.  
5. If an element cannot be checked out, the deliver operation does not proceed to the following step. In this case, you have two options:  
• Wait until the other developer completes or cancels the deliver operation, and then restart your deliver operation. However, with a deliver operation in progress, any new versions you create in your development stream are not delivered until the next deliver operation.
• Undo your deliver operation and continue working on your activities. 
6. After all elements that can be checked out are successfully checked out, each element is merged. Diff Merge starts and requests your input when merge conflicts are encountered.  
7. When all merges are finished, you are prompted to build and test the work in your integration view.  
8. The deliver operation stays in the deliver-in-progress state until you formally complete the operation (issue the complete command). To complete the deliver, the following is done:  
• The merge results in the target stream are checked in.
• The state of the stream is changed to Complete.

 

Delete activities when ClearQuest Record is linked with a UCM activity

Delete activities when ClearQuest Record is linked with a UCM activity

 

You can enable ClearQuest and ClearCase integration to manage the developement process. ClearQuest is used as a defect tracking tool and ClearCase is used as source control repository. If a Rational ClearQuest record is linked with a UCM activity and you want to delete the activity, you should do:

• Remove the link between UCM activity and ClearQuest records (In ClearCase side)
• Delete ClearQuest records(in ClearQuest side)

Before you remove the link between UCM activity and ClearQuest records, below requisiton must be fulfilled:

• no changeset in that activity. If yes, move the change sets to other activity
• the operator to do this must be the owner of the ClearQuest record. Not the submitter but the owner

Then you can use below command to remove the link

cleartool rmactivity clearquest_record_id

 

executing above command does not delete the ClearQuest record. So you must login the ClearQuest and do the Delete action then. The access control of the Deletion is defined in the ClearQuest schema. You should ask the ClearQuest admin to confirm if you have the right to delete the record.

 

 

How file/directory checkouts are canceled

 

How file/directory checkouts are canceled

How file checkouts are canceled

• When you cancel the checkout of a file element, the request is handled as follows:
• You have prompted to rename the fie in your view to filename.keep
• The VOB is notified that you no longer have the version checked out in your view
• In a snapshot view, the version that was in your view when you performed the checkout operation is copied from the VOB
• In a dynamic view, the version-selection rules in the config spec are used to select a version.

 

How directory checkouts are canceled

• When you cancel a directory checkout, the VOB is notified that you no longer have the version of the directory checked out to your view. But you are not prompted to rename a canceled directory checkout to directory-name.keep.
• If you cancel a directory checkout after any changes you made to rename,move, create link will lost. Any new elements you created (with mkelem or mkdir) become orphaned. But pls note that if you just only modify the content (add/remove/update lines) in the file and check in the file, the file version and its content is still there although you undo check out against that folder.

 

Orphaned elements are moved to the VOB lost+found directory under names of this form:

element-anme.UUID

 

In a snapshot view, view-private objects are not removed nor is the update operation for the directory in the view started. To return the directory in your view to its state before you checked it out, you must start the Update Tool.

Action	Result after undo checkout its parent directory	Input into lost+found
rename element	stay in the view but the Kind is view-private	No
create dir and add to source control	stay in the view but the Kind is view-private	Yes
create element and add to source control	stay in the view but the Kind is view-private	Yes
create link and add to source control	stay in the view but the Kind is view-private	No
delete element	can not show again until you update the view	No

 

 

In a dynamic view, view-private objects are not removed, but the view does revert to its previous state.

Action	Result after undo checkout its parent directory	Input into lost+found
rename element	recover the name to its previous one	No
create dir and add to source control	dispear	Yes
create element and add to source control	dispear	Yes
create link and add to source control	dispare	No
delete element	show again	No

 

To move the elements from the lost+found directory

• To move an element from the lost+found directory to another dirctory within the VOB, use the cleartool mv command.
• To move an element from the lost+found directory to another VOB, use the relocate command.

 

To delete an element in the lost+found directory

• To delete an element in the lost+found directory permanently, use rmelem command.

 

Checking out directory

Checking out directory

Directories and files under Rational ClearCase source control. Having versions of directories can be helpful if, for example,you rename a source file used in a particular release and then modify your makefile to reflect this change. If you need to rebuild a previous release, you can set up your view to sleect the version of the directory that contains the file under its previous name.

 

On Unix system

To add a file or subdirectory to Rational ClearCase control, you must first check out the parent directory. It is common mistake that, after checking out a parent directry and adding elements to it, users forget to check in the directory. If you check out a directory, you can see its modified contents form your view, but other users can not see the modifications until you check in it.

 

On Windows system

You rarely need to check out a directory explicitly. The parent directory of a file is checked out and checked in when you add the file to source control. in a directory under version control, a new version of the directory is created when you add or rename a file element under source control. Before you modify the contend in the view, if you check out the parent directory explicitly, you can see its modified contents from your view, but other users can not see the modifications until you check in it.

 

Modifications here means the operations of mkdir,mkelement,rename,ln and exclude the operations that only update the contents in the source files

 

Reserved and Unreserved Checkouts

Reserved and Unreserved Checkouts

In some version control systems, only one user at a time can reserve the right to create a new version on a branch or in a stream. In other systems, many users can compete to create the same new version.Both models are supported by allowing tow kinds of checkouts: reserved and unreserved.

 

The view with a reserved checkout has the exclusive right to check in a new version for a branch or stream. Many views can have unreserved checkouts. A unreserved checkout does not guarantee the right to create the successor version. If several views have unreserved checkouts, the first view to check in the element on a branch or stream creates the successor; developers who arew working in other views must merge the check-in changes into their own work before they can check in.

 

For example, one file in view A is checked out with Reserved option. The file is checked out in view B with Unreserved option too ( only can be checked out with Unreserved option since it has been Reserved by view A). That means the file in view B can not be checked in unless the files in View A has been checked-in.

 

In above example, if the file is checked out in View A and B with Unreserved option, it can be checked in at any time without considering the check-in sequence. The first check-in makes the successor version and later one will create antoher version after merge operation.

 

The status of a checkout can be changed from reserved to unreserved or from unreserved to reserved. Users can not change an unresearved checkout to a reserved checkout if the version is checked out as reserved in another view. Here are the 2 ways to do this

• • Using cleartool command

  Cleartool reserve element-name

  Cleartool unreserved element-name

• • Using the GUI

  In Rational ClearCase Explorer, select the checked-out version and click either Tools->Reserve or Tools->Unreserve

  In Windows Explorer, right-click a checked-out version. Then click ClearCase->Properties of Version.

Text Mode in ClearCase

Text Mode in ClearCase

 

Text modes in Rational ClearCase views are necessary because lines in text files are terminated differently on different platform types. The text mode of a view determines how lines in text files under Rational ClearCase control are processed, independent of the platform that the view storage, the VOB server, or the client runs on.

 

Linux and the UNIX system and Windows observe different conventions for terminating lines in text files. Typically, Linux and the UNIX system terminate lines with a single <LF> character and Windows systems terminate lines with a two-character sequence <CR><LF>.

 

To better support parallel development in mixed operationg system environments,a text mode setting for views in provided that controls how line terminators are handled when text files are presented to applications.This setting applies only to file elements whose element type is text_file or a subtype of type text_file. You determine a view text mode when you create the view. You can not change the text mode fo a view after the view has been created.

 

Text Modes

transparent (formerly unix) No line terminator processing is done.

insert_cr (formerly msdos) A <CR> character is inserted before every <LF> character.

strip_cr The <CR> character is stripped from every <CR><LF> sequence.

 

Sitewide property and Rational ClearCase user option for text mode on Windows computers

On windows computers, the sitewide property view_interop_text_mode in a Rational ClearCase registry determines the default text mode when you create a view with the GUI. If view_interop_text_mode is set to True, insert_cr text mode is the default. If view_interop_text_mode is set to False, transparent text mode is the default. The cleartool lssite -inquire command lists the current value.

 

On windows computers, in the View Options page in the ClearCase User Options window, you can specify a preference that determines the default text mode when you create a view with the GUI. if you set interop text mode, insert_cr text mode is the default. If you clear interop text mode, transparent text mode is the default. The preference can override the default for the site-wide property view_interop_text_mode.

C:\Program Files\Rational\ClearCase\bin\cleardlg.exe  /options

 

In a snapshot view created in either insert_cr or strip_cr text mode, the <CR> characters are added or removed whenever the view is updated. In a dynamic view, the <CR> characters are added or removed as you open and read files. For both snapshot views and dynamic views, the <CR> manipulation is reversed (<CR> characters being added or removed as appropriate) during the checkin process.

 

If most users are developing software on UNIX systems:

• UNIX clients should use views created in transparent text mode.
• Windows clients should use views created in insert_cr text mode.

If most users are developing software on Windows systems:

• Windows clients should use views created in transparent text mode.
• UNIX clients should use views created in strip_cr text mode.