Share/Branch

[maggieo]

We are currently on VSS 6.0d. I manage the VSS. Every interval that we do a full "release" - I do a "Share" and then "Branch after Share" from my "DEV" version of VSS to create the next QA version. That QA version has all the DEV history. If things are checked out of DEV when I do this, they are NOT checked out of QA. I don't even understand the "Branch after Share" part of doing this - but that's how I was taught. We are ready to get a new product, ASAP, but I need to know how I will accomplish this task before we can buy this product. Also, I "RENAME" QA to PROD, when the time comes, then I "Share , with Branch after Share" the DEV to the new QA. For the next build/release (full), DELETE the PROD version, rename the QA to PROD, and need to know how to do the "Share, with Branch after Share" to create the new QA from DEV.. So DEV stays the same forever, and we just "promote" new versions "up" from there. I hope I have explained this correctly. I don't believe our developers use and "merge" functions currently in VSS.. They show diffs all the time and do manual "merging" on their PC of the code, and then check in the "merged" version to either our QA or PROD version of SS - all in one SS Database. So let's say our product name is "Maggie" - then under Maggie there are always three versions, PROD, QA & DEV. Any and all assistance/advice here would be much appreciated as we need to move to a new product asap and we are seriously considering this one. Thanks very much

[Beth]

With Vault, you could perform the share and branch from share just like you currently are in VSS. This means no changing how you work, but there are better ways of dealing with this. Your current method add additional size to the database that isn't needed, plus it essentially duplicates data.

If you are interested in covering other options, just let me know.


A good general overview of how we see a person working can be found here: http://www.ericsink.com/scm/source_control.html.

[maggieo]

Hi Beth,

Thank you so much for your prompt reply.. Firstly I'm releaved to know that I can do what I "need" to do - but I am definitely interested in talking with you about other options. I realize that we create size growth this way - but we do need the history to "promote" with the code.. I actually used to branch "downward" and that created tons of nested stuff, and eventually someone gave me the idea of doing it the other way - basically branching "up" from DEV and never changing the DEV version. So I'm not sure how much increased size we are creating, since the "PROD" version gets deleted every build.

My Senior Developer here has demo'd this software and I'm going to look at it too, but as long as we can figure out how I maintain three versions of code along with history, we are good and I believe we will be purchasing this.. but I am definitely interested in hearing other options.. Let me know how best we should talk about this.

Thanks again - Maggie

[Beth]

One possibility is to create 3 shares.

Share 1 will always have the latest code...your Dev Share.

Share 2 will be pinned at the version at the version you need it to be at. I will not have all the latest code until you unpin, and repin.

Share 3 will work just like share 2. It will be pinned at a folder version, or individual files can be pinned, and then to receive the approved changes, you would unpin, and repin it at the version you want.

Going this method would require labeling folders so that if you get too many changes, you can easily pin the label that represents the version you want that folder to be at.

How often is data pushed through your cycle of Dev, QA, and Prod?

If QA finds errors in the code, where is the code fixed at? Is it fixed in the QA folder or the Dev folder?

[maggieo]

Hmm - interesting.. I used labeling a long time ago in another company, and it didn't seem to work for us - but that was long ago.. We generally do a "full" build/release once a month.. The "norm" is that developers do all their coding and put their stuff in DEV.. At build time it all promotes up, as QA goes to PROD.. For "hot fixes" as we call them here, they have put their code in DEV - tested it there, then they have to put it in QA - checking for, and merging with if necessary, other changes that are in QA (but they should also already be in DEV), then I "get' that code, build/compike and deploy. and for a PROD Hot Fix, they basically have to check their code in to three places - prod, qa and dev, but generally it will have already been to DEV and QA before ever getting to PROD.
Also, there are times when we keep PROD at it's current version (I do all this version labelling in the projects as a lot of other things depend on version), but we'll "throw away" the QA and "create/promote" a new QA that will have all the DEV code in it, so that the developers don't have to Hot Fix a ton of code to QA for Business Analyst testing.. This usually only happens during conversions when there is a lot of code changing going on, and the hot fix forms are time consuming for the developer to fill out and there is a whole approval process as well - totally separate from SourceSafe, but part of the process. I don't know anything about "pinning" though.. I could try to read about it.. Let me know if this all makes sense.. Also - if we're throwing away PROD (sourcecode) every build (I used to archive it but that stopped working in our ancient SS a long time ago!) - how is it that we're increasing size all the time?
Thanks again so very much for your time..
- Maggie

[Beth]

In Vault deleted items are still in the database. We do have an obliterate function that will remove an item and all it's history from the database permanently, but that could make it so that you can't use our Export/Import tool to move code and it's history to different repositories or servers. If you have no reason to ever use Export/Import, then it won't be a problem to obliterate.

We have some best practices articles you might find helpful as well.
Best Practices for setting up repositories: http://support.sourcegear.com/viewtopic.php?p=5183
Best Practices for Managing Branches: http://support.sourcegear.com/viewtopic.php?t=193
Basics of using Label, Cloak, Share, Pin, Branch and Merging: http://support.sourcegear.com/viewtopic.php?t=9
KB article index: http://support.sourcegear.com/viewtopic.php?f=13&t=792
How to label as part of a build script: http://support.sourcegear.com/viewtopic.php?t=15

I included the labeling as part of a build, because that's how we do it here. A build happens and it gets labeled. Then our QA department performs a Get on the build label and tests that code, which developers continue working.

Continuing with your current methodology will be possible with Vault, so you don't have to feel like you have to change. I'm just providing some alternative ways of looking at it. You could also implement one method and then change later.

[maggieo]

Hi Beth - sorry I didn't respond - I was out Friday.. Thank you for all that info - I will definitely read those artichles/best practices and see if "labeling' could work for us.. but I'm glad to know I could do what we do now at least to get going.. So - here's my urgent question of the day.. we are ready to purchase.. We have 7 developers and me- the administrator.. I use two machines to "build" on - but the same logon.. and the database lives on a server that I manage. So is one license for me good enough, bringing our total to 8? I think it's one licence per logon - but not sure if that's "at a time" or what - I am often logged in on two machines.. and as far as the database, I think we are all set.. So - hopefully 8 is good.. the 7 developers and me.. but just checking before we place our order.

Thanks for all your help - you will be stuck with me!!

[Beth]

The licensing is per specified user, so it sounds like you just need one. You can feel free to send an email to our sales department (sgstore at sourcegear.com), and they can assist with your purchase.

[maggieo]

That's what we already thought so I think we are okay.. thank you!!

[maggieo]

Hi Beth - A couple more questions! We are trying to figure out if we need the maintenance or not - it's kind of expensive as it's "per person." Do we get "support" like from you, without the Maintenance? Do we get "minor" upgrades, like from 5.1.2 to 5.1.3? Can you tell me when you went from 4.x to 5.x?

Also - in Visual Source Safe - there are a ton of little files - all those aaaa, bbb, etc files - do those exist in your product? They take FOREVER to back up at night!

Thanks much.
- Maggie

[GregM]

Since they discontinued Gold Support, the only thing that maintenance gets you is major version upgrades. We were off maintenance for 2 years because there was absolutely no benefit to it. We renewed recently because Version 6 is "coming soon". Hopefully it will come out before our maintenance expires. Version 5 came out in July 2009.

[maggieo]

Hi Greg - thanks so much for the info..

Meantime, still trying to find out if we need to buy maintenance in order to get "support" on the product. We may need some at the outset, and/or at upgrade time. Someone from SourceGear please advise.

Thanks very much.
- Maggie

[Beth]

Support is included in the cost of the product. Maintenance is only for the upgrades.

[maggieo]

Excellent! Thank you.

[Beth]

You're welcome.