old SCMer questions

David,

I am not looking for a binary Clearcase or RTC decision here. Like all tools different tools are applicable to different scenarios. RTC will have benefits under some scenarios, and Multisite will have benefits in others.

Unfortunately I have seen more than a few implementations of Clearcase where Dynamic views were misapplied or where mvfs was not tuned effectively. I have also seen other sites where MVFS build times were much less than their equivalent Snapshot view builds by a significant margin.

As an example, one of our current clients has a geographically distributed team across 5 countries, with a WAN infrastructure which drops out daily to some sites, who is also after an effective Disaster recovery scenario with users who are not technically inclined, then Clearcase Multisite is a good match. Of course, it's success/failure does depend on how well the deployment is planned, implemented and automated.

MVFS can be lightweight, but as with a lot of aspects of clearcase and clearquest for that matter, it is highly dependant on the quality of the implementation and the environment it is being deployed into.

jacksuss wrote:

With the process modifications, are the following possible:
1) Can we create custom triggers on Deliver, checkin etc
On deliver, yes, on checkin, currently no.
2) Do we have the ability to deliver change set(s) to an alternate
target (to use UCM speak). The ability to prevent this also (depends
on the need).
Yes (both to deliver, and to prevent it).
3) Ability to change the deliver scenario to be a pull mechanism
rather than a push mechanism.
Change flow in RTC is always a combination of a pull (into a Workspace)

and a push (into a Stream ... you can push into one of your own
Workspaces, but that is an edge case). So push vs. pull is really just
whether the developer or the integrator is doing the change flow. If
this doesn't sound right to you, please go into a bit more detail on
what you consider a "pull" and what you consider a "push".

4) Ability to force new WIs to be associated with other Work item
types on submission.
Could you elaborate a bit on a specific example of what you have in mind

here?

5) Ability to force associating change sets to Work Items - not
allowing comments instead?
Yes. There are built-in deliver hooks that allow you to require

comments, require associated work items, require either comments or work
items, or require both.

Is it correct ot assume that only one user can be wroking on a WI at
one time. By working on it I mean checking out/in against it.
You can use process to require this if you want. Note that you don't

check out/in against a work item ... you check in against a change set.
You then associate a change-set with a work item (and if you declare a
work item to be "current", the system will automatically associate your
new change sets with that work item). You can configure in process
whether at you are required at deliver time to only deliver a change-set
associated with work items that you "own" (which effectively enforces
that only one user can be working on a given work item at one time).

Cheers,
Geoff

Thanks Geoff,

Ok, for clarification:

Custom triggers are available on delivery

- are these triggers flexible enough to run custom code (say like a perl script)?
- What other events can triggers be applied to?

We can deliver a change set to alternate targets (or we can have this turned off). Good.
- can we deliver the same changeset to multiple target streams - i.e. one for hotfix and the other into the mainline?

Pull Vs Push. Ok, in many scenarios, having developer based branching and delivering makes a lot of sense. However, if you're working on a codebase with a lot of non-mergable files, you really don't want multiple developers working on the same files because when they merge, the merge crashes.

The way around this with clearcase is to not have user based parellel development and people just have to work a different way. How is this scenario handled in RTC?

With the Push Vs Pull scenario, for larger teams (think really large here), often there is a need for integrators to perform all deliveries. Without doing this, so many deliveries happen so often that it can become impossible to select a baseline for a release - think of say 50 people trying to get in a door at the same time just as you are trying to close the door, for an analogy.

So, in RTC, is it possible to implement it so that developers don't push their deliveries from their workspaces, but they indicate (say with the Work items state) that the changeset is ready to be delivered and someone else then does the delivery for them?

I consider a pull delivery to be where you pull a changeset from a developers workspace into the mainline. A push is where the developers push their changesets on the mainline.

With regards to only one developer being able to work on a work item at one time, this poses a problem if the Work Item is a change request or sometimes a defect. Change requests often involve many people to do many things to implement them, and this is not allways a sequential process - it requries parellelisation. Likewise, defects can under some circumstances require parellelisation also -i.e. multiple people resolving the defect at the same time.

I can see that by creating a changeset first, and then associating it to a work item could help this, but the scenario I have just mentioned would require multiple changesets done by different people to be associated with the Work item.

With regards to forcing a Work Item to be associated with parent CRs or Defects on submission, this ties closely with what I have just mentioned. With UCM, I normally have activities as the lowest level of work where the changesets exist. Activities can be associated with some form of header record -a CR, Defect, Project Management Task etc. Thereby allowing multiple people to work concurrently on resolving a defect/CR. it also reduces the amount of double punching -i.e. creating activities is really simple, as a large amount of the information is already on the header CR or defect etc. This actually works extremely well for everyone - especially the developers themselves.

So, how can the Jazz SCM process be adapted so Work item submission can be configured to require an association to another header record?

jacksuss wrote:

Custom triggers are available on delivery
- are these triggers flexible enough to run custom code agains (say
like a perl script)?

Currently, you have to write your triggers in Java, and install them on
your server (there are articles/videos showing how to do this on jazz.net).

- What other events can triggers be applied to?

Look at the Process Configuration page in the Project Area editor. That
will list all of the events that you can contribute triggers to (and all
of the out-of-the-box triggers that you can turn on/off).

We can deliver a change set to alternate targets (or we can have this
turned off). Good.
- can we deliver the same changeset to multiple target strems - i.e.
one for hotfix and the other into the mainline?

Yes.

Pull Vs Push. Ok, in many scenarios, having developer based
branching and delivering makes a lot of sense. However, if you're
working on a codebase with a lot of unmergable files, you really
don't want multiple developers working on the same files because when
they merge, the merge crashes.

The way around this with clearcase is to not have user based parellel
development and people just have to work a different way. How is
this scenario handled in RTC?

So it sounds like you're asking about how to avoid branching on
unmergeable files? You'd use the usual approaches, i.e. have all
development of that component be done in a single stream. In the
2.0.0.2 release, the SCM WebUI was enhanced to allow you to develop
directly on a stream, with automatic locking of the file you are
editing, so single stream development is enforced in the Web UI.
With the Eclipse UI, the developer would explicitly take out a lock on a
file that is not mergeable, so that other developers would see that they
are working on that file.

Caveat: The lock currently is not enforced in the Eclipse UI until
deliver time, so developers need to remember to always take out the lock
before they start to modify a non-mergeable file. There is a work item
requesting the ability to auto-lock a file of a given type when it is
modified (work item 71912) and a request to make a file read-only until
a lock has been requested (work item 77416). Please feel free to add a
comment to those work items to indicate your support/interest.

With the Push Vs Pull scenario, for larger teams (think really large
here), often there is a need for integrators to perform all
deliveries. Without doing this, so many deliveries happen so often
that it can become impossible to select a baseline for a release -
think of say 50 people trying to get in a door at the same time just
as you are trying to close the door, for an analogy.

So, in RTC, is it possible tim implement it so that developers don't
push their deliveries from their workspaces, but they indicate (say
with the Work items state) that the changeset is ready to be
delivered and someone else then does the delivery for them?

Yes, this is supported in RTC. Deliver to the integration stream is
limited to the integrator. There are a few variants. You can define a
particular state for a workitem ("awaiting integration"), or add a
"needs integration" approval. Alternatively, you could define a
"developer integration" stream that the developers deliver to, and then
have the integrator selectively pull change sets from that developer
integration stream.

With regards to only one developer being able to work on a work item
at one time, this poses a problem if the Work Item is a change
request or sometimes a defect. Change requests often involve many
people to do many things to implement them, and this is not allways
a sequential process - it requrieds parellelisation. Likewise,
defects can under some circumstances require parellelisation also
-i.e. multiple people resolving the defect at the same time.

To be clear, in RTC it is completely up to the project lead as to
whether multiple people can add change sets to a single work item, or
only the owner can add change sets to a given work item (specified in
the project area process). One way to get a very lightweight level of
coordination between several people contributing to a single work item
is to create an "approval" for each of the folks working on that work
item, so they can indicate when they are done with their part of it.

With regards to forcing a Work Item to be associated with parent CRs
or Defects on submission, this ties closely with what I have just
mentioned. With UCM, I normally have activities as the lowest level
of work where the changesets exist. Activities can be associated with
some form of header record -a CR, Defect, Project Management Task
etc. Thereby allowing multiple people to work concurrently on
resolving a defect/CR. it also reduces the amount of double punching
-i.e. creating activities is really simple, as a large amount of the
information is allready on the header CR or defect etc. This
actually works extremely well for everyone - especially the
developers themselves.
So, how can the Jazz SCM process be adapted so Work item submission
can be configured to require an association to another header record?

Yes, RTC supports child tasks, so you can create a child task of the
work item for each of the individuals participating on that work item
(and that is probably the most functional way doing the sharing). I
don't believe that there is a built-in process hook for requiring that
the tasks have a parent, but that is the kind of trigger that you could
add yourself.

Cheers,
Geoff

Thanks geoff,

Very comprehensive answer, I really appreciate it.

One more question RE: Non mergable files. Is it possible o set whether indicudal files or file types are worked on a single branch whereas the mergable ones can be branched for user based parellel development.

This was possible with base clearcase and is something I really missed with UCM.

And in summary, it looks to me that features missing between clearcase and RTC are the following:

1) Dynamic views
2) IDE integrations with other systems
3) Multisite capability
4) Lower overhead to run

What else?

As a general comment, note that RTC SCM is not designed to replace
ClearCase, but rather to complement it. In particular, the key
differentiators for ClearCase are:
- dynamic views (and everything that goes along with them ... instant
view creation, build auditing, wink-in, etc.)
- "roll your own SCM system" ClearCase pretty much lets you build your
own SCM system from low level primitives

IDE integrations is more a question of timing ... RTC provides IDE
integrations with the two most popular IDE's (Eclipse and Visual
Studio), but over time if customer demand warrants it, integrations with
other IDE's are a reasonable enhancement to request (several have
already been filed).

Multisite capability is a question both of timing and of different ways
of addressing a customer need. The ability to work in two usually
disconnected repositories is a feature currently being worked on (first
step ... ability to deliver change sets to another repository).
Failover is handled by the underlying repository DBMS, rather than at
the application level.

WRT "lower overhead to run", since the first three in the list were
characteristics of ClearCase, were you suggesting that ClearCase has
lower overhead to run than RTC? If so, I'd be interested in what ways
you found that to be the case (not disagreeing with you ... just wondering).

Cheers,
Geoff

jacksuss wrote:

Thanks geoff,

Very comprehensive answer, I really appreciate it.

One more question RE: Non mergable files. Is it possible o set
whether indicudal files or file types are worked on a single branch
whereas the mergable ones can be branched for user based parellel
development.

This was possible with base clearcase and is something I really
missed with UCM.

And in summary, it looks to me that features missing between
clearcase and RTC are the following:

1) Dynamic views
2) IDE integrations with other systems
3) Multisite capability
4) Lower overhead to run

What else?

Thanks Geoff,

By lower overhead, I was referring to the ability with clearcase to have a small install on a workstation - just MVFS and the basics, and the ability to tie this into the OS. Let's face it, eclipse is pretty heavyweight -especially for non development users.

On top of that is automating things so the user really doesn't need to learn much. in fact I have had users that after using clearcase for a couple of years, were insisting they had never used it they just had this funny network drive that forced them to checkout and checkin to.

I always try and set things up so the developers/users get most of their workspaces created for them - if they want others, that's where the training comes in and then away they go. Likewise with the integrations, I would automate the itnegrations between the various rational tools so they were all setup for the users when they logged in.

It's this sort of thing that I have found really has a positive impact on the development endeavor, and the uptake of the tools. It really lowers the admin overheads as well. It also tends to mean the Cmers aren't bogged down with nasty silly little scenarios as much.

This approach has scaled very well for some really large projects (i.e. more than 1000 developers).

jacksuss wrote:

By lower overhead, I was referring to the ability with clearcase to
have a small install on a workstation - just MVFS and the basics, and
the ability to tie this into the OS. Let's face it, eclipse is
pretty heavyweight -especially for non development users.

It depends on how you look at it. I don't see MVFS as lightweight. It
creates a new kind of file system in the operating system. That's
pretty serious stuff. The RTC Eclipse client is just a regular
application that you can plop down anywhere. The ClearCase client may
be less visible because it integrates into the operating system better,
but I wouldn't call it lightweight.

RTC does a lot more than just SCM. Comparing RTC to just base ClearCase
isn't really fair. If you compare the lightness/heaviness of RTC
against ClearCase UCM + ClearQuest + CruiseControl, it compares a little
more favorably. (You'll probably make the argument that not all users
need to do all those things, and they shouldn't be burdened with all of
RTC if they are just doing SCM or just creating defects. And that's a
fair point.)

jacksuss wrote:

And in summary, it looks to me that features missing between
clearcase and RTC are the following:

3) Multisite capability

I see the lack of multisite as a huge plus for RTC. Back when we were
using ClearCase multisite, most people liked ClearCase well enough but
hated the multisite aspects of it. We saw multisite as a necessary evil
due to ClearCase not being able to work over long distances. RTC works
just fine from all the way across the continent, so it doesn't need
multisite, and we are thrilled with that.

I agree with both Jack and David. For a customer that has good LAN
connectivity and a good ClearCase admin, ClearCase MVFS can provide the
end user with a completely transparent lightweight experience. It's
just a network drive that requires you to "checkout" a file when you
want to modify it and "checkin" when you are done. And on Windows, you
can do that checkin/checkout directly from the Windows Explorer (no SCM
client to learn). And if you are using an IDE with the ClearCase
plugin, the checkout is automatically invoked, so all you need to do is
checkin when you are done with a file. And like a shared drive, you can
see everything your team is doing without waiting for file trees to be
copied back and forth ... but unlike a shared drive, you get to decide
when your changes are visible to other team members (that's what the
"checkin" command gives you control over).

On the other hand, if you don't have good LAN connectivity, and need a
fast/easy copy-based model, then you want an SCM system optimized for
that environment, and RTC will be much easier to admin.

WRT integration, the apples to apples comparison is not CC/CQ/BuildForge
with RTC, but rather CC/RTC-work-items/RTC-Build with
RTC-SCM/RTC-work-items/RTC-Build. Although today you get the most
seamless experience with RTC-SCM/RTC-work-items/RTC-Build, with the work
being done this year to enhance the CC-Bridge, and to improve the CALM
capabilities of RTC-work-items and RTC-Build, the experience using CC
with RTC-work-items and RTC-build should come much closer to what you
see today with RTC-SCM/RTC-work-items/RTC-Build.

Cheers,
Geoff





David Olsen wrote:

jacksuss wrote:
By lower overhead, I was referring to the ability with clearcase to
have a small install on a workstation - just MVFS and the basics, and
the ability to tie this into the OS. Let's face it, eclipse is
pretty heavyweight -especially for non development users.

It depends on how you look at it. I don't see MVFS as lightweight. It
creates a new kind of file system in the operating system. That's
pretty serious stuff. The RTC Eclipse client is just a regular
application that you can plop down anywhere. The ClearCase client may
be less visible because it integrates into the operating system better,
but I wouldn't call it lightweight.

RTC does a lot more than just SCM. Comparing RTC to just base ClearCase
isn't really fair. If you compare the lightness/heaviness of RTC
against ClearCase UCM + ClearQuest + CruiseControl, it compares a little
more favorably. (You'll probably make the argument that not all users
need to do all those things, and they shouldn't be burdened with all of
RTC if they are just doing SCM or just creating defects. And that's a
fair point.)