I quite agree with the following:
> Also, it is my considered opinion that the tool you choose is
> less important
> than the procedures you devise and implement. Just putting the
> configuration management tool in place won't solve all the
> problems, even if
> everyone uses it. You need to put a lot of thought into how
> you want to do
> software configuration management, write it up, deploy it,
> work out the
> wrinkles and consistently enforce it.
The single most important aspect of version control is philosophy. There is
obviously a reason version control has been endorsed in a particular case
like:
-everybody does it
-we need 'backups'
-we would like to track changes and return to old code that worked
when everything breaks
-we need to have multiple users work on the same code at the same
time
If you don't know why you want it, you can't make it solve your problems. I
recommend really focusing on the needs because they vary significantly
depending on the makeup of the developers and the company. I have worked
with a large outfit that used the extremely expensive commercial product
"Rational Clearcase" and almost never had a successful build due to people
committing/checking-in code that wasn't working. Perhaps that was not one
of their goals for version control, but most large groups would say that it
is. So hopefully I make my point that philosophy is most important - there
is not always a "correct" way to use a tool - nothing in any version system
stops you from checking in non-functional code, but if you always want the
main branch to be buildable you could make that one of your behavioral rules
for the system.
Regardless of your choice in a particular tool, I do recommend reading the
SVN manual if you are new to version control - they seem to spend lots of
time on philosophy, so you can jumpstart your abilities on any platform.
On another note, I have heard from a reliable source that "cvsnt" has fixed
alot of the problems (philosophic/ functionality?) with regular cvs, I've
certainly found the developers very responsive to bug fixes & enhancements.
Not having used anything else, I couldn't mention specifics.
Steve
Steve Franks
Electrical Engineer
Tucson Embedded Systems
(520) 575-7283 x171
_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
