[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Todd Denniston
Subject: Re: List of directories under a "top-level" module
Date: Tue, 09 Sep 2008 13:03:04 -0400
User-agent: Thunderbird (X11/20080707)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]