Moving projects/folders between repositories in 3.0

jfaulken · Post by **jfaulken** » Fri Dec 17, 2004 4:43 pm

I have a need for this feature, and I've seen it show up over and over again in the forums. It's been acknowledged in most of the responses from SG people as one of the most requested features of all time.... drumroll.... is the feature in 3.0?

Post by **jclausius** » Sat Dec 18, 2004 12:01 am

Sorry, it is not.

The code to do this will be quite complex ( storing histories, branches, deleted items, file versions - all in just one single file ), and is currently scheduled for Vault 4.0.

Guest · Post by **Guest** » Wed Dec 29, 2004 2:53 pm

Can you post detailed information about the database schema?

Without checking my license agreement, if I write a stored procedure can I release it?

- John

jfaulken · Post by **jfaulken** » Wed Dec 29, 2004 3:37 pm

Sorry, that last post was me... forgot to log in.

In all seriousness, this is very frustrating. We're having SIGNIFICANT performance problems as our database has grown. It seemed to be a no-brainer to create a new repository and move everything to it that wasn't active. I can't afford to lose history, but I also can't afford to have my users waiting longer and longer for gets. We store many large binaries because of the type of work that we do.

Looking in the database I see that the stored procedures are encrypted. I am now regretting moving our company's lifeblood to a proprietary, locked system. I am researching open source replacements for Vault, and I plan to pay for no additional licenses or upgrades. I admit that the open source equivalents don't have the polish or fit-and-finish that Vault does, but that's not what's most important for a tool that's central and core to all work that we do.

Note to Erik: I've followed your blog for a while, and I have a great deal of respect for your approach to software development and business. Talk me out of leaving.

- John

dan · Post by **dan** » Wed Dec 29, 2004 3:51 pm

John,

We are a little short-handed because of the holidays, so it may be next week before we can fully address your concerns.

Some questions though:

1. Are you running 3.0?
2. How many folders/files are in your repository? If performance is the issue, there may be other ways than needing to move files out to help it along.
3. What are the exact performance problems you are seeing? Is it on refreshes, Gets, initial startup, etc?

jfaulken · Post by **jfaulken** » Wed Dec 29, 2004 3:58 pm

Dan -

Thanks for the reply.

1. No, we're on 2.0.6.

2. We're at around 1000 folders and 15,000 files.

3. The most obvious slowdown is in UI refreshes in the windows client, but a check-in or a get are both much slower than they used to be.

We just move Vault over to a new computer, a dual CPU heavy-iron system, and that helped some with performance... but not as much as I'd hoped. If there are any easy things to do that would help with the performance issues, I'm more than willing to try them out. I do know my way around a database, so I'm not afraid to poke tables/views/sprocs with a stick.

- John

dan · Post by **dan** » Wed Dec 29, 2004 4:12 pm

The database questions will have to wait till next week, but really, 15,000 files is not all that many, so we should hopefully be able to figure out why it is slow.

Some things to try until then:

1. If you have a lot of users, you might think about upgrading to 3.0, because we improved concurrency quite a bit in 3.0.

2. Do all users/machines have about the same performance? One thing to try is to simply unset the working folders for old folders that you are no longer using, and then cloak them. The client will then no longer scan those working folders for changes, and no longer get files from the cloaked folders, so should help.

jfaulken · Post by **jfaulken** » Wed Dec 29, 2004 4:20 pm

Dan -

No worries about being short-staffed.

I've turned on folder security, hoping that disallowing access to projects would make the client ignore them. Does that make sense?

I'll have one of my developers unset working folders and cloak.

- John

dan · Post by **dan** » Wed Dec 29, 2004 4:31 pm

Unfortunately, security will make things slower rather than faster, even if users are denied access to parts of the tree. This is because the server needs to compute access rights, which slows things down a bit. Good thought, but not how Vault is designed

Another question: Do you have a lot of repositories stored on the same server? This shouldn't make a difference, but any data points are good.

jfaulken · Post by **jfaulken** » Wed Dec 29, 2004 4:38 pm

AHA. Well, that makes a lot of sense. Oops.

I only have one repository on the server. Well, aside from the one named "Archived Projects" that I just created last week and is still empty.

- John

lbauer · Post by **lbauer** » Wed Dec 29, 2004 4:45 pm

As Dan said, we will have some more detailed database optimization tips next week, but in the meantime, here are suggestions for basic Vault database maintenance:

Every day:

1- backup the transaction log

Every week:

1- Backup the entire database
2- UPDATE STATISTICS on all vault table indices

Every month:

1 - Check file structure consistency - DBCC CHECKALLOC
2 - Defrag the indices of all tables - DBCC INDEXDEFRAG

Every six months:

1 - Shrink the database DBCC SHRINKDB
2 - Rebuild all indices of all tables - DBCC DBREINDEX

Don Thimsen · Post by **Don Thimsen** » Thu Jan 20, 2005 9:11 am

Linda,

Was there ever a more detailed document written for "database maintenance and optimization"? The only SQL experience we have at our shop is with Vault, so it's all foreign territory. So, we've pretty much shied away from doing ANY maintenance other than backups. A howto guide would be appreciated from our end.

Also, I noticed a recommendation from a post about performance problems to use the SQL wizard to setup a scheduled maintenance job. Sounds like something good to learn about as well.

Thanks from a very happy vault camper,
Don

lbauer · Post by **lbauer** » Thu Jan 20, 2005 10:28 am

Not yet, I'll bump it up a notch in our todo's list.