[Siebel] Workaround for typical dynamic views functionality
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.
So (free thinking): a script that simulates what a dynamic view does (from an end user point of view) e.g. scm checkin, scm deliver, scm accept etc... along with a popup that requests the stream/change.
p.p.s. : this script relates to my label question here: http://jazz.net/forums/viewtopic.php?p=45136#45136 since we use that also in our scripts (to set these automatically on latest versions).
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.
So (free thinking): a script that simulates what a dynamic view does (from an end user point of view) e.g. scm checkin, scm deliver, scm accept etc... along with a popup that requests the stream/change.
p.p.s. : this script relates to my label question here: http://jazz.net/forums/viewtopic.php?p=45136#45136 since we use that also in our scripts (to set these automatically on latest versions).
4 answers
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. One of the
points you raise is that you need to prevent branching of certain files.
In RTC, you would achieve that by "locking" those files (while in
ClearCase, you would "checkout" those files).
Cheers,
Geoff
On 11/4/2010 12:53 PM, edelwater wrote:
.... 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. One of the
points you raise is that you need to prevent branching of certain files.
In RTC, you would achieve that by "locking" those files (while in
ClearCase, you would "checkout" those files).
Cheers,
Geoff
On 11/4/2010 12:53 PM, edelwater wrote:
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.
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.
on 1: Yes, with anything but dynamic views, you do need to download the
files. Note that RTC is very fast at loading files, and with RTC, you
can usually re-use a single repository workspace for a variety of
related purposes, so you usually are only paying for an "incremental
update", as opposed to a full load. Note: I am not in any way saying
that for various use cases, dynamic views are not essential. That's
why Rational will always be enhancing and selling ClearCase, for
customers that need it.
on 2: Yes, users need to keep their loaded files up to date (that's true
for any SCM system other than ClearCase).
on 3: Yes, ClearCase does make sure nobody by mistake tries to modify a
file that shouldn't be modified. There is a work item to improve how
RTC handles this ... work item 89703. Please feel free to add a
comment indicating your interest/support.
Cheers,
Geoff
On 11/7/2010 1:23 AM, edelwater wrote:
files. Note that RTC is very fast at loading files, and with RTC, you
can usually re-use a single repository workspace for a variety of
related purposes, so you usually are only paying for an "incremental
update", as opposed to a full load. Note: I am not in any way saying
that for various use cases, dynamic views are not essential. That's
why Rational will always be enhancing and selling ClearCase, for
customers that need it.
on 2: Yes, users need to keep their loaded files up to date (that's true
for any SCM system other than ClearCase).
on 3: Yes, ClearCase does make sure nobody by mistake tries to modify a
file that shouldn't be modified. There is a work item to improve how
RTC handles this ... work item 89703. Please feel free to add a
comment indicating your interest/support.
Cheers,
Geoff
On 11/7/2010 1:23 AM, edelwater wrote:
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.
Thanks for your answers :)
As an addition to 3 (and for others interested in the same question):
it even does not matter if clearcase locks / reserve checkout a file since Siebel does not fire a trigger on a checkout in Siebel.... it ONLY fires the trigger on a CHECKIN of a file in Siebel. So ONLY then a moment exist where communication is possible to the versioning system. So the versioning system can only react on "a checkin" ergo: locking/reserve checkout etc... has no use here.
The only option is to ask the user to manually go to RTC and press the button lock in RTC at the same time he presses the button checkout in Siebel and provide him a reference card with the names in RTC and the names he sees in his repository. But since he is the only user anyway (since the Siebel repository has the project locked) ---> doing that is not needed.
So the dynamic view benefit is not about the moment between checking out, working on and checking in a file for 1 developer but the time directly after that. (If another developer decides to check out a file).
One thought would be to leave the file in a locked state in RTC AFTER the checkin in Siebel, so a checkin in siebel does not cause a checkin in RTC but even if he has it locked in RTC it is checked in Siebel ergo another developer can then work on it and only finds out at the end on the checkin process in Siebel that he can not check it in in RTC. --> does not work.
So for now I think the only solution is the addition of a manual process: before checking out a project in Siebel the developer should go to RTC to see which files are locked. If one is locked he may not check it out in Siebel. This is then a manual / functional process. If he forgets, makes changes he will find out only after making his changes so the script will prevent him from checking it in in Siebel too and thus prevent errors.
I think this is the way to go, I would be interested in additional suggestions. I also still have the labeling question open as indicated above.
As an addition to 3 (and for others interested in the same question):
it even does not matter if clearcase locks / reserve checkout a file since Siebel does not fire a trigger on a checkout in Siebel.... it ONLY fires the trigger on a CHECKIN of a file in Siebel. So ONLY then a moment exist where communication is possible to the versioning system. So the versioning system can only react on "a checkin" ergo: locking/reserve checkout etc... has no use here.
The only option is to ask the user to manually go to RTC and press the button lock in RTC at the same time he presses the button checkout in Siebel and provide him a reference card with the names in RTC and the names he sees in his repository. But since he is the only user anyway (since the Siebel repository has the project locked) ---> doing that is not needed.
So the dynamic view benefit is not about the moment between checking out, working on and checking in a file for 1 developer but the time directly after that. (If another developer decides to check out a file).
One thought would be to leave the file in a locked state in RTC AFTER the checkin in Siebel, so a checkin in siebel does not cause a checkin in RTC but even if he has it locked in RTC it is checked in Siebel ergo another developer can then work on it and only finds out at the end on the checkin process in Siebel that he can not check it in in RTC. --> does not work.
So for now I think the only solution is the addition of a manual process: before checking out a project in Siebel the developer should go to RTC to see which files are locked. If one is locked he may not check it out in Siebel. This is then a manual / functional process. If he forgets, makes changes he will find out only after making his changes so the script will prevent him from checking it in in Siebel too and thus prevent errors.
I think this is the way to go, I would be interested in additional suggestions. I also still have the labeling question open as indicated above.