Production deployment for sql server objects

[mrmikolyski]

I am evaluating source vault for use as a sql server object repository. I was wondering what the best options are for retrieving files by a label or a given project or if there is some other way of marking them so that the group that was edited for a given project can be retrieved at that specific version level. Currently we have cvs in use but that does not integrate with our development tools but it does allow for a checkout based upon a lable/tag.

[lbauer]

You can apply a label on a file or folder at a particular version. Then you can get the labeled version from the Show Labels command.

Would that meet your needs?

[mrmikolyski]

Thanks for your response Linda. It appears that this only works if I am trying to retrieve one file but I need to retrieve many files at once that have the same label. it seems that you can do a get command on one file in the show labels window but not on multiple files. Is there anything else that could work? Is this complex enough that someone in support would need to talk to me so that we can get a real solution to this problem? It is pretty important and I would really appreciate it. I really don't want to continue working with cvs.

Thanks,
Matt

[lbauer]

You can apply the label to a folder and get all the items in that folder at the version they were at when the label was applied.

It sounds like you don't want the entire folder, is that correct? Only the files that have changes since . . . the previous label? version?

[mrmikolyski]

Linda,

That is correct. Applying the label one file at a time at the time they are modified is acceptable. We need a way to deploy all of the files that have the label in one fell swoop from multiple folders or projects even. This should be a process that allows us to pull out all of the labeled files at the version that was labeled even if its not the current version. That way we can extract all of the changed files and there respective changes from source vault at once and deploy them to there respective servers.

Thanks,
Matt

[lbauer]

There's no built-in command to do this. You might be able to use the command line or Client API to label a parent node, make your changes, do a GetlabelDiffs and extrapolate from there to get the files that have changed.

[mrmikolyski]

Linda,

Does this work with source vault 4.1.4? Is there another way to manage the latest version moving forward with development but then a prior version is determined to need a bug fix, I need to check out the code at that old version, fix the bug and then merge with the latest code. How do we deal with this scenario?

Thanks.

[lbauer]

One way to deal with on going production, plus maintenance releases or bug fixes would be to use branches.

Here's how the tree structure would look with a product
in development at version 2.0. Let's call it "MyApp"


You start with your development of MyApp 1.0. This is your trunk.
When you're done, you label (tag) the final code MyApp 1.0 and
create a branch, also called MyApp 1.0.

Code: Select all

$\Trunk (where the development of MyApp 2.0 is progressing)

     src
     docs
     test

$\ Branches

         MyApp 1.0 (this includes labels for maintenance releases,
                          1.1, 1.2, 1.3, etc.)
                 --src
                 --docs
                 --test

Now work on MyApp 2.0 continues in the trunk.

Meanwhile, you need to fix some bugs in MyApp 1.0. You fix them in
the MyApp 1.0 branch. The bugs are fixed, and you label the MyApp
1.0 branch with a MyApp 1.1 label. Then you merge the 1.1 changes
into the continuing development for MyApp 2.0 in the trunk.

MyApp 2.0 is done. Make a branch called MyApp 2.0. You might also want to label it the trunk at that point.

Continue work in the trunk for MyApp 3.0. If you need to do
maintenance releases for MyApp 2.0, do those in the MyApp 2.0
branch, label each, then merge them into the trunk for 3.0.

So in this model, the trunk is where current development occurs, and
the branch is for the finished version and any maintenance releases.