branching/patching questions

[alexanderpj]

We are currently evaluating Vault as a VSS replacement, and so far things look really good. We do have some questions as it appears we will have to change some of our procedures to work with Vault. The big question is how to manage changes from development to production. We are a web development team, and we push changes out very frequently (3-5 times a week).

I am open to suggestions on how to do things better. Note that I did not come up with these procedures, they're just "how things are done here". Accordingly, the more our procedures would change, the greater the resistance. I'm the most junior member of the team and since I suggested finding a VSS replacement, the bulk of the work has fallen to me.

First, current VSS-based development:
We have two branches under $/ : dev and prod. The folder hierarchy is identical and all files are shared from dev to production. The current production versions are pinned in $/prod. To edit a file, I check it out from dev, make my changes, test my changes locally, check it in. I then log into VSS under a different user name (TEST_USER) that is shared by all developers, check the file out (to a different working folder - on the test server) where all the developers test the change. (Yes, I think it's weird having to have 2 VSS instances open all the time...)

Once the change makes it through testing, our lead developer pins the new version in $/prod. He does a "Get Latest..." to a staging folder where he then selects the new files by hand to be burned to a CD to take to our customer location to update the web server there. (Which exists on a totally isolated network.)

The first thing I noticed in Vault is that if you pinned a shared file it shows as pinnned in both locations, preventing new development in $/dev. (This behavior is contrary to what Eric Sink describes here: http://support.sourcegear.com/viewtopic.php?t=9 , a little over halfway down. Am I missing something?)

I saw a similar question in the forums here: http://support.sourcegear.com/viewtopic.php?t=7200 and the response seems to be "Use branching".

So that's what I'm trying right now, I'm just not sure I'm doing it in the most efficient manner. I set up my folders by branching, so I began with two identical branches $/dev and $/prod. (With the versions in $/prod being one higher b/c of the branch operation - no biggie.) So I do my check-out, edit, check-in of the files I'm changing. Assuming everything passes testing, I now select Tools-> Merge Branches and go through the wizard, selecting the origin and target folders, select the folder revision I want to merge, and so on and so forth, clicking through eleven or twelve pages of the wizard, and finally committing the change to the production branch. This seems like *a LOT* of work and my coworkers will definitely consider it a major inconvenience. Is this considered "best practice"? Am I missing something?

My other question is how to do what we call a "baseline audit". We have a crusty old tool that will print out which files have changed between two given dates (I see that the Show History tool can do this for us) as well as print out the pinned version in $/prod. I'm having trouble getting the history tool to show us that data without displaying any of the extraneous versions. How do I get vault to show me a list of either (1) all pinned file versions or (2) just all current/most-recent file versions. This is not so much a history request as current status.

Thanks,
alexanderpj

[lbauer]

We use branching at SourceGear, rather than pinning.

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

Code: Select all

$\Trunk (where the development of MyApp 4.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

         MyApp 2.0 (includes labeled maintenance releases)

                 --src

                 --docs

         --test

         MyApp 3.0 (includes labeled maintenance releases)

                 --src

                 --docs

         --test

Here's how it works.

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.

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.

first thing I noticed in Vault is that if you pinned a shared file it shows as pinnned in both locations, preventing new development in $/dev. . . Am I missing something?)

If a file itself is shared, it is possible to pin one of the shares. However if you pin a file in a shared folder (the folder is shared, not the file), the file in the other shared folder is pinned -- all actions on items in each folder are mirrored.

How do I get vault to show me a list of either (1) all pinned file versions or (2) just all current/most-recent file versions.

You could run a history query with History Explorer, limited to Pin/Unpin actions, save the results as a CSV and sort out the Unpin actions. Or you could run a History query from the Vault Command Line Client, excluding all actions but Pin and parsing out any Unpin actions.