trimming repository

[bwhite]

Our database is over 98 GB which makes it more time consuming to backup and restore.

We'd like to put it on a weight loss program.

We have a number of projects that check in binaries, EXEs, DLLs, etc.
We don't really need the very old versions and it seems like it could be
an easy way to recover a lot of space.

Is there any way to purge files with a certain extension before a certain date?

Thanks,
Brad.

[Beth]

There isn't a way to purge parts of history. There's only a way to purge an entire file or folder and all it's history. Unless it's absolutely needed, I wouldn't recommend it though. Let's first consider some other options.

First, is your use of your database space efficient? By that, I mean do you have a lot of duplicate data being added? Do you add builds?

Do you create a lot of branches and shares and then delete them and recreate them again?

Have you reviewed our KB article on performance to make sure you are getting the best performance you can currently? That article is here: http://support.sourcegear.com/viewtopic.php?t=4206.

Also, make sure you are performing regular SQL maintenance that is recommended by this article: http://support.sourcegear.com/viewtopic.php?t=2924

Another argument against purging, in another forum thread you mentioned possibly splitting this database up. If you end up needing to use the Export/Import tool then any purging through the use of our obliterate function could make Export/Import not work for you. Export/Import relies on historical data being present.

[bwhite]

Beth wrote:
> There isn't a way to purge parts of history. There's only a way to purge an
> entire file or folder and all it's history. Unless it's absolutely needed, I wouldn't
> recommend it though. Let's first consider some other options.
>
> First, is your use of your database space efficient? By that, I mean do you have
> a lot of duplicate data being added?
No, not a lot.
One example is that we can't share across repositories, so DLLs provided
by one team must be duplicated in the client team's repo.

> Do you add builds?
Yes, some teams do that. Those are the kinds of things that I want to
get rid of a lot of history for.

>
> Do you create a lot of branches and shares and then delete them and recreate
> them again?
No.

>
> Have you reviewed our KB article on performance to make sure you are getting
> the best performance you can currently? That article is here:
> http://support.sourcegear.com/viewtopic.php?t=4206.
>
> Also, make sure you are performing regular SQL maintenance that is recommended
> by this article: http://support.sourcegear.com/viewtopic.php?t=2924
>
> Another argument against purging, in another forum thread you mentioned
> possibly splitting this database up. If you end up needing to use the Export/Import
> tool then any purging through the use of our obliterate function could make
> Export/Import not work for you. Export/Import relies on historical data being present.
That seems broken 8: -)

Thanks,
Brad.

[Beth]

One example is that we can't share across repositories, so DLLs provided by one team must be duplicated in the client team's repo.

Those are usually not a problem.

Yes, some teams do that. Those are the kinds of things that I want to get rid of a lot of history for.

These are probably a good portion of the size. What should be done is labeling at the point one does a build and that way any build from any time can be recreated, or maybe label important builds. The KB article posted here may help as well: How to label as part of a build script

At this point you might first just delete the items, and that might help with performance without obliterate. Then have your users label what they are building instead of placing builds into Vault.

I wouldn't be able to explain adequately why this is the way it is, and I have a feature request open for a change. This doesn't help for the immediate moment though, so it's a matter of deciding what's important.

If your users want to continue store builds in Vault, I would highly recommend you make a separate repository for that and just assume you won't be exporting from that particular repository. That way you could obliterate as you felt it was needed without affecting your repositories that hold code. The user should still place labels on their code in Vault for important builds.

If you need to move forward on obliterating, then what might also help is doing any reorganizing first. For example, you could create some new repositories, export your code into those, but don't include the builds, and then just delete the entire old repository. A repository delete is just like an obliterate and doesn't affect any other repository. Initially your database would get bigger, but once you can delete repositories, it would get much, much smaller.