Is it possible to move a repository from one server...

If you are having a problem using Fortress, post a message here.

Moderator: SourceGear

dist0rti0n
Posts: 112
Joined: Mon May 01, 2006 10:50 pm
Location: Birmingham, AL

Is it possible to move a repository from one server...

Post by dist0rti0n » Wed Nov 07, 2007 11:06 pm

... to another?

Say I have 2 established instances of Fortress and I want take a repository from one server to the next, is that possible?

Beth
Posts: 8550
Joined: Wed Jun 21, 2006 8:24 pm
Location: SourceGear
Contact:

Post by Beth » Thu Nov 08, 2007 8:30 am

Yes. You would use the Export/Import tool that installs with it. Just export it out to a file, then import that file to where you want it on the other machine.

dist0rti0n
Posts: 112
Joined: Mon May 01, 2006 10:50 pm
Location: Birmingham, AL

Post by dist0rti0n » Sat Nov 10, 2007 12:45 am

Thanks! That sounds like it would do the trick but I'm getting an error when I try to import:

---------------------------
Import Error
---------------------------
An error occurred while importing a transaction for (TxID: 18 on 6/27/2007 8:46 PM by admin [1]) . The import cannot continue.
---------------------------
OK
---------------------------


Any clue what that might mean?

Beth
Posts: 8550
Joined: Wed Jun 21, 2006 8:24 pm
Location: SourceGear
Contact:

Post by Beth » Mon Nov 12, 2007 5:12 pm

Can you check both your export/import log (C:\Program Files\SourceGear\Fortress Client\VaultFolderExportImport.txt) and your Vault Server Log for errors. If you wish, you can either post them here as well or send them to support at sourcegear.com (attn: Beth) with a link to this forum thread.

dist0rti0n
Posts: 112
Joined: Mon May 01, 2006 10:50 pm
Location: Birmingham, AL

Post by dist0rti0n » Mon Nov 12, 2007 8:53 pm

Ok so I checked out the log file and it gave me a clue: it had failed why trying to process and stated "checkin comment required."

I thought back to through the history of the repository and this option was enabled at some point, although not a the very beginning but had been enabled from the start on the new repository I was attempting to import to.

So i disabled it and ran the import again. No dice.

I blew away the repository, created a new one with the same name and ran in the import again.

Success!....almost. This program is such a tease! This time it made it through nearly 500 of 600 transactions before failing.

I've sent you the log in a separate email.

Thanks!

Zack

dist0rti0n
Posts: 112
Joined: Mon May 01, 2006 10:50 pm
Location: Birmingham, AL

Post by dist0rti0n » Mon Nov 12, 2007 9:07 pm

One more question:

If the import succeeds, does it bring across the work items as well? On the old repository we always checked in against a bug and it would be nice to have that history as well.

Beth
Posts: 8550
Joined: Wed Jun 21, 2006 8:24 pm
Location: SourceGear
Contact:

Post by Beth » Tue Nov 13, 2007 5:32 pm

The work items aren't part of a repository at all. They are in a different type of container that is called a Project. They will be where they always have been.

Also, the links in the Project that point back to the files modified will point to the repository location where the check-in occurred.

dist0rti0n
Posts: 112
Joined: Mon May 01, 2006 10:50 pm
Location: Birmingham, AL

Post by dist0rti0n » Wed Nov 14, 2007 8:16 pm

Beth wrote:The work items aren't part of a repository at all. They are in a different type of container that is called a Project. They will be where they always have been.

Also, the links in the Project that point back to the files modified will point to the repository location where the check-in occurred.
Sounds like "no" to me. I guess that makes sense given the history of the product. Perhaps in the future when dragnet and vault are tied more closely together into what we now know as Fortress we can expect that they will function more as a single unit.

I think it makes sense that if the product presents a common interface and allows you to relate projects to change sets that there should be some support for retaining that relationship when you ship a repository from one server to another.

Would it be possible to get this on the list of things to address in a future version?
Last edited by dist0rti0n on Wed Dec 05, 2007 9:48 pm, edited 1 time in total.

Beth
Posts: 8550
Joined: Wed Jun 21, 2006 8:24 pm
Location: SourceGear
Contact:

Post by Beth » Thu Nov 15, 2007 11:20 am

I just had another user request the same thing a couple of days ago, so I will add your "vote." :-)

Maintaining that link will be a bit harder in an export/import situation, versus a move inside a repository, but I made note of that part.

dist0rti0n
Posts: 112
Joined: Mon May 01, 2006 10:50 pm
Location: Birmingham, AL

Post by dist0rti0n » Fri Nov 16, 2007 8:12 am

Thanks, Beth!

Beth
Posts: 8550
Joined: Wed Jun 21, 2006 8:24 pm
Location: SourceGear
Contact:

Post by Beth » Fri Nov 16, 2007 11:07 am

Back to the original issue of the export, it turns out there is a bug on our end with changesets that have a rename or delete in them at the same time as other functions. A fix is being worked on for this.

ccalcutt
Posts: 4
Joined: Wed Jan 02, 2008 1:20 pm

Can't get export to work with version 4.0.6

Post by ccalcutt » Mon Jan 07, 2008 1:51 pm

I am exporting a folder that contains a single file. Viewing detailed, recursive history on this folder shows 5 changes. Among them is the addition and subsequent deletion of a second file.

When I start an export...
- Shows it must retrieve 178 transactions. Where are all these coming from?
- Moves verrry slowly. Takes 2 hours to "retrieve" 149 of 178 at which point...
- It fails saying, "A database error has occured (FailDBReader). It asks me if I want to continue export. If I answer yes it says, "The folder's trasaction information for indirect folders was not retreived from the Vault server. The export cannot continue. An exception was encountered retrieving the Indirect Folder Transaction information."

Here is an excerpt from the error log:
----1/7/2008 11:09:14 AM ccalcutt--servername.ilsmart.com(xxx.xxx.xxx.xxx)--SSL Disabled System.Data.SqlClient.SqlException: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)
at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)
at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
at System.Data.SqlClient.SqlDataReader.ConsumeMetaData()
at System.Data.SqlClient.SqlDataReader.get_MetaData()
at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString)
at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method)
at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior, String method)
at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior)
at VaultServiceSQL.VaultSqlSCC.GetIndirectFoldersTxIDs(VaultSqlConn conn, Int32 nRepID, Int64 nCeilingTxID, String strXml, VaultFolderExportTxInfos& vfeTxInfos, VaultNameValueCollection& nvcBranchObjIDsTxIDs) at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)
at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)
at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
at System.Data.SqlClient.SqlDataReader.ConsumeMetaData()
at System.Data.SqlClient.SqlDataReader.get_MetaData()
at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString)
at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method)
at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior, String method)
at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior)
at VaultServiceSQL.VaultSqlSCC.GetIndirectFoldersTxIDs(VaultSqlConn conn, Int32 nRepID, Int64 nCeilingTxID, String strXml, VaultFolderExportTxInfos& vfeTxInfos, VaultNameValueCollection& nvcBranchObjIDsTxIDs)
----1/7/2008 11:09:14 AM ccalcutt--servername.ilsmart.com(xxx.xxx.xxx.xxx)--SSL Disabled GetInfoForFolderExport returned: FailDBReader

Beth
Posts: 8550
Joined: Wed Jun 21, 2006 8:24 pm
Location: SourceGear
Contact:

Post by Beth » Mon Jan 07, 2008 1:55 pm

ccalcutt:
The transactions are how many changes have occurred in that folder. An export pulls the entire history.

The error that you are seeing is a SQL timeout. You can end that error by going to your Vault.config file and finding the SQL timeout setting. It's set to 360 by default. Add another '0' after that to make it 3600, and then try again. If it fails again, then check your server log again, and you most likely will have a different error the.,

ccalcutt
Posts: 4
Joined: Wed Jan 02, 2008 1:20 pm

But detailed history on the folder shows only 5 transactions

Post by ccalcutt » Mon Jan 07, 2008 4:28 pm

The transactions are how many changes have occurred in that folder. An export pulls the entire history.

I get that the db is timing out. The question is why?
I am exporting a folder that contains a single file. Viewing detailed, recursive history on this folder shows 5 changes.

When I start an export...
- Shows it must retrieve 178 transactions. Where are all these coming from?
- Moves verrry slowly. Takes 2 hours to "retrieve" 149 of 178

What is taking so long? Why is it timing out?

Beth
Posts: 8550
Joined: Wed Jun 21, 2006 8:24 pm
Location: SourceGear
Contact:

Post by Beth » Mon Jan 07, 2008 5:22 pm

Is it possible that there were obliterates done on this folder that you are exporting?

It might be good if I can see it. Could you send an email to support at sourcegear.com (attn: Beth) with a link to this thread?

Post Reply