Re: List of directories under a "top-level" module

[Todd Denniston]

chaitu wrote, On 09/09/2008 10:51 AM:
> Hi Todd,
>
> Thanks a lot for responding. Here are my thoughts on some of the
> things you said:
>
> 1. Under /src/abcd, I have a mix of files some of which are C/C++/PHP/
> Perl code, PDFs (bulky), RPMs (bulkier) and MSIs (bulkiest). For
> compiling my company's product, I need C/C++ code and for packaging, I
> need some of the PDFs. But I don't really need the sub-modules
> containing RPM and MSI files. Worst of all, the sub-modules keeps
> changing from time to time so I cannot hard-code the list. I would
> rather obtain a list of all sub-modules and filter out the names of
> those bulky nasty ones and pass the rest to the checkout command. My
> CVS is 1.11.17 which unfortunately doesn't support the 'ls' command
> and the organisation is loathe to upgrade CVS :(

the `cvs history` command may be able to give you some heads up on when things 
are changing.  Assuming that the history database is being kept.

`cvs history -a -x AR`
gives you when files are added or removed from the tree, so you could look for 
RPM and MSI files being messed about with.
I would probably also use a -D with a date of when I last used the command.


> 2. Ignorance of CVS is really the first thing to pop up in my mind
> too, but then the higher management believes in doing fresh checkouts
> blindly because on some occassions in the past, developers gained
> access to the build machine (they are not supposed to, but thru social
> engineering they could!) and changed certain source code files and
> didn't bother to clean 'em up, causing merge issues. They instructed
> us to check out code daily instead of disciplining the errant
> developers. This is something I really cannot argue against as the
> management in my company is not really any different than in those
> around the world...........narrow-minded and afraid that anything new
> or cool would break something somewhere.

With this case, I would try to ask someone appropriate if the tarball idea 
would be close enough...
If you rm the previous build directory, or untar in a new location from a 
cleanly checked out tarball (that the build team knows they can control write 
access to, and a few md5/sha1 sums for extra measure) then an update in that 
fresh untar will be exactly the code (and other artifacts) that you would have 
gotten from a checkout.
If they want more guaranty of it, then try using untars next to the current 
policy method for a week, do recursive diffs between the directory structures 
and keep data on how long the updates took verses the checkouts and any 
differences noted.  To further assuage their fears, suggest that each week 
you'll start from a fresh full checkout to make the week's starting tarball, 
so some recalcitrant coder can't get away with something for more than a week, 
and they could only do that if they found a way to corrupt your tarball.

You should be able to show a significant time savings, with no degradation in 
code control.

> 3. I've even tried getting them to agree to shift the bulky ones into
> a separate repository but they wouldn't listen.

Try for something a little less drastic.  Keep them in the same repository and 
make a directory tree called something like binaries, and all RPMs and MSI 
files have to go there, that way it CAN be checked out with one checkout 
command, but not everyone has to get it.

> Anyway, thnx for ur time once again. Hope I could make more sense to u
> now. I am basically stuck in a place where I can't really do too much.
> I'll read the link you've sent tonite.


--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter