I like Michael's idea, but I think this is a bit easier (see rest of thread
for problem) -- see what y'all think:
As part of the build, I've inserted this line:
for /F %%i in ('dir /s /b /aR-d *.des') DO cleartool checkout -ncomment %%i
This only takes time the first build they do; subsequent (re)builds before
they deliver won't have the .des files read only, so they won't be checked
out again.
Then, I give them this 'uncheckout.bat' script, which is (with comments
removed):
for /F %%i in ('cleartool lsprivate -co -s') do call :uncoIfNoDiff %%i
goto :end
:uncoIfNoDiff
cleartool diff -options "-status_only" -pred %1 2>nul
if errorlevel 1 goto :eof
cleartool uncheckout -rm %1
So, if they have anything left checked out after this, it's 'real' work they
need to check in.
I think this will work, but if anyone sees flaws, do tell!
-- Jim Pinkham
Executive Jet Aviation
----- Original Message -----
From: "Michael Woodhams" <michael.woodhams@peace.com>
To: "Jim Pinkham" <pinkham@netjets.com>; "cciug" <cciug@rational.com>
Sent: Tuesday, September 12, 2000 8:01 PM
Subject: Re: [cciug] long term checkouts with UCM
>
> Have you considered creating some files that contain just the hand-entered
> parameters of the .DES files, and as part of the build, you copy (or
otherwise
> generate) a .DES file from these, then let the build process make the
machine
> generated bits? This seems a cleaner solution, separating the source code
> component from the machine generated component, and making the .DES files
a
> pure derived object.
>
> I can imagine problems where developers change the hand-coded bits and
forget
> to deliver, because they are so used to those checked out DES files not
being
> included in deliveries. (Or if you *do* deliver the .DESs, they will get
sick
> of merging files when they know that the sections will just be overwritten
by
> the compiler anyway.)
>
> Jim Pinkham wrote:
>
> > I'm new to ClearCase & trying to setup with UCM and CC v4.1.
> >
> > We are doing Java EJB development using PowerTier EJB server. It has
it's
> > own build process that involves code generation and the reading and
> > re-writing of some config (.DES) files. The .DES files must be checked
in
> > because they contain some hand-entered parameters, but they must also be
> > writeable for every build because they also contain 'generated'
sections.
> >
> > I'd like to let developers build on their development stream drive, so
it
> > seems that I will need to have them check out all of these .DES files in
> > order for them to be writeable. My first thought was to check them all
out,
> > then undo the checkout after each build. This takes quite a while.
(Just
> > enumerating the directories that contain them takes 20 sec.)
> >
> > My second thought is to just leave them checked out between builds.
When
> > they occasionally rebase, any files that were changed (modified, checked
in
> > and delivered, then checked out again by another developer) should merge
> > into the checked out ones.
> >
> > Does anyone see a better way or some problems with this approach?
> >
> > Thanks,
> >
> > Jim Pinkham
> > Executive Jet Aviation
> >
> > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> >
> >
> >
> > http://clearcase.rational.com/cciug/mailing_list.html
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This archive was generated by hypermail 2b29 : Sun May 06 2001 - 00:26:33 EDT