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.

scenarios:

-to fix as of a version, create subproject/branch, checkout a build to that dir, fix, and then merge changes in. In versions, can only branch a subproject (curious). After doing that, use "files to checkout" to get all files there for testing (assuming they're needed. May be able to get by with just checking out those needed.)

- start working on a fix, and in the midst are told to fix a bug in one (or a few files). Don't want to incorporate the incomplete fixes, but need to have stable platform of the code that was deployed for the version that needs the bug fix. Assuming that you were using version control, and when you were at a stable point in the coding of that version you "labelled" the files as a milestone or a build, can retrieve all the files for that version and work on them in isolation. First, check-in current incomplete versions (risky, may want to label them as incomplete), then check out all the files as of the build. Make the fix, deploy it, and then merge the changes made into the version you're working on. (question: how to cause bug fix to be available in later "checkouts" of that build? better still, how to have bug fix apply to intervening builds?)

I think the solution is to use a subproject branch, and then merge. But that doesn't quite solve the problem.

Asked Starbase:

Folks, I am starting to use what for me are the more complex aspects of your Versions product. Among them are builds.
I understand that I can label a set of files at a given version with a "build" or "milestone" label. I further understand that a benefit of that is that, should I need to make a fix to code at that revision, I can check-out all the files for that revision (after checking in what I am working on first, of course). I have 2 questions about this process, though.
Let's assume I have a milestone A and Milestone B and builds B.1 and B.2. I'm working on build B.3 (not labelled as such yet, of course). And I learn of a bug in the milestone A code. I proceed to check-in the fixes I'm working on for B.3 (they're incomplete, but I have to fix the bug). I check-out the files for version "milestone A".
Once I fix, let's say, the one file in error. I ship the code (or in my case FTP it to the server running Milestone A). Now what do I do with this file? How do I cause that fixed file to be a part of any future check-outs of Milestone A? Or Milestone B or its builds? Am I missing something obvious? It seems when I check-in, it will create a new version after my last check-in, Milestone B.3. What will tell me in the future to include that fix in any checkouts of Milestone A?
More important, if the code has since been changed in Milestone B, then I really need to merge its changes into what's available there. If I check out Milestone B, I need that fix as well. But I need it in a form that it can accept. Again, how can I get it into the code available for Milestone B and its builds?

branching: in versions, use project>subproject>branch (see help "create a subproject branch" for scenario, and also "branch subproject")

merging: in versions, lock then merge (in versions interface). See help for "merge files" for scenario.

-to work on files with entire project in working directory, working alone, can choose to have files marked read only on check-in. this prevents you editing them without checkout. Since this can only be done in projects tab and after opening project, is a bit of a pain.

Could instead choose to checkout immediately on check-in, thus preventing that hassle. But the cost is then that you can't easily tell in Studio what's been modified from the checked-in version. Can run a difference, but that's a hassle too. But you can use a feature in Versions' interface which lists which files need to be checked in. Use "files to checkin" drop-down. May be the way to go.

(In a multi-user environment, using "check out immediately" on checkin would be troublesome.)

consider that a number of files is in a directory, and you rely on the file date to tell how old a file is and whether it's been udpated in a while (for whatever reason you want to know that). You make a change for some minor reason to a large number of files, including this one. Now, oyu no longer can track this file's history by its date, because it will change. In this case, a version control system is the only way to track that.

- working on 3 programs to add an enhancement. choose not to upload those while working on them. Then a problem crops up regarding another unrelated program. You determine that the problem there affects multiple programs. You do a "extended find" to locate and change all the affected problems, test them (if you're good) and send them to the server.

But now one of them fails on the server because it was among the 3 you had started working on for the enhancement, and you had started making those changes which rely on the other 2--only they were not uploaded because you weren't done working on "them".

Now you have to back out the changes made to the one in support of the enhancements, and make the changes in support of the "problem" to put that up on the server. Then you can get back to the enhancements.

How to do this easily without version control? When you uploaded to the server, you wiped out the current version. With version control, if you always checked in before uploading to server, you could save off the latest version that had "both" changes, restore the version checked in before starting the enhancement changes, add back the "problem changes", and then check that in, upload it, and add back the enhancement changes.

Of course, if the enhancement changes were complex and threaded throughout, it would be difficult to add them back (but at least the version control allowed easy REMOVAL of them to restore to the previous state). It may be possible (through means I don't understand) to also merge back in the enhancement changes from the copy you saved off prior to trying to recover. (add knowledge: can lock a file from within Versions to be able to check in changes without forcing a checkout to overwrite them)

don't even get into "documenting" changes on checkin. Just checkin before uploading to server. Then, a record is kept of what changes were made. Can just use "compare" later to see "what" changed. (May even want to setup upload process to run from different directory than working dir. And have version control software put a version into that dir for uploading. VSS supports this in 2 ways: "shadow folders" and "web project deployment"

Further details available for: