Contact us

All times are UTC - 8 hours

   [ 6 posts ] 
Author Message

Joined: Fri Sep 12, 2008 4:33 am
Posts: 3
There are 2 cases we need to use export functionality:
1. When we want to make some cleaning and want to keep only some parts (latest) in a new repository just to keep is simple.
2. When we want to clean some very old history that is not meaningful at the moment anyway but still good to keep some very latest history - for example last year history.


Joined: Tue Mar 08, 2005 12:23 am
Posts: 1315
Currently, we do not have the Export feature.

To achieve your goal, you can periodically:

1.Backup your whole database to a new location;
2.Get all the files from the repositories;
3.Create a new empty database;
4.Add all the files into the database.

This way, you can work on the clean/latest repository and if you need any old history, you can turn to your backup copy.

Will that work for you?



Joined: Fri Sep 12, 2008 4:33 am
Posts: 3
For sure this will not work because at the moment we realize something old is not needed anymore it will be already late to do this. I am speaking about the case where we work 5 years on a project and decide to remove all history except the versions for the last 2 years.

It doesn't make much sense to be able to maintain many repositories without the ability to be able to move projects between them. We were badly surprised that something that VSS has for over a decade here is not supplied as functionality even having in mind that in the sql database this would be much easier operation.


Joined: Tue Mar 08, 2005 12:23 am
Posts: 1315
Hi apetkov,

Since we are using SQL as the back end, technically speaking, there is almost no need to truncate the history.

May I know why you want to truncate the history? Maybe performance and storage space are the concerns.

The performance of SourceAnywhere will not degrade even you have very large repository with years of history. We tested SourceAnywhere on 10 million lines of history record and the system worked almost like a new repository. SourceAnywhere Standalone has very advanced cache mechanism on the server side. Everything retrieved once from SQL Server will not be retrieved again. For example, you can do a test by yourself. You can do a Get Latest option first and then do it again. For the first option, commands are sent to SQL Server. But for the next one, there will be no commands sent to SQL Server and the server work load will be extremely low.

Our SourceAnywhere Hosted server, which uses the same technology as SourceAnywhere Standalone, handles 3000+ developers daily on almost 100G repositories and works very smoothly.

For the storage issue, SourceAnywhere Standalone uses Delta for both text and binary files. Also all data are compressed by default. The total repository size is much smaller than VSS database. During the past years, the price of the storage devices has dropped significantly. Hopefully, this is not an issue for you.

For the backup, you can combine the full backup and incremental backup together to reduce the backup time and space.

So basically, our suggestion is that you just keep all the histories without doing any extra work.

Please let us know your concern and consideration so we can help you.

Best regards.


Joined: Fri Sep 12, 2008 4:33 am
Posts: 3
Hi Catherine,

The reasons to ask for this are neither performance, nor the storage. We are just starting to use SAW Standalone and we can't say anything about the performance. But I am sure the peformance of operations like File History or Project History will be much different if we have less data.

The reason is mainly because we prefer from time to time to take out some history because we don't need it. For 2-3 years the project evolves to the position where the very old sources are just useless. It is for us - we don't want to see them anymore. If a file was changed 3 times for the last 2 years we want to see 3 versions in history, not the 100 more in the past.

According to Repositories - it would have been nice to be able to make a new version of the Repository and keep the old one as read only. We were able to do this in VSS. It was easy there even to just copy all the files to another place and keep old version but work on the new one and see both of them together - which here is impossible. Sometimes for example we may need to delete lots of files - we would prefer to keep old versions backup as they were. You can say we can make branches in the same Repository - yes, we can but how many times? Instead of having in root Ver32, Ver33, ... Ver 55 isn't it better to have less versions in this Repository but have the old projects in another Repository? I know they both work in the same SQL Database and this will not bring any performance improvement. What I am claiming is comfort for the developers - the users of this system.

Here is a small graphical explanation of the difference between the 2 ways:
Your way - keep everything

The way I think all big software projects work:
(underscore was supposed to be spaces but when posted they are ignored)

I believe export/import functionality similar to what VSS has would be useful to have and it will add another big benefit to your otherwise really great product.



Joined: Tue Mar 08, 2005 12:23 am
Posts: 1315
Hi apetkov,

You are right that if there are less data the performance of File History and Project History is faster. But the point is that several seconds of performance degrade should not affect the usability.

The beauty of a version control system is that go back to any moment of the history and get file files at that moment out. Truncating part of the history can cause problems in the system. The previous tree may be incomplete and a label may be broken. SourceAnywhere Standalone has very advanced label features. You can add/deleted the label members and change the version number of an existing label item.

Can you be more specific about “We were able to do this in VSS. It was easy there even to just copy all the files to another place and keep old version but work on the new one and see both of them together - which here is impossible.”? In SourceAnywhere Standalone, you make the existing repository read only, create a new repository and add the current files into the new repository.

How SourceAnywhere Standalone implements repository is different from what you think. In SourceAnywhere Standalone, each repository has an independent set of tables. The data in different repositories virtually have no effect on the performance on each other.


Display posts from previous:  Sort by  
   [ 6 posts ] 

Who is online

Users browsing this forum: No registered users and 0 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Copyright © 2016 Dynamsoft | All Rights Reserved
dynamic designed by Dynamsoft team
Fatal: Not able to open ./cache/data_global.php