And you think I'm different? I most often am the IT support only for the single reason that people think I'm "clever" with computers. Does that mean I like it? Don't you think I try to avoid it? However, I can't ignore the situation - source code needs to get backed up. Source code needs to be version-controlled.


No, this is surely an example of you making the wrong assumptions.

> Have you looked at just downloading and installing CVSNT on your workstation machine?



CVSNT is a port of CVS for use on Windows. There is both a client and a server side available. The port to Windows have added a number of features - for example using Windows authentication besides the traditional pserver or ssh. And it supports unicode.


If I work in my own company, it would be very stupid of me to try to underestimate time/costs involved. I have incentives for maximizing my own productivity. Same thing if I work in a smaller company that I own a percentage of.



It takes a couple of minutes to add a user.
It takes a couple of minutes to assign specific project rights, unless everyone gets full rights from the start.
If using the copy method, I still need to give out access rights to the target machine.
So access rights/users is about same-same whatever method.

Sorting out conflicts? Depends on how you work. You normally let the developers sort their own conflicts. If you copy/paste files and have multiple developers you will always have conflicts - unless of course you just miss them becase the copy/paste overwrites someone elses changes silently. Big oops.

The repository route gives one more way you can have conflicts - by working in multiple threads and then merge the changes. If you don't like these merges, then don't work with multiple threads. You don't have that option anyway if using ZIP files or copying directories, because then you would always have to spend sigificant times with three-way diffs.

Moving repositories? Not more work than moving your directory trees where you store all your saved snapshots. And the big question is of course - why the need to move around repositories?

Setting up new "services" for a new machine? Same if the source code is stored on just a standard file server - that machine still needs standard services for backup, time synchronization, ...

For the machine hosting a source code repository, there are basically two alternatives:
- the machine sees the repository as just a shared directory tree.
- the machine has a directory tree to backup (often not shared), and also a server program that is listening for commands on a port.

And that machine can be your workstation. Or your workstation with a virtual machine running in it. Or an existing server. Or an existing server with a virtual machine running in it. Or a dedicated machine.

So if you have an IT guy who have to spend a lot of time, then it is time to sit down and analyze exactly where the problem is.
- are you using the system in a problematic way?
- are he doing something you as developer should have done?
- are he doing something wrong?
- would it really have made a difference if you had zipped directory trees?

The last 12 months, I may have spent two hours in total of administrative time on source code repositories. This for 8 developers and quite a number of projects.

If I want to modify a single source file and someone else also changes it concurrently (and we chose not to lock the file) then I do not consider it administrative time when I have to resolve conflicts in the source code. The alternative (what I would have had to do if just copying files) would have been to throw away my changes and let the faster copier win. Then add my changes again. Handling the conflicts is normally way faster. And this is a developer task, not an IT staff task. The C in CVS is "Concurrent" - i.e. a tool intended to allow concurrent development of source code without a need to lock out all other developers. SVN of course also handles this.

If I want to develop using multiple tracks and then merge them together, I don't consider that administrative time. If I do want to separate work-in-progress from maintainance releases, I have to merge bug fixes whatever methods I use. And it is a developer task, not an IT staff task. I can use diff and manually copy/paste code. Or I can have the versioning-control software automatically move code lines as long as there are no conflicts, and have it just mark the conflicting blocks for me to consider.

What does take time in an organisation is not really the use of a source-code repository. The expensive part is normally things like:
- having dedicated build machines supporting automatic builds with controlled compiler versions and of tagged releases
- having configuration control - which customer should have access to what software releases. over-the-air packages identical to factory releases?
- having test solutions - nightly builds with regression testing etc, test servers, devices running long-time tests, ...
- having checkpoints with sign-offs: This change accepted by customer? This set of features to be included in the revision? This release properly tested? This release accepted by customer? This set of configurations/versions for use on the customer devices? This shipping order complete with all required information?
- making sure all required documentation exists
- ...

The repository is the low-maintainance part that pays for itself greatly down the road.

The fact is that the amount of time I have spent in this thread alone is way more that it would take to have a repository up and running, and having checked that a "backup-now" does work. The next logical step would be to check tomorrow that the backup files did reach the backup media.

Developers who have never used any source code repository may have to spend a couple of hours reading the quick-start-guide and the FAQ for the selected tool. But no more time than they can reclaim within the first year because of the improved ways to track changes or separate work-in-progress from maintainance releases.