Manual code management practices
Olmos, Fernando (Sericon at Alcoa)
Fernando.Olmos@alcoa.com.au
Fri, 20 May 2005 09:57:41 +1000
These ideas are great! Thank you everyone.
-----Original Message-----
From: powerh-l-admin@lists.sowder.com
[mailto:powerh-l-admin@lists.sowder.com] On Behalf Of Guy Werry
Sent: Friday, 20 May 2005 5:44 AM
To: PowerHouse List
Subject: RE: Manual code management practices
Yet another example of the fact that we don't need to always throw
technology at a problem!
This makes a great deal of sense, especially since a person can take a
digital photo of the board at the end of each day, in order to have a
"backup". We've often done this when we have critical info on the
whiteboard.
Thanks,
Guy L. Werry
Senior Systems Analyst
Hudson Bay Mining & Smelting Co., Limited.
-----Original Message-----
From: Robert Edis [mailto:robeconsult@sbcglobal.net]
Sent: Thursday, May 19, 2005 2:37 PM
To: PowerHouse List
Subject: RE: Manual code management practices
As far as ideas for a manual method is concerned why not use a
centralised white board for visability. Use permanent markers to draw a
grid and labels then get the developers to write in using dry erase
markers who has what code at what stage in it's development cycle?
Get it in everyone's head to check the whiteboard before starting any
work on a code object. You could also have a request column where a
developer can put their initials if they want a code object that is
already being worked on.
Blue
--- Guy Werry <guy.werry@hbms.ca> wrote:
> If you're on Unix, then use RCS. It's embedded in the OS, no cost.
>
> It keeps a history of each revision, and shows WHO has checked out a
> particular version. Unless you're using generic logons, this works
> quite well.
>
> It also has tools that help manage multiple developers, although we
> don't use these here, as we stay away from that scenario (small shop,
> which helps). As a side note, RCS works on any language, even
> scripts.
>
> Automate as much as possible!
>
> The idea about regular meetings is a very sound one.
> A half-hour a day or
> every 2nd day will pay HUGE dividends. Really, though, this work
> should be planned, so everyone knows who is working on what and when.
>
> Hope this helps .....
> Guy L. Werry
> Senior Systems Analyst
> Hudson Bay Mining & Smelting Co., Limited.
>
> -----Original Message-----
> From: Olmos, Fernando (Sericon at Alcoa)
> [mailto:Fernando.Olmos@alcoa.com.au]
> Sent: Wednesday, May 18, 2005 6:36 PM
> To: powerh-l@lists.sowder.com
> Subject: Manual code management practices
>
>
>
> Hi everyone.
>
> I recently re-joined the PH list due to a larger than expected volume
> of work requiring my PH skills.
>
> Just one question, which is baffling a lot of my clients at the
> moment.
>
> Code management:
>
> * What practices are being used?
>
> * What tools are being used?
>
> * Any DOs and DONTs?
>
>
> My client is running Powerhouse, in a HP9000 Unix box, and has
> recently hired a few contractors and myself to do some work which will
> require us to share code, and keep it all seamless without people
> overwriting other people's work.
>
> Currently we use a "repository" method which is to keep the code in a
> central location and ONLY pull it out of there if the file is not
> listed in a "holding location" elsewhere. If the code is in the
> holding location then it means someone is using it, and so the
> developer has to email/communicate with the team to find out who is
> using it, why and discuss how to "share"
> the program.
>
> Unfortunately with this system, as you all know, it's heavily reliant
> on human "good will" and control. If someone forgets to pull out the
> source code from the holding area or at least comment it to say this
> is no longer required, then other developers will be wasting time
> chasing people or making assumptions (because some people just don't
> like to talk!) and start using the program anyway.
>
> Is there a manual system that is better than the above? We are trying
> to stay away from using specific code management tools like CM or VSS
> due to cost and timing spent on installation, training, management,
> etc.
>
> Thanks guys.
>
> Fernando J. Olmos
> Melbourne
> +61 3 9629-9444
> Software Consultant (Information Services - Alcoa
> Australia)
>
>
>
--
= = = = = = = = = = = = = = = = = = = = = = = = = = = = Mailing list:
powerh-l@lists.sowder.com
Subscribe: "subscribe" in message body to
powerh-l-request@lists.sowder.com
Unsubscribe: "unsubscribe <password>" in message body to
powerh-l-request@lists.sowder.com
http://lists.sowder.com/mailman/listinfo/powerh-l
This list is closed, thus to post to the list you must be a subscriber.
--
= = = = = = = = = = = = = = = = = = = = = = = = = = = = Mailing list:
powerh-l@lists.sowder.com
Subscribe: "subscribe" in message body to
powerh-l-request@lists.sowder.com
Unsubscribe: "unsubscribe <password>" in message body to
powerh-l-request@lists.sowder.com
http://lists.sowder.com/mailman/listinfo/powerh-l
This list is closed, thus to post to the list you must be a subscriber.