How often should a programmer check in program code? 2

[LeonelSanchezJr]

I have been appointed as the Administrator for Visual Source Safe for the company due to the fact that some programmers have lost their code in the past and this runs into money.

The majority of the programmers that do use Visual SourceSafe DO NOT CHECK THEIR CODE IN on a daily basis. Their reasoning for this is becuase they do not see why they should check in their code if the code is not working / complete.

I agree with this because I've always done the same thing myself. However, my question is what happens if their hard drive crashes? Their new code will be lost.

I know there is a ROLLBACK feature, but none of the programmers have ever been able to use it successfully.

There is also a PIN / UNPIN feature. I'm not too familiar with it, but it looks like the programmer can not check their code back in which totally defeats the purpose of using Visual SourceSafe because their changes will not be backed up.

Please advise because these programmers are my co-workers / friends and I don't want to tell them to do something that will actually jeopardize their work.

Thank you. (|>

 

[rgh]

To get round this problem I forced the programmers to use a specific folder on a central server as their work folder with anything that they worked on checked out into these folders. I then created a batch file that zips the contents of the folder into a zip file, which was then moved into a folder with the current system date as the name. E.g.

\\server\development\Programmer1
\\server\development\Programmer2
etc….

When I run the scheduled backup you get
E:\backup\20010817\backup.zip
E:\backup\20010816\backup.zip
Etc….

This backup is done on a nightly basis and on 3 PCs just in case……

Another benefit of this approach is that if you need to do a code check on some work before checking it in you do not have to worry about password or permissions on the programmers PC.

I would hope there is a better way to do this, however it does work.

 

[kamikrazy]

The way we make sure the programmers check in code (even if it's not working) is to maintain to separate VSS databases: one for production code and the other for development. The VSS databases are maintained on an application server, physically separate from our file server. If your team is small, you can get away with one VSS database, but I would still set up separate development and production projects.

We have a policy, clearly stated: before leaving, check all code into the development VSS. No exceptions. When they are done with an enhancement or bug fix, they will then apply those changes to the production VSS. The other thing we require: all working folders will reside on the primary file server. It's a RAID5 box, with nightly backups. Barring a some catastrophic disaster, we have at least three spots where we can find source.

Just because they think they shouldn't check in non-working code is not a valid reason to put your development at risk.

Rollback is used to go bo back to a previous version. You lose all history and changes. For example, you have 10 versions of main.frm, and you do a rollback to version, all changes since version 8 are lost. Normally, we don't do this, since it's remotely possible that we'll need those changes, so we do a "virual rollback". Say you want to get back to version 8, you check out the file, go into the history, and do a get on version 8, then check it back in. In the history, you'll have a version 11 that is identical to version 8, but you'll still have versions 9 and 10 just in case. Just be sure to comment the versions as to what was done.

Pinning is usually used for shared files, since it stops people from changing it. You go into the history of the file, then pin the specific version that you want them to use. We rarely use this feature, but it does come in handy on our shared classes. I can pin at an earlier version so when programmers get latest, they get the "production" version. If they need to make a change, I'm made aware of the change so I can unpin the file.