visualsvn-server

Is there a way to migrate SourceSafe with HISTORY into a SVN ? Ideally I'd like to use VisualSVN Server, but I don't really want to lose my SourceSafe history. If I have to I will though. M4N A long time ago (it seems) I tried to migrate a SourceSafe DB to subversion using vss2svn , but finally gave up. There were several problems, IIRC: you have to make sure that the SS DB is consistent (e.g. Analyze does not find any problems or is able to fix them). it took a very long time to migrate the DB, because it was quite big. finally the migration failed due to some problems with parsing dates. I

So this error seems to occur when I attempt to add a new repository location in Eclipse. However, I am sure that the URL and authentication info (username and password) are valid. The error looks like this, and it occurs when I use https://localhost/svn/TestSVN as the URL. I understand I replaced the name of my PC with localhost but the same error occurs when I use the name of my PC instead. When I installed TortoiseSVN and VisualSVN-Server, I didn't do any custom installations so for the most part, the installations relied on default settings. I also used all the default settings when

I'm using Visual SVN Server and Tortoise SVN (client) for source control. I would like all developers to standardize on a consistent format for checkin notes. For Example I want their Commit Message to default to... Synopsis: Developer Name: (pre-populated) Reviewed By: [Bug Id]: [Change Bug State]: Known Issues: Affected Files: (pre-populated) In the future I'd like [Bug Id] and [Bug State] to supply the information to trigger an automated update to the Bug Tracking system. Also Developer Name and Affected Files should be prepopulated with the svn user and files that the user is commiting.

We were having a problem with our build server not checking out modifications from source control despite recognizing that there had been changes. It was traced to the control folder (not sure what it's real name is), the existing working builds were using _svn. Clearing the working folder forced a new complete checkout and I noticed that now the control folder is .svn. It looks like originally our integration routines were checking out code using _svn but now it is using .svn. The svn.exe being used during integration is from VisualSVN Server can I set this up to use _svn again? How the

Recently I am facing problem of commit to SVN. The SVN server I am using is VisualSVN Server 2.5.9 and the client is TortoiseSVN 1.7.12. At first, one user is having problem to commit files to SVN. But that user still can access to the repository and download the update. The second user on second PC is working properly. But today, the second user is having the same problem as the first user. Why is this happen? How can the problem be solved? Thanks. You can get the "Forbidden" error if your user account lacks access permissions to a repository or repository path; it makes sense to check

I would like to upgrade my TortoiseSVN installation to version 1.7. We have a VisualSVN server running with a SVN 1.6 repository. Do I need to upgrade the repository to 1.7 before I can update my client, or is TortoiseSVN backwards compatible? I know that during the upgrade from TortoiseSVN 1.6 to 1.7, I need to convert my working copy to the new format, but during a commit does it have some logic to see the server version and adapt appropriately? In the release notes Older clients and servers interoperate transparently with 1.7 servers and clients ... Subversion 1.7 servers use the same