In Siebel version control can be performed on Siebel projects (SIFs):

1) A developer checks out a Siebel project from the Siebel repository
(here is no trigger so no CC activity)
2) Works on it
3) The developer checks in a Siebel project in Siebel, on a check in ,
Siebel fires a trigger:
4) "under water" a temporary XML file is written to a
temporary directory.
5) Siebel calls a batch file that calls a ClearCase perl script that
checks in that file in the stream that is defined for the user (and
in our case also pops up a pulldown menu to choose the activity he
was working on)
(e.g. the batch file as written by David Bellagio in 2004)

Since these Siebel SIF XML files may not be merged outside of Siebel
and e.g. can be compared to "word documents" (to give the
mindset) we defined just 1 stream where all developers work in. A
file is never checked out longer than a few seconds since it only
occurs when the Siebel developer checks in that project in Siebel and
since we set up
dynamic views their view is always up to date.

In other words: these Siebel developers never ever even know that
there is something called "clearcase" installed on their
machines. (Since it is not handy to checkin a file in Siebel and then
again go to another tool to perform the same checkin).

If e.g. another developer (after the checkin of the previous
developer) decides to work on a certain Siebel project it always
works. The previous developer checked it in (in Siebel and therefore
CC) and therefore never
conflicts arise.

Now....... how would we implement this use case in RTC?

My assumption is that is pretty hard or even impossible without
dynamic views but I would really like to be proven wrong.

1. I think that the developer in Siebel will now have to make sure a
"complete local copy" (all Siebel projects) are in his
Eclipse Workspace, which can be a lot.
2. I think that the developer in Siebel will now have to go to RTC to
commit his changes to the repository (deliver) to promote his change
set to
(hopefully) the same common stream before other members can work on
the same SIFs
2.a. He has to do that after each check in of a Siebel-Project (SIF)
because a minute later another developer could be working on the same
SIF. (remember merges are not possible)
3. All other members need to load their Eclipse workspace after each
change of each other members since the Siebel projects are worked on
continuously be different members.

So a use case in which we want to prevent doing double work in both
Siebel and RTC AND "hide" the versioning layer under here
is not possible I think / not a good idea.

Ideas / Alternatives / Possible / Not Possible?

p.s.: My thought until now is: if it is possible to automate load,
sycn, accept all, change changeset, (then copy file from temp
directory), checkin, deliver (of always every changeset) etc... in
one script (just to have 1 stream updating behind the users back) it
may be possible to don't bother the Siebel user though it may take
some time for each checkin of a proejct he performs during the day.
(this is not the only use case, there will dozens of these operations
a user performs a day also on other objects). We will have to let him
choose a) the particular change he is working on and b) the
particular stream he is working in though.

gmclemmwrote:
I didn't see anything in your description that depends on dynamic
views
.... what did I miss? In particular, it looks like the main point
is
that a Siebel checkin time, you want to fire off a script that
silently
puts things into the version control system. Since RTC has a
command
line, you should be able to do the same thing for RTC.

I think it means:

1. developers now have to start by going to RTC, go to their project
stream, and then load thousands of XML's in their workspace while
previously this was a few seconds connecting to the right dynamic
view
(its difficult to determine what to load in front because working in
the gui<> physical exported xmls).

2. it also means that before each update of someone else they have to
re-load these things locally to stay in sync and to prevent identical
new files re-entering the system.

3. with dynamic views no locking was necessary since during the siebel
checkin process no other user can access these files. Even if you
would lock a file in RTC it has no meaning in Siebel (where the work
is done) since the lock does not exist there.