Oooh, we had this system of docs being one project and it had very
unsatisfactory (for us) results. The docs are accessed by other projects
during the build (the doc component used to be a non-modifiable comp. in
other projects). This then forces either the doc group or the build person
for the project to apply a baseline on the doc project, then rebase their
integration stream to get all the changes required for their build. There
was just a proliferation of baselines and the process was painful to say the
least. Now the doc component is modifiable in every project. Each project
has access to only their component's docs and not all the rest of the
documents, there's better co-ordination between doc and development.
-Cheers,
Yamuna
-----Original Message-----
From: Jim Pinkham [mailto:pinkham@netjets.com
Sent: Friday, September 29, 2000 7:31 AM
To: cciug@rational.com
Subject: 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 <mailto:stro@im.se>
To: 'cciug@rational.com' <mailto:'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 <mailto: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
BM__MailData-----Original Message-----
From: Gande Thirupathaiah [ mailto:gthirupa@harmonicinc.com
<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
<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
<http://clearcase.rational.com/cciug/mailing_list.html> ]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This archive was generated by hypermail 2b29 : Sun May 06 2001 - 00:26:57 EDT