Since your browser does not support JavaScript, you don't see any navigational toolbars above. For now, please use the navigational links offered at the bottom of each page. We are working on a better solution.

Tips:

be sure to turn on the "force check=in reason" in the project properties in versions

keywords in versions are CASE sensitive (must start with cap, and some have embedded caps, like NoKeywords).

Best to put inside <!--- comment block, and to use Nokeyword to stop versions from parsing for further keywords. Here's a good setup:

<!---
$Log$
$NoKeywords$
--->

Need to turn on keyword processing in project using versions interface, and project>properties>defaults> and check the "keyword expansion" box. No need to use the "settings" button, which is used to specify a prefix for output of the $Log$, which is unique in putting out multiple lines on expansion. But since we're using HTML and comments can span multiple lines, there's no need for a special prefix (in fact none would work since it doesn't offer a suffix, which would be needed even if we did use it).

Also, won't see change in use of keywords (made in versions interface) unless you reopen the project in studio. see annoyances above.

Can use $Date$ keyword to put date into a static file on publishing it. No more need to update that manually. (Note, though, that this is the date and time in Versions. VSS has dateonly keyword.

May be tempting to put a database into the project to track changes to that, but be VERY CAREFUL. A deploy to the web site could overwrite the db being modified there. Usually not desired. Put DB's in own directory and, perhaps, own project.

challenges in studio interface: finding projects tab, creating new project (from projects tab, use new project or right click on list of projects), remembering to add project to source control, adding project to source control (only via right click on project name in list of projects), remembering to then add files to source control, adding one or more (or all) files to source control, remembering to use it when modifying files under source control.

don't forget while adding project to source control to turn off security (if no need for password) and turn on "force check in reason" under advanced tab.

be careful in creating projects in studio interface. just creating project does not put under source control (and there's no prompt). must add to source control. Also, then just adding to source control doesn't add the files. Must do that manually as well (can select all).

In studio, if there are many files in the project it will slow down the interface to open the project, perform check-out/check-in, etc. Also slow just moving between folders in a project. Simply is a factor of the number of files in the project. one thought is that you don't have to have file in project to have in source control. Can place into source control in versions (or in studio and then remove from project but not source control).

Good candidates are files that won't change often or that you really don't care to track (gifs, old stable html documents, etc.)

This way you get the benefit of version control without needlessly slowing down the studio projects interface.

Plus, when you need to check out a file, can do it from versions as well, and optionally add it to the studio interface if you'd like.

Almost begs the question, why use the studio project interface if only being used for source control (if used for cross-directory feature, may be worth it).

- if only for version control, maybe just use versions

- if you go that route, then may want to limit what's in the version project (but is two edged sword: may need ability to track a file. Can set it to read only, and if you need to update it, add it to versions.)

-note that in Versions, the file context menu (right click) does not list ALL the things you can do to a file. Use File command on menu, for Merge for instance.

- note in versions that there are powerful management reports not available via normal "reports" option in File command from menu. Instead, use "audit" tab below the project window (default display is "files". Can select "audit" or "team" (which is nothing in single environment).

Note that to see file level audit reports, must select button to left of filter, for descendants.

Note also the available filters, such as last 24 hours, this week, this month, "user=me", etc.

And note that using this "audit" tab opens a new "audit" command menu, which includes options to print these reports.

-Note that in versions interface, you can't delete a file from the project unless you first *lock* it. Then several greyed out features on the File command become available (including merge).

- while you can designate a "build" or a "milestone" in versions, can't really do much with that. It's just a label. Can't even easily "get" a project into a new working directory with all versions at that label. Have to open the project, select click "all descendants", select all files, and then use check-out. But be careful not to use right-click "check out", use menu command check out. It will prompt for the version label to use. It begins checking out, and will prompt as it detects files changed in working dir that would be overriden. (Should checkin all files first.) Would be nice to be able to specify place to put these checked out alernate versions.

VSS provides both a prject checkout and a deploy command that are more akin to what we need.

-rather than use studio's interface for checking files in (which is slow, especially with a large number of files in the project and a number of individual checkins to do), use versions. It's not only faster, but you don't risk hitting the "undo checkout" button by mistake. More important, you can easily list all the files that need to be checked in (using the "files to checkin" filter on the project file list), which you can't even do in Studio. (Can also easily add files in working dir to a project, which you can't do in Studio). Using Versions to check in not only does mark a file as read-only on check-in (if that option is selected), but it also is reflected immediately in Studio's project list with the red dot icon. Now why can't studio do that update that quickly? Still more, you CAN use keyboard shortcuts (for highlighting the file, doing a compare, and checking in a file, all of which require mousing around in studio). Can even use it to check files out and edit them in studio. Saves having to deal with the projects tab interface almost entirely.

in fact, with this approach, don't technically even need to checkout a file to edit it. Just lock it.

- in versions, you can do a secondary sort on a file list (but note that this will not make sense for many primary sort fields, such as name, date, size). Unless there are duplicate values, no secondary sort will be possible. You'll know if it's possible if the primary sort creates a "grouping" band.

- in versions, note that you can't check out an older version of a file by right clicking on it to select checkout. That will get the latest version. Instead, you can either go to its properties>history, or even easier, use the menu command file>checkout. This presents a dialog box.

-in versions, can compare versions by selecting multiple versions within a file's history and then select compare.

-while you often can't merge files in versions, you can merge any file in Visual Diff. (if intention is to a local updated non-checked out file with a checked in version, will need to check out the version under source control first to a different location and then merge the 2.)

-in versions, to check out several files at a given revision, build, or check-in date, select the files and choose file>checkout.

-if making several updates over a few days, and don't want to check-in and check-out constantly, consider still checking in without removing lock (in studio, use checkin with the "checkout immediately" option checked; in versions, use checkin with the "keep files locked" option checked. This can also be set as a project default.)

- in project properties, turn on defaults>time stamp working file with checkout time, particularly when using keywords. without this, the time stamp of a file will be changed to the time of check-in (because with keywords on, the file is updated with the keywords at the time of check-in. This could confuse a comparison between the local version and a version ftp'ed to the server). (not sure what negative impact this might have if not using keywords)

Further details available for: