RE: [cciug] UCM: good for some artifacts, bad for others?What we have done is to make a doc UCM component vob, and a project just for it which creates an integration stream.
Instead of having developers join the doc project (which would create developer streams), they create a view (and ClearCase explorer view shortcut) to the integration stream. Now they can all do activities there and check-in and check-out with immediate visibility. One big assumption is that exclusive check-out is OK, which is true for us. If not, consider splitting larger docs into chapter docs until this is true.
-- Jim Pinkham
Executive Jet Aviation
----- Original Message -----
From: Rosendahl Sten - stro
To: 'cciug@rational.com'
Sent: Friday, September 29, 2000 9:21 AM
Subject: RE: [cciug] UCM: good for some artifacts, bad for others?
I agree with the idea of keeping all different product artifact together, it makes a lot of sense when you deal with a modularized product suite. However, how do handle parallel development of artifacts that are difficult or impossible to merge? We are thinking in terms of using shared development streams and lock attributes to prevent multiple branching on complex element types. Has anyone implemented such triggers?
Sten Rosendahl (stro@im.se)
IMI Corp.
-----Original Message-----
From: Dignard, Norman [mailto:dignarn@navcanada.ca
Sent: Friday, September 29, 2000 14:47
To: 'Gande Thirupathaiah'; Yamuna Ramasubramaniyan
Cc: 'Couball, James'; 'cciug@rational.com'
Subject: RE: [cciug] UCM: good for some artifacts, bad for others?
One issue comes to mind are the actual user manuals, guides, test procedures etc,,, that are required for and/or part of the end product. As part of the activities of approving changes to code all the relevant docs also need to be updated and reviewed/approved to ensure they match and support the unit or integration tests or final release. These updates to docs form part of the tasks required using UCM or not.
Using UCM in this light makes for a cleaner process in my mind. Having one central source to address all the required work and traceability of changes.
Any comments anyone?
Norm
-----Original Message-----
From: Gande Thirupathaiah [mailto:gthirupa@harmonicinc.com
Sent: Thursday, September 28, 2000 1:38 PM
To: Yamuna Ramasubramaniyan
Cc: 'Couball, James'; 'cciug@rational.com'
Subject: Re: [cciug] UCM: good for some artifacts, bad for others?
Hi,
Why do not we put all the documents (like design docs etc) in a NON UCM
vob?
Can any body tell me on what do we gain by putting these in UCM VObs?
Thanks
gande
Yamuna Ramasubramaniyan wrote:
>
> James,
>
> You have it right in that any change a person makes needs to be delivered
> and baselined before it can be accessed by anyone else. It is painful in
> the initial development stage of the project. It is not particularly
> mistake prone (if you can't see the doc in your view, you just can't see the
> doc), but it does cause a lot of heartburn ("But I just need to see it, why
> do I have to do all this stuff" will become a very familiar phrase). You
> might want to consider having everyone use one development stream during
> this initial phase only. That way project members can read the docs, edit
> them etc. in real time and deliver and baseline it when it undergoes a peer
> review periodically.
>
> -Cheers,
> Yamuna
>
> -----Original Message-----
> From: Couball, James [mailto:James.Couball@cotelligent.com
> Sent: Thursday, September 28, 2000 8:41 AM
> To: 'cciug@rational.com'
> Subject: [cciug] UCM: good for some artifacts, bad for others?
>
> Hello,
>
> I am using ClearCase UCM (w/o ClearQuest integration at the moment) in an
> environment where we previously used SourceSafe. I am running up against a
> usability issue I was hoping that someone could help me with.
>
> It is early in the project and there are a lot of documents being shared by
> the develolpment team. They used to use SourceSafe to share the documents.
> This was easy for them: just check it in and the next person can get it.
> Now that we have moved to ClearCase using UCM, one person must deliver their
> changes, someone must baseline the delivered changes, and then the
> interested parties must rebase their development stream. It strikes me that
> I am not using UCM or ClearCase correctly if it is so hard to do this.
> People will make mistakes.
>
> I think that this is particularly the case for management documents. For
> instance, you don't usually go through a change management process for
> changes made to the project plan -- right?
>
> How do others use ClearCase UCM for managing these types of documents in a
> way that makes it easy for people make small changes and share the results
> with others? Maybe these type of documents shouldn't be stored using UCM?
>
> Sincerely,
> James.
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
>
>
> http://clearcase.rational.com/cciug/mailing_list.html
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
>
>
> http://clearcase.rational.com/cciug/mailing_list.html
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
http://clearcase.rational.com/cciug/mailing_list.html
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This archive was generated by hypermail 2b29 : Sun May 06 2001 - 00:26:56 EDT