Visual Source Safe (VB 6.0)

Topic

New Reply

Does anyone have any sites that give a good overview of VSS? I am just trying to learn how to use it.

I’m looking for a “Dummies Guide to VSS” site, just to make sure I’m doing it right.

Thanks,

Reply | Quote

Replies

Well, I used the built-in help and a friend to learn. Here’s a few observations though:

1) Don’t allow multiple checkouts until you have mastered the merging of files.

2) Learn how to merge changes from multiple users. Practice on a dummy file or
two before merging live code files.

3) VSS is not very useful unless you allow multiple checkouts.

4) The most frequent reason for lost changes is improper us of multiple checkouts.

5) Use the VSS toolbar for checking out an in. It’s makes the clunky interface a bit easier.

Reply | Quote

Thank Kevin.

I hadn’t planned on using it for multiple checkouts. I am using it locally, as a single developer, to allow me to branch my code. That way I can work on the next version of the app while keeping the code base for the previous version so I can make bug fixes.

It certainly isn’t an intuitive interface, that’s for sure.

Reply | Quote

Bryan,

>>It certainly isn’t an intuitive interface, that’s for sure.

You got that right.

Not sure it’s worth the hassle to use VSS for what amounts to
simple versioning. But, if you figure out how to make multiple
versions easy to use, let me know. Besides the basic shared v. local
versions, the only way to version (that I can see) is the admin tool’s
archive facility.

Reply | Quote

I’m not sure what you’re looking for Kevin. What do you mean by multiple versions? YOu can always create a new VSS project share the objects from an existing project and then branch them in that project. That maintains the history up to that point but changes to that branched version won’t affect the other projects and the original version’s further changes won’t affect the branched project. You can also Pin a version at some point. Rollback allows you to discard the changes you’ve made to a particular object and return to an earlier version that worked.

I just realized you might be talking about the Share/Pin/Branch method of maintaining multiple versions. Is that what you meant? If so, the help topic at Maintain Multiple Versions of a Project seems pretty clear to me, although it does keep referencing the DDUPD, which only applies if you have upgraded to VSS 6 from an earlier version.

Reply | Quote

Thanks, Charlotte. I’ll check out Maintain Multiple Versions of a Project. Sounds like
something I need to know but didn’t.

Reply | Quote

It really isn’t hard to use, Bryan, although the interface is a bit intimidating. There’s a manual that comes with the full version, but it isn’t really very helpful. The on-line help is about as good as it gets, but you won’t do a lot of damage if you just play around with it. We use it in our office, where there are 3 developers working on multiple versions of about 5 products, so it gets quite a workout. On a stand alone setup, just use the admin tools to give yourself a login and password and then create a project or rename the default one that gets set up in Microsoft Visual StudioVSS. If you’ve installed the client tools from the Developer disk, then all you have to do is pick a database, select Source Safe from the Tools menu and select Add Database to SourceSafe. That will put the current database into Source safe and you can then start playing with it. We do not enable multiple checkouts at work because it would make us all crazy. With them turned off, we can see at a glance whether someone else have an object checked out and the VSS project explorer will show us who has it checked out.

Once you get used to working in it, it’s quite comfortable and makes you feel a lot safer, since even deleting the database file doesn’t delete the sourcesafe project. There are a lot of features you’ll probably never use and that we don’t use at work either because we simply don’t need them. You can have separate VSS databases to hold projects at different stages if you want as well.

Reply | Quote

Thanks Charlotte,

I have been using it for the past couple of days with a VB Project. I am starting to get used to it.

I think my biggest issue was the fact that it LOOKED “big and scary” but now I can see the benefits. I was even checking out the history of a class module that I’m working on. Pretty slick. Now when I royally screw up my code, I think can roll back to a working state and try again

I haven’t tackled an Access project yet, but one day soon, I’m sure I’ll give it a go.

Thanks again for you, and Kevin’s, input. It has helped me get more comfortable with it.

Reply | Quote

Now that I am starting to get the hang of VSS I have a couple of questions about using it with VB 6 and down the road Access 2K

Sould I Check In/Out components from the VSS interface of from within VB? Is there an advantage or disadvantages to doing it either way?

Should I only check out the component(s) I am currently working on, or the entire project?

Since I am working in a stand alone environment with VSS, how often should I check in my changes? Hourly, daily, when I quit for the day, when I make significant changes?

Thanks again

Reply | Quote

I think how you use it is really up to you, but I’ll tell you how we do it at work. We check out objects only from within the application–in our case, Access, in yours, VB. When you have quite a few VSS projects involved, it helps to know which one you’re in when you’re checking stuff in and out, and you can’t do it both ways. You can either check things out from VSS or you can do it from within the particular application project, but not both, so find the method that is most comfortable for you. I generally find it easier to check out individual objects rather than everything at once. In Access, though, you have Data and Misc Objects (tables, references, etc.) that can only be checked out or in all at once, so you have no choice there. Those objects aren’t saved individually in the vss project, so it’s all or nothing for them. As for how often you check back in, that’s a question of granularity. I put comments in my code to tell me what particular modifications were made, but it’s difficult to remember or summarize the changes for the VSS history, so I check back in fairly frequently. Of course, in a multi-developer envirornment where objects are shared between VSS projects, keeping something checked out for a long time affects other developers, which is another reason to check in frequently. If you start colliding with yourself between projects, you’ll learn the most effective frequency for yourself.

I think the real beauty of VSS (which is a pretty ugly baby, I agree) is the way you can share objects between projects. If you have a library of code in a particular module and you use it in every project, you can just drag it from one VSS project to another to share it. Then changes you make in any project are shared with every other project unless you branch the module for a particular project. Can you say “reusability”? The history shows not only the changes that you’ve noted but also the project where you checked it back in, which is handy as well. And it’s very useful to be able to compare differences between versions within the history.

If you haven’t yet figured it out, there are two ways to use differences in VSS, one from the project level and a different way from within history. The project level lets you compare objects between projects, but in history, you can pick and earlier version of the object and check differences from the current version. That let’s you see exactly what has changed, which can be a real help and is a LOT easier than printing stuff out and doing a line by line comparison the hard way!

Reply | Quote

Thanks everyone. I’m starting to feel more comfortable using VSS and it looks like it’ll save my butt from myself [indent]

---

If you haven’t yet figured it out, there are two ways to use differences in VSS, one from the project level and a different way from within history

---

[/indent]No I haven’t figured this out yet but I’m sure I will one of these days.

Thanks again.

Reply | Quote

When you select History from the VSS window, it shows you all the checkins you’ve done for that object. If you select one of those checkins, you can then click Diff and compare it to the latest checked in version. If you are in an application and use Tools–>Sourcesafe to select History, it will compare the checked out version to the last version checked in. Handy.

Reply | Quote

Just to add to what Charlotte has mentioned. When you do a compare, you have options to ignore whitespace and to ignore case. That can be useful when you want to see real changes, not just code that you’ve formatted nicely or variables in which you’ve changed capitalisation. They are sticky options, so will keep the same settings between sessions.

You can additionally check any version in history against any other version- or even between two files stored locally, if you wish.

Reply | Quote

I would be checking out only components I’m working on.

Also, if you’re working on multiple projects, VSS makes it easier to share code. Look at making modules of common code.

I tend to check in changes when I’ve made significant changes- usually when the changes are working, but at minimum, when you have a clean compile.

Also look at having another database. Use the one you have for day to day work- but have another one for code which you’ve sent out.

Reply | Quote