Is there something like clearfsimport in RTC?

Check this video

https://jazz.net/library/video/100

Hi

If we just want to move a few baselines from ClearCase to RTC, is there a command line tool like clearfsimport to import the files recursively from file system to RTC?

Thanks
Jirong

Thanks for the info, but this is just as good for the initial load, we need a tool to import files recursively to lay one version on top of another.

Jirong

As it is a snapshot view and the version of file which are already in the repository is available in your workspace. if you copy over the local dir structure in the workspace all this files will be shown as required to be checked in and deliver in outgoing. Once you checkin and deliver you will have a new version over the previous version.

Just tried with one folder and it worked. try out in your test area and see if it works for you or not

clearfsimport works great from dynamic views but here we do not have concept of dynamic views

Thanks for the info, but this is just as good for the initial load, we need a tool to import files recursively to lay one version on top of another.

Jirong

Thanks for your reply. That clarifies a lot.

Now I have another question: why bother using CC Importor if this works?

When we say we want to import 10 baselines from CC with history using CC Importor, does it create 10 versions (versions included in these 10 baselines) in RTC or all versions an element has? If it only create 10 versions, then what does the history mean here? and why not just using the approach we described instead of using CC Importor? What else CC importor give?

Thanks
Jirong

The main thing you gain with the CC importer is file/directory
renames/moves. The CC Importer will detect that a file/directory has
been renamed, but with the file system import, it will look like the
original file/directory has been deleted, and a new file/directory has
been created in the new location. This is especially noticeable with a
directory move, when a whole tree of files appear to have been deleted,
and a whole new tree of files have been created. This is especially
problematic of you are trying to import more than one stream/branch of
the same component/vob. Capturing renames properly is necessary if you
want to do any merging between those imported streams/branches.

But if none of those issues concern you, then importing directly from
the file system is certainly faster.

Cheers,
Geoff

On 7/12/2011 5:23 PM, hujirong wrote:

Thanks for your reply. That clarifies a lot.

Now I have another question: why bother using CC Importor if this
works?

When we say we want to import 10 baselines from CC with history using
CC Importor, does it create 10 versions (versions included in these
10 baselines) in RTC or all versions an element has? If it only
create 10 versions, then what does the history mean here? and why not
just using the approach we described instead of using CC Importor?
What else CC importor give?

Thanks
Jirong

As it is a snapshot view and the version of file which are already in the repository is available in your workspace. if you copy over the local dir structure in the workspace all this files will be shown as required to be checked in and deliver in outgoing. Once you checkin and deliver you will have a new version over the previous version.

Just tried with one folder and it worked. try out in your test area and see if it works for you or not

This is what I did:

1. Create two snapshot views to a label and the latest.
2. New a project in RTC project explorer, pointing to the label snapshot.
3. Share the above project into RTC.
4. Copy and lay the latest snapshot view folders/files on top of the project. It created an Unresolved changes.

The problem is when I look into the Unresolved Changes. It has more than I expected. In my case, the latest purely added some new folders and files and no other changes at all. Very simple.

e.g. in the screenshot below, the first files in listed in Unresolved Changes but they are no different. What's wrong here? How RTC detects the different here? By size, content or timestamp?

http://i43.tinypic.com/2e56ovd.png

On the files that show as changed in the pending changes view, what do
you get when you double click on that line (which normally would open up
the diff editor and show you the changes). Does it say "files are the
same"? If so, you probably will need to work with support (this worked
fine for me when I tried it).

Cheers,
Geoff

On 11/7/2011 12:23 PM, hujirong wrote:

mehulnpwrote:
As it is a snapshot view and the version of file which are already in
the repository is available in your workspace. if you copy over the
local dir structure in the workspace all this files will be shown as
required to be checked in and deliver in outgoing. Once you checkin
and deliver you will have a new version over the previous version.

Just tried with one folder and it worked. try out in your test area
and see if it works for you or not

This is what I did:

1. Create two snapshot views to a label and the latest.
2. New a project in RTC project explorer, pointing to the label
snapshot.
3. Share the above project into RTC.
4. Copy and lay the latest snapshot view folders/files on top of the
project. It created an Unresolved changes.

The problem is when I look into the Unresolved Changes. It has more
than I expected. In my case, the latest purely added some new folders
and files and no other changes at all. Very simple.

e.g. in the screenshot below, the first files in listed in Unresolved
Changes but they are no different. What's wrong here?

http://i43.tinypic.com/2e56ovd.png

On the files that show as changed in the pending changes view, what do
you get when you double click on that line (which normally would open up
the diff editor and show you the changes). Does it say "files are the
same"? If so, you probably will need to work with support (this worked
fine for me when I tried it).

Cheers,
Geoff/quote]

No, it said nothing, just display as follows, seems same content. Is there a different line ending issue?

http://i41.tinypic.com/ci2l3.png

Another thing I don't understand is: in Beyond Compare 3, when I compare the ss view and temp dir after sharing (it's actually becomes the sandbox), it lists all these files as different (compare file size), but right after you double click into the file to compare the content (they are the same), they disappear from the difference list. Then when I go back to check the file size, it changed back to the original (before sharing) again!!!

If I compare them using content, they are the same.

http://i43.tinypic.com/14xo54w.png

Having the pending change disappear after you double click on it is not
something I've ever seen. If you can reproduce, please submit as a
work item so the development team can take a look.

Cheers,
geoff

On 11/8/2011 3:23 PM, hujirong wrote:

On the files that show as changed in the pending changes view, what
do
you get when you double click on that line (which normally would
open up
the diff editor and show you the changes). Does it say "files
are the
same"? If so, you probably will need to work with support
(this worked
fine for me when I tried it).

Cheers,
Geoff/quote]

No, it said nothing, just display as follows, seems same content. Is
there a different line ending issue?

http://i41.tinypic.com/ci2l3.png

Another thing I don't understand is: in Beyond Compare 3, when I
compare the ss view and temp dir after sharing (it's actually becomes
the sandbox), it lists all these files as different (compare file
size), but right after you double click into the file to compare the
content (they are the same), they disappear from the difference
list.

If I compare them using content, they are the same.

http://i43.tinypic.com/14xo54w.png

Having the pending change disappear after you double click on it is not something I've ever seen. If you can reproduce, please submit as a
work item so the development team can take a look.

Cheers,
geoff

You mixed two things.

1. Double click the file in RTC shows no message like "file are identical" (to answer your question). It just displace these two files as that screen shot.

2. Double click the file in Beyond Compare make it disappear. Further investigation shows after double click the file, the size of file changed back to 17 (so now BC thinks it's same).

Finally I compare the Hex and found the 0A0D and 0A different, but don't know why? https://www.ibm.com/developerworks/forums/thread.jspa?messageID=14701907&#14701907

Thanks
Jirong