Free check-ins or stable check-ins?

Free check-ins or stable check-ins?

Post by Eric Gorel » Fri, 14 Jan 2000 04:00:00



Hi all,

I'm hoping someone could give me insight to how they do things...(BTW, we
are using VSS 6.0 and
VisualStudio6.0 on an NT platform)

I was thinking about mandating stable check-ins for all code in our project.
That is, nobody checks in code unless it is deemed complete and workable.
Due to the way VSS <project> labels work (always labels latest versions of
all files), if code is checked in incomplete and a build is performed, it
could break the build. I've heard that if code is checked out for a long
period of time though (if a change takes a week or so), the code is more apt
to become corrupt. Is this true?
The alternative to this is to let developers check in code regardless of the
working state. If a build is performed, this may cause the build to break.
Also, if a "hotfix" needs to be performed, and if the code has already been
changed and is checked in incomplete, the hotfix will include the incomplete
code. If the code is stable, this is not a problem. If the code is still
checked out, at least the person responsible for the hotfix will know that
the code is being modified and can communicate with that person to get the
fix incorporated.

How do others here manage their source code with respect to the above?
Thanks for your thoughts!

 
 
 

Free check-ins or stable check-ins?

Post by Greg Boyk » Fri, 14 Jan 2000 04:00:00


I am currently allowing free check ins, although I am starting to rethink this.
Lately we have been plagued by a number of broken builds (i.e. source doesn't
compile) and instances of unstable or non-working object code (i.e. code doesn't
function as specified). It has become quite a nuisance. Perhaps the best
solution is to allow free check ins but run something like TinderBox which would
monitor and flag broken builds. I don't know if it is worth the overhead to set
up something like TinderBox. I am also interested in hearing what others are
doing.

--
Greg Boyko
Zephyr Technologies


> Hi all,

> I'm hoping someone could give me insight to how they do things...(BTW, we
> are using VSS 6.0 and
> VisualStudio6.0 on an NT platform)

> I was thinking about mandating stable check-ins for all code in our project.
> That is, nobody checks in code unless it is deemed complete and workable.
> Due to the way VSS <project> labels work (always labels latest versions of
> all files), if code is checked in incomplete and a build is performed, it
> could break the build. I've heard that if code is checked out for a long
> period of time though (if a change takes a week or so), the code is more apt
> to become corrupt. Is this true?
> The alternative to this is to let developers check in code regardless of the
> working state. If a build is performed, this may cause the build to break.
> Also, if a "hotfix" needs to be performed, and if the code has already been
> changed and is checked in incomplete, the hotfix will include the incomplete
> code. If the code is stable, this is not a problem. If the code is still
> checked out, at least the person responsible for the hotfix will know that
> the code is being modified and can communicate with that person to get the
> fix incorporated.

> How do others here manage their source code with respect to the above?
> Thanks for your thoughts!


 
 
 

Free check-ins or stable check-ins?

Post by Dwain Wilde » Fri, 14 Jan 2000 04:00:00


We allow checkin of compilable code only. It doesn't have to be full implementation, but
it mustn't break the build. We set a date for an "integration build" at which time the
sources should be fully implemented. After all features play well with each other, we
label and do a production build. The problem with this scheme is that there is about a
week to 10 days when no one can check-in changes. We are extremely unhappy with this
scheme and are currently presenting a case to move to ClearCase.

Dwain


> I am currently allowing free check ins, although I am starting to rethink this.
> Lately we have been plagued by a number of broken builds (i.e. source doesn't
> compile) and instances of unstable or non-working object code (i.e. code doesn't
> function as specified). It has become quite a nuisance. Perhaps the best
> solution is to allow free check ins but run something like TinderBox which would
> monitor and flag broken builds. I don't know if it is worth the overhead to set
> up something like TinderBox. I am also interested in hearing what others are
> doing.

> --
> Greg Boyko
> Zephyr Technologies


> > Hi all,

> > I'm hoping someone could give me insight to how they do things...(BTW, we
> > are using VSS 6.0 and
> > VisualStudio6.0 on an NT platform)

> > I was thinking about mandating stable check-ins for all code in our project.
> > That is, nobody checks in code unless it is deemed complete and workable.
> > Due to the way VSS <project> labels work (always labels latest versions of
> > all files), if code is checked in incomplete and a build is performed, it
> > could break the build. I've heard that if code is checked out for a long
> > period of time though (if a change takes a week or so), the code is more apt
> > to become corrupt. Is this true?
> > The alternative to this is to let developers check in code regardless of the
> > working state. If a build is performed, this may cause the build to break.
> > Also, if a "hotfix" needs to be performed, and if the code has already been
> > changed and is checked in incomplete, the hotfix will include the incomplete
> > code. If the code is stable, this is not a problem. If the code is still
> > checked out, at least the person responsible for the hotfix will know that
> > the code is being modified and can communicate with that person to get the
> > fix incorporated.

> > How do others here manage their source code with respect to the above?
> > Thanks for your thoughts!

 
 
 

Free check-ins or stable check-ins?

Post by John Bridgma » Sat, 15 Jan 2000 04:00:00


We require developers to do a local build/test of their changes before
checking in. No formal testing, but we expect a low rate of bad builds.
We're shifting to automated nightly build/test so there's pressure to allow
untested checkins, but I don't see any advantage to that right now.

The biggest problem with long checkouts is that you **always** end up with
parallel development on the files, so the build breaks because of the need
to merge the changes. We're using Continuus CM with heavy use of parallel
development, the rule is that developers need to deal with any parallel
changes (ie do the merge) before checking in.

The big problem is making everyone follow the procedures, of course ;)

JB
ATI Technologies


>Hi all,

>I'm hoping someone could give me insight to how they do things...(BTW, we
>are using VSS 6.0 and
>VisualStudio6.0 on an NT platform)

>I was thinking about mandating stable check-ins for all code in our
project.
>That is, nobody checks in code unless it is deemed complete and workable.
>Due to the way VSS <project> labels work (always labels latest versions of
>all files), if code is checked in incomplete and a build is performed, it
>could break the build. I've heard that if code is checked out for a long
>period of time though (if a change takes a week or so), the code is more
apt
>to become corrupt. Is this true?

 
 
 

Free check-ins or stable check-ins?

Post by Michael Sl » Sat, 15 Jan 2000 04:00:00


The real problem that we have had between CM and developers is that
they want a place to version their work in progress code.  They also
want builds to be performed on their WIP code.  The following scenario
has solved this problem as well as allowed us to keep a stable set of
code for testing: We have two branches in CM (we are using StarTeam)
for the project we are working on.  The one branch is known as WIP
(work in progress). The other branch is Q/A.

The rules for the WIP branch are as follows:
--------------------------------------------
Free checkins.
Built daily.
You may break the build.
No penalty for breaking the build.
Code from this build is deployed nightly to integration
   test systems.
All integration testing takes place from the code in WIP.
When code has passed integration testing, then it is up to the
   manager of the department to promote the code to Q/A.

The rules for the Q/A branch are as follows:
--------------------------------------------
Secured checkins (managers only).
Built daily.
Builds are not be broken.
There is a penalty for breaking the build.
Code from this build is deployed to our Q/A department.
All Q/A testing takes place from this branch.
When code has passed through Q/A, then it is promoted to a
   separate Release Project which then goes to our customers.

This has worked well for us for about 5 months now.

I hope this helps.

Take care,
Michael Sly



> We allow checkin of compilable code only. It doesn't have to be full
implementation, but
> it mustn't break the build. We set a date for an "integration build"
at which time the
> sources should be fully implemented. After all features play well
with each other, we
> label and do a production build. The problem with this scheme is that
there is about a
> week to 10 days when no one can check-in changes. We are extremely
unhappy with this
> scheme and are currently presenting a case to move to ClearCase.

> Dwain


> > I am currently allowing free check ins, although I am starting to
rethink this.
> > Lately we have been plagued by a number of broken builds (i.e.
source doesn't
> > compile) and instances of unstable or non-working object code (i.e.
code doesn't
> > function as specified). It has become quite a nuisance. Perhaps the
best
> > solution is to allow free check ins but run something like

TinderBox which would

- Show quoted text -

> > monitor and flag broken builds. I don't know if it is worth the
overhead to set
> > up something like TinderBox. I am also interested in hearing what
others are
> > doing.

> > --
> > Greg Boyko
> > Zephyr Technologies


> > > Hi all,

> > > I'm hoping someone could give me insight to how they do things...
(BTW, we
> > > are using VSS 6.0 and
> > > VisualStudio6.0 on an NT platform)

> > > I was thinking about mandating stable check-ins for all code in
our project.
> > > That is, nobody checks in code unless it is deemed complete and
workable.
> > > Due to the way VSS <project> labels work (always labels latest
versions of
> > > all files), if code is checked in incomplete and a build is
performed, it
> > > could break the build. I've heard that if code is checked out for
a long
> > > period of time though (if a change takes a week or so), the code
is more apt
> > > to become corrupt. Is this true?
> > > The alternative to this is to let developers check in code
regardless of the
> > > working state. If a build is performed, this may cause the build
to break.
> > > Also, if a "hotfix" needs to be performed, and if the code has
already been
> > > changed and is checked in incomplete, the hotfix will include the
incomplete
> > > code. If the code is stable, this is not a problem. If the code
is still
> > > checked out, at least the person responsible for the hotfix will
know that
> > > the code is being modified and can communicate with that person
to get the
> > > fix incorporated.

> > > How do others here manage their source code with respect to the
above?
> > > Thanks for your thoughts!

Sent via Deja.com http://www.deja.com/
Before you buy.
 
 
 

Free check-ins or stable check-ins?

Post by Ray McVa » Sat, 15 Jan 2000 04:00:00


One technique might be to define a special tag with which the developer
can identify the version of a module to be included in the builds. That
way she can go ahead and check in non-functional later versions and
"move" the tag when they are ok.  Several of these tags would probably
be necessary.

--

Ray

 
 
 

Free check-ins or stable check-ins?

Post by Berend de Boe » Sun, 16 Jan 2000 04:00:00



> Is there an easy way to do this with VSS?  In CVS, it's trivial, but I
> haven't figured out how with Microsoft's Visual Source Safe.

See pin.

Groetjes,

Berend. (-:

 
 
 

Free check-ins or stable check-ins?

Post by aka T » Mon, 17 Jan 2000 04:00:00


Eric!   Get a job!  (inside joke)

Know the feelings expressed here well.
We moved to ClearCase for partly this reason.
We now operate CC 3.2.1 with ClearMake as well (and Clear Quest
eventually).  For us, developers are forbidden to check in code that is
not ready to be built.  Any deviation from this has to be approved in
advance by SCM (and it won't be, in all likelihood).
By checking in code that can't compile, or that is incomplete, it
effects our builds, as well as development environments.  It's ugly,
but currently our Dev environments are basically free for alls with
more than one project in them.  (eeeeewwwwww!!!!!)

Still, allowing checkins of code that is not ready for a build is just
not logical, IMHO.  There are workarounds in either direction, of
course, but I am more comfortable with no checkin until ready to build.

Tom



> We allow checkin of compilable code only. It doesn't have to be full
implementation, but
> it mustn't break the build. We set a date for an "integration build"
at which time the
> sources should be fully implemented. After all features play well
with each other, we
> label and do a production build. The problem with this scheme is that
there is about a
> week to 10 days when no one can check-in changes. We are extremely
unhappy with this
> scheme and are currently presenting a case to move to ClearCase.

> Dwain


> > I am currently allowing free check ins, although I am starting to
rethink this.
> > Lately we have been plagued by a number of broken builds (i.e.
source doesn't
> > compile) and instances of unstable or non-working object code (i.e.
code doesn't
> > function as specified). It has become quite a nuisance. Perhaps the
best
> > solution is to allow free check ins but run something like

TinderBox which would

- Show quoted text -

> > monitor and flag broken builds. I don't know if it is worth the
overhead to set
> > up something like TinderBox. I am also interested in hearing what
others are
> > doing.

> > --
> > Greg Boyko
> > Zephyr Technologies


> > > Hi all,

> > > I'm hoping someone could give me insight to how they do things...
(BTW, we
> > > are using VSS 6.0 and
> > > VisualStudio6.0 on an NT platform)

> > > I was thinking about mandating stable check-ins for all code in
our project.
> > > That is, nobody checks in code unless it is deemed complete and
workable.
> > > Due to the way VSS <project> labels work (always labels latest
versions of
> > > all files), if code is checked in incomplete and a build is
performed, it
> > > could break the build. I've heard that if code is checked out for
a long
> > > period of time though (if a change takes a week or so), the code
is more apt
> > > to become corrupt. Is this true?
> > > The alternative to this is to let developers check in code
regardless of the
> > > working state. If a build is performed, this may cause the build
to break.
> > > Also, if a "hotfix" needs to be performed, and if the code has
already been
> > > changed and is checked in incomplete, the hotfix will include the
incomplete
> > > code. If the code is stable, this is not a problem. If the code
is still
> > > checked out, at least the person responsible for the hotfix will
know that
> > > the code is being modified and can communicate with that person
to get the
> > > fix incorporated.

> > > How do others here manage their source code with respect to the
above?
> > > Thanks for your thoughts!

--
Tom Adkins

"In the year 2000 I'm going to change my name to "none of the above"
and run for office."

Sent via Deja.com http://www.deja.com/
Before you buy.

 
 
 

Free check-ins or stable check-ins?

Post by Dwain Wilde » Mon, 17 Jan 2000 04:00:00



> Eric!   Get a job!  (inside joke)

> Know the feelings expressed here well.
> We moved to ClearCase for partly this reason.
> We now operate CC 3.2.1 with ClearMake as well (and Clear Quest
> eventually).  For us, developers are forbidden to check in code that is
> not ready to be built.  Any deviation from this has to be approved in
> advance by SCM (and it won't be, in all likelihood).

The way I've worked with Clearcase in the past is this:

1. Each developer creates a branch type for each problem worked on.
2. Check-out/edit/build/test/check-in on the branch.
3. When the problem is resolved and unit testing is complete, request the vobadm
to merge all the branches back to the main branch.
4. Integration builds and releases are are built on the main branch, only.

This schema worked well for allowing the developers total freedom to try various
experiments, maintain their own code version control without implicating anything for
other peoples' work, etc.

When you have completed a major part of the problem or new funtionality, check-in to
freeze your changes in case you wipe out in your next edit session, loose a disk,
etc.--Everything checked-in gets backed up nightly. Check-ins give you several different
sanity checks on your development.

Our model was, check-in early and often on your branch. But don't ask for a merge back to
the main unless it's ready to play with others. Wearing the "I broke the build" hat all
day was no fun in that organization!

Dwain

Quote:> By checking in code that can't compile, or that is incomplete, it
> effects our builds, as well as development environments.  It's ugly,
> but currently our Dev environments are basically free for alls with
> more than one project in them.  (eeeeewwwwww!!!!!)

> Still, allowing checkins of code that is not ready for a build is just
> not logical, IMHO.  There are workarounds in either direction, of
> course, but I am more comfortable with no checkin until ready to build.

> Tom

 
 
 

Free check-ins or stable check-ins?

Post by Joerg Bullman » Tue, 18 Jan 2000 04:00:00


Quote:> >"move" the tag when they are ok.  Several of these tags would probably
> >be necessary.

> Is there an easy way to do this with VSS?  In CVS, it's trivial, but I
> haven't figured out how with Microsoft's Visual Source Safe.

Suppose there is file A and both you and
me are working on it.

I commit revision 1.67 and tag it "BUILD_WORTHY".

You and me apply more changes to it and merge and
commit etc. and after two days we end up with revision
1.71.

You find that one great from your point of view and
tag it "BUILD_WORTHY".

I don't like that because I don't consider the changes
*I* have committed since revision 1.67 to be build
worthy at all.

How is this scenario going to be resolved?

I understand this whole issue can't be handled
without at least branches for you and me. We would
then merge from our branches to the trunk the revisions
we consider build worthy. And we would do that
independently from eachother.

Do I see things radically wrong here?

Joerg

 
 
 

Free check-ins or stable check-ins?

Post by Bob Ventimigli » Tue, 18 Jan 2000 04:00:00



> Eric!   Get a job!  (inside joke)

> Know the feelings expressed here well.
> We moved to ClearCase for partly this reason.
> We now operate CC 3.2.1 with ClearMake as well (and Clear Quest
> eventually).  For us, developers are forbidden to check in code that is
> not ready to be built.  Any deviation from this has to be approved in
> advance by SCM (and it won't be, in all likelihood).
> By checking in code that can't compile, or that is incomplete, it
> effects our builds, as well as development environments.  It's ugly,
> but currently our Dev environments are basically free for alls with
> more than one project in them.  (eeeeewwwwww!!!!!)

> Still, allowing checkins of code that is not ready for a build is just
> not logical, IMHO.  There are workarounds in either direction, of
> course, but I am more comfortable with no checkin until ready to build.

> Tom

Tom,

It may not be logical in your situation because of the limitations of your
underlying tool set, but it is very logical in other situations using
different tools, and is in fact, how we operate while developing eight
variations of our product.  Other tools, e.g. process management/driven
tools, do not present the problems you describe. A developer can check-in
source code as many times as they want. It is not used in a build or
another part of the process until the developer promotes/actions it. When
it is promoted, the developer has certified that it is ready for the next
step in the development process. Since each source code file follows a
process/workflow/lifecycle (pick your semantics), and the tool supports
selection of source based on attributes/states only code that is ready is
used in integration and QA builds.

We need to avoid making to many conclusions or limiting our horizon based
on the limitations of the very popular version management tools. Many tools
exist that are significantly more robust than the version management tools
and  that help avoid the problems I've seen discussed in this and other
threads.

gotta run! s/see yas!

bob e v

ps - let us in on the inside joke

- Show quoted text -



> > We allow checkin of compilable code only. It doesn't have to be full
> implementation, but
> > it mustn't break the build.
> >snip<

 
 
 

Free check-ins or stable check-ins?

Post by John Bridgma » Tue, 18 Jan 2000 04:00:00



>It may not be logical in your situation because of the limitations of your
>underlying tool set, but it is very logical in other situations using
>different tools, and is in fact, how we operate while developing eight
>variations of our product.  Other tools, e.g. process management/driven
>tools, do not present the problems you describe. A developer can check-in
>source code as many times as they want. It is not used in a build or
>another part of the process until the developer promotes/actions it. When
>it is promoted, the developer has certified that it is ready for the next
>step in the development process. Since each source code file follows a
>process/workflow/lifecycle (pick your semantics), and the tool supports
>selection of source based on attributes/states only code that is ready is
>used in integration and QA builds.

We use Continuus CM which allows all of the things you're talking about
(checking in broken code, keeping it out of the main builds until the change
is explicitly promoted etc..) but it's still not clear to us why we should
encourage incomplete checkins.

Quote:>We need to avoid making to many conclusions or limiting our horizon based
>on the limitations of the very popular version management tools. Many tools
>exist that are significantly more robust than the version management tools
>and  that help avoid the problems I've seen discussed in this and other
>threads.

There is a benefit if the developer is moving between machines (the CM tool
can make the code follow them around) and no chance of losing WIP if the
developers hard drive dies over the weekend, but that seems to be it. Do you
see other reasons to allow checking in partially finished code ?

I guess some systems might need that to let another developer know that they
were about to start a parallel change, but C/CM establishes that on
checkout, not checkin..

JB
ATI Technologies

 
 
 

Free check-ins or stable check-ins?

Post by Jochen Hollman » Tue, 18 Jan 2000 04:00:00




> >It may not be logical in your situation because of the limitations of your
> >underlying tool set, but it is very logical in other situations using
> >different tools, and is in fact, how we operate while developing eight
> >variations of our product.  Other tools, e.g. process management/driven
> >tools, do not present the problems you describe. A developer can check-in
> >source code as many times as they want. It is not used in a build or
> >another part of the process until the developer promotes/actions it. When
> >it is promoted, the developer has certified that it is ready for the next
> >step in the development process. Since each source code file follows a
> >process/workflow/lifecycle (pick your semantics), and the tool supports
> >selection of source based on attributes/states only code that is ready is
> >used in integration and QA builds.

> We use Continuus CM which allows all of the things you're talking about
> (checking in broken code, keeping it out of the main builds until the change
> is explicitly promoted etc..) but it's still not clear to us why we should
> encourage incomplete checkins.

> >We need to avoid making to many conclusions or limiting our horizon based
> >on the limitations of the very popular version management tools. Many tools
> >exist that are significantly more robust than the version management tools
> >and  that help avoid the problems I've seen discussed in this and other
> >threads.

> There is a benefit if the developer is moving between machines (the CM tool
> can make the code follow them around) and no chance of losing WIP if the
> developers hard drive dies over the weekend, but that seems to be it. Do you
> see other reasons to allow checking in partially finished code ?

It's maybe a question of your editing technique. When I change code I
sometimes want to revert to a previous version. Now, if I can only check-in
working copies, I can only revert to the last working copy. This may be
sufficient for most cases, but it's not for large changes, where you want to
have a finer granularity. Also, before I do commits, I always want to take a
look on the diff. If the diff is to large I may oversee thinks, which should
never go into the main tree.
 
 
 

Free check-ins or stable check-ins?

Post by John Bridgma » Tue, 18 Jan 2000 04:00:00


Now THAT makes sense. Thanks, I'll take another look at our policies ;)

JB
ATI


>It's maybe a question of your editing technique. When I change code I
>sometimes want to revert to a previous version. Now, if I can only check-in
>working copies, I can only revert to the last working copy. This may be
>sufficient for most cases, but it's not for large changes, where you want
to
>have a finer granularity. Also, before I do commits, I always want to take
a
>look on the diff. If the diff is to large I may oversee thinks, which
should
>never go into the main tree.

 
 
 

Free check-ins or stable check-ins?

Post by Dwain Wilde » Tue, 18 Jan 2000 04:00:00


Interesting and stimulating remarks, Randy. I think of CM as its own discipline, not as a
hodge-podge of folks who come and go with various skills, as in a CMM Level 1
organization. If your goal is to think of CM as a CMM Level 2 operation, some of these
question clear up right away: it makes just as much sense to plan for role-based
competent, complex activities in CM itself as it does to rely on trained proffesionals in
software development generally. I agree that trained CM folk are scarce, but so are
developers.

I think we should be thinking of CM as a Production Management discipline in the context
of software engineering, not as a field which contributes quixotically, with unexpected
brilliance, relying on the individual genius of a small coven of geeks, (no matter how
charming it is to be a member of such a small group in a developing specialty ;o) ). There
are roles for people in all the quantum states of your competence spectrum, and indeed,
I'd argue that an organization would do well to have the whole spectrum, with the
more-experienced strengthening their professional standing by training the less-experienced.

So I would say that CM Processes that fall apart like a house of cards when key people
leave is a signal of the failure of CMM Level 1 organizations. The cure is to achieve
Level 2, not to clamp expectations at that achievable by untrained staff. Use good Process
Improvement techniques, and role-based tasking rather than relying on individual
brilliance for day-to-day success. The brilliance should be put to work planning,
training, and Process Improvement, not saving the company's bacon every day.

Dwain


> You're all making really good points. Let me try to add a little, if I may,
> to the decisions involved here.

> <jumping onto soapbox>

> Much of what we're describing here is highly dependent on the skill-sets of
> the people in the roles of Configuration Manager. The way I look at it, you
> have a spectrum that looks something like this:

>     At one end: CM people being able to handle
>         semantic analysis of code to sequence
>         atomic changes associated with features.

>     Somewhere in the middle: CM people help organize
>         the repository, structure releases, but are not
>         involved in looking at the code.

>     At the other end: CM people essentially push the
>         "check-in" and "freeze" buttons and inform other people
>         that stuff is ready.

> You need to take a good hard look at your processes and the underlying
> methodologies involved in deploying your software products (yes, if you have
> CM involved, you're in a product mode, because evolution is implicit). Who
> runs the CM group? Is it product management (my feeling is that that's the
> most appropriate place, most often), development, quality assurance (that's
> also a good place, because that's often under product management also),
> quality control, operations, etc.? What skill sets do you require of your CM
> people to perform their roles to the expectations of your organization? Are
> you likely to be able to sustain the required skill sets should changes
> occur in your organizations (growth, reorganizations)?

> <General back-patting coming, beware :-) > It's fine and great when we're
> all able to effectively manage our changes because we are, or have been, or
> have close access to heroic developers, or really understand the process of
> building software. But, and it's a bit but, what happens when it's time to
> move on? Can the organization continue to maintain the processes and
> procedures we've created and executed so effectively, if we move onto
> something else?

> <jumping off soapbox>

> I've seen many companies set up CM infrastructures that worked for a while,
> and were highly dependent on specific individuals being in the jobs. When
> those people left, the whole CM process fell apart like a house of cards.
> We, in CM (Change Management, Configuration Management - take your pick), of
> all people, should be able to avoid doing this. It's our calling in life,
> isn't it?

> Just some thoughts.

> Hoping they help,

> Randy

 
 
 

1. Graphical representation of CVS or RCS archive check-ins

Before I go off and reinvent the wheel.

Has anyone got, or knows about any scripts/tools, for generating
graphical plots of changes to RCS/CVS project files giving details on
the number of lines that have been modified per files and per directory,

plotted over a specified time period. Some additional per user
info would be nice too.

Something that takes raw rlog type output and interfaces to something
like perl's Chart::PNGgraph is the sort of thing I'm thinking of.

cheers,

Ian Gilmour

2. Minidock:allows internal & external monitor simultaneously?

3. graphical plots of CVS/RCS archive check-ins

4. Minolta Quickscan 35 plus

5. 8150, 3270, INS info wanted..

6. need screen bin for sunos 5.5

7. VST plug-ins

8. Password server not working for us. Any ideas?

9. getting winamp to read plug-ins

10. TDM plug-ins problem

11. Strange Delay while using DSP-FX plug ins in Live Input, anyone??

12. Digital Audio DLL's or Add-Ins