Re: (OT) Team programming tools
Jamin W. Collins wrote:
On Fri, Aug 22, 2003 at 07:02:31PM +0200, Benedict Verheyen wrote:
So basically we do not get time to study these tools because they
don't see the need for versioning and so on. If we would use it and we
wouldn't lose time implementing such a system, management wouldn't
complain. That's why i asked for a quick and easy way to start using
something like that.
[snip]
Subversion on the other hand was a
breeze to setup, available on all needed platforms, addresses many of
the problems with CVS, and as an extra side bonus provides browser based
access to the most current repository revision when combined with
Apache2. So, now I use Subversion for all my personal development and
the company I work for uses for our internal development as well.
It sounds like I should take a look at subversion. I've learned CVS,
looking it up on my own at home after noting so many opensource
projects saying 'check it out from anonymous cvs...'. I did a couple
tiny programs using it at home while I read and re-reading 'the
Cederqvist,' cvs documentation until I felt I was competent enough to
help others with it - or at least know what I'm looking for when I
reference documentation.
http://www.cvshome.org/docs/manual/
How to move a project into CVS:
http://www.cvshome.org/docs/manual/cvs-1.11.6/cvs_3.html#SEC38
Additional problem is that one of the programmers hate's commenting
his code and doesn't like to use tools like a cvs. But that's a
different story.
Yes, and one that needs to be addressed. This programmers lack of
comments and use of a versioning system will most likely hurt the group
as a whole in the long run.
I have experiance with this. Unless you become a pro at your versioning
system, be it CVS, Subversion, or whatever and can get a couple of the
other programmers to take it seriously, this programmers complaints will
just be the irritation management won't want to hear. If you are working
on seperate projects sometimes, use the code yourself and highlight how
it helps you during a development or progress meeting. If you are
always doing group projects, then try CVS with just your work or manage
it for your whole group. That method won't show the right people for
commits, but it will give you a rough change history.
I am not sure what type of software your company designs or what
management's ideas are. The impression I get is that it is a 'write it
and forget it' process with very little after-release work for bugfixing
or updated versions. If this is not the case, I can hardly believe this
other programmer hasn't been brow-beaten into writing comments or let go
- unless they are a percieved to be very good. I know I'd be muttering
up a storm and complaining in every development meeting about how long
it takes just to try and figure out what old uncommented code did. Even
if the company does 'write it and forget it', if you aren't all working
on seperate projects it must be taking extra time to review that
programmers code and figure out if a bug is in your code or theirs since
theirs is uncommented.
We would actually be developing faster (reusable code) with these
tools but somehow they aren't convinced of that.
That is the first hurdle that needs to be addressed. Otherwise any step
you take toward using the tools will be seen as a waste of the company's
time.
I don't think that using CVS has helped me write more reusable code.
Code can be copied and reused without a version management system. It
has helped me save time fixing reused code by only needing to fix it in
one place.
Start by using some form of version management yourself and promote it
as a 'code backup system'. I think it takes about as much time to set up
and less time to maintain than a zip archive. I use cvs from the command
line on Debian, and WinCVS on Windows. Both take me very little time to
operate. I will be shocked to hear that they say it's a 'waste of time
and resources' to keep a backup of your code with software that let's
you go back to yesterday's version if they didn't like today's changes.
If your company releases fixes to their published software, I believe
that as you adeptly use some form of version control management software
and point out when and where it helps you, management should get a clue
and eventually tell you how great it was that they told you to use it.
If your company has one product per developer and they are callous
enough to not fix bugs in released software (or you're all that good)
then maybe a version control system wouldn't help you. The fact that you
are looking into it shows there is a need.
This section on 'What CVS is not' is good reading, and may apply to
other version control software:
http://www.cvshome.org/docs/manual/cvs-1.11.6/cvs_1.html#SEC3
The short on what CVS has done for me:
* Shows who committed what and when.
* Provides and interface to quickly compare code changes between
versions of the file.
* Facilitates the building of a changelog.
* Allows me to branch off a stable version for bugfixes while continuing
with the next version.
* Enables multiple developers to work on the same project, and sometimes
on the same file, while doing a good job merging the changes.
Reply to: