We usually check-out our projects through 'svn://servername/projectname/trunk' (Repo-browser).
Our current server is Windows Server 2008 Standard installed with TortoiseSVN 32bit 1.8.1 2013/07/22 version.
We have no problem in accessing our repositories from said server.
*transfer all our repositories and projects in a new server..
When trying to set-up a new server which is Windows Server 2012 R2 installed with TortoiseSVN 64bit 1.9.7 2017/08/08 version, we can't check-out our projects through svn://...
Upon trying to check repo-browser or checkout using 'svn://newservername/projectname/trunk'.. below error occur.
Checkout Failed!
Unable to connect to a repository at URL 'svn://newservername/projectname/trunk'
Can't connect to host 'newservername': No connection could be made because the target machine actively refused it.
Should we coordinate with our Network and Server incharge/s on possible required authorizations etc.? What area can we advise them to check? Or is there anything we still need to set in TortoiseSVN?
Your respond is very much appreciated.
Thanks so much.
You need to run svnserve in the background in order to use the svn: protocol. TortoiseSVN itself is just a Subversion client and only provides repository access through serverless file: protocol.
Luckily, for a few years now the TortoiseSVN installer has been bundling the official command-line tools as optional components. Double-check you've installed them in the machine that acts as server:
... and then try to figure out the exact mechanism you were using in the old machine to launch the program as background service.
Alternatively, you can migrate to a dedicated server software an maybe choose another network protocol.
Related
I have a set of machines, a mixture of Linux and Windows Boxes.
I hav set up rsync to pull from the Linux Machines to a Linux Server box.
I am trying to accomplish the same using cwRsync, to pull to the Linux box from the windows machines. I have downloaded the free version from https://www.itefix.no/i2/content/cwrsync-free-edition and also I have downloaded CopSSH. I have managed to install CopSSH fine and I am able to SSH between the Linux and Windows hosts no problem using keys rather than passwords.
However, for the life of me I can't get this cwRsync working, I've googled the matter to death, and your meant to unzip the directory, configure the environment settings in the batch file then install it. However, there is nothing to install it with! and the reason it isn't working is because it needs to install a windows service for it to run.
Any help would be much appreciated!
As described at itefix web page for the free edition, it allows to initiate rsync from your Windows machine, i.e. client functionality only (push data). Server functionality allowing you to set up an rsync server on Windows to pull data from it is not a part of the free edition.
I am trying to setup a new connection to TFS with VS2012. Early on I was able to add my TFS server and, using the Microsoft Git Provider, clone a copy of the remote repository from within Visual Studio. Later, as I was fiddling with things in Team Explorer trying to find the branch I wanted to use, something broke. My local repository remains, but my connection to the remote repository was somehow corrupted, as evidenced with this error:
TF31004: Unexpected error encountered while connecting to Team Foundation Server at http: //my.server.com:8080/tfs. Wait a few minutes and try again. If the problem persists, contact the server administrator ok help
Things I have tried to resolve this:
Wait and try again (as the error message suggested).
Restart Visual Studio.
Reboot my machine.
Reboot TFS server.
Use system restore to revert back before I installed msysgit and Microsoft Git Provider, or had attempted to connect to the TFS server.
Review the MSDN help for the error (see below).
Search Stack Overflow (found one other related issue but did not seem to apply).
Tried devenv /ResetSkipPkgs
Tried devenv /setup
Re-install Team Explorer for VS2012.
Clear IE cookies (per this post).
Clear TFS caches (per this post).
The help page offers these tidbits, but none of them seem likely given that I had, as I said, the connection working at one point:
The version of Team Foundation running on the local computer does not match the version running on the Team Foundation Server server {name}.
The server returned HTML content instead of XML content.
The required Web service on the server could not be found.
Any ideas would be appreciated!
I have had an exactly the same problem.
My solution was to clear all the credentials in the Windows Vault (Credential Manager residing in the Control Panel).
I have no idea why the credentials did get messed up.
We just installed JProfiler on a Windows box and a Linux box. The installs seemed to go fine.
We then installed the ejtlicense server on a different Linux box, and that seemed to go well also.
However, when we try to connect from the Windows or Linux box with JProfiler installed to the Linux license server, we get an error message saying that there was an error communicating with the license server.
Both systems can ping the hostname and the IP address of the license server. I have checked the license server using the admin tool, and everything seems to be working correctly on the license server itself.
Is there a requirement to explicitly set up the port number, or will the default ports work correctly?
Thanks very much for any assistance anyone can provide.
In many cases, this is a firewall issue. On the license server, port 11862 has to be allowed for incoming connections.
am trying to evaluate ccnet, I have gone through a number of tutorials/blogs which describe in detail on how to install ccnet. However most of them assume that CruiseControl.NET is being installed on the same machine on which Subversion repository is or it is a server machine.
I would like to know if ccnet can be installed on a non server machine and pre - configured subversion?
Sure this is not a requirement to install CCNet on a Server nor on the same machine as your repository.
CCNet can run as console application or windows service and both can run on windows, windows server and linux/mac with Mono.
Thus CCNet uses the native applications for source control operations (e.g. svn.exe or git.exe) it also supports the same remote repository features as its source control application. So your Subversion repository can be located everywhere your CCNet machine has access to.
I recommend you to read the Scenarios Section in our wiki.
I would never install my CC.NET on the same machine as my SVN repository. But that is me.
For local testing, you can run the command line version, and not the service. It's helpful, because the Console output actually let's you pick up on a few things while it is running. (Nothing you can't find with the service, but its cool to see it "in progress").
When you do install CC.NET, I would install it on a "clean" machine. The way I like to use CC.NET is to think of it as a "big fancy msbuild wrapper".
Your CC.NET will pull code from the repository, and I like to pull the .msbuild defintion file from svn as well (meaning, you store it there), and then have cc.net use the "msbuild.exe" task. The less custom cc.net tasks you use, the better. If you put 99% of your build logic into a .msbuild file, you'll won't screw yourself if you ever leave CC.NET for TFS.
3.
Yes, it has to be able to "talk to" SVN under some Identity. This identity needs read (maybe write) rights back to SVN. But it is the identity (account) that pulls the code from SVN. If your source code is projected (most likely it will be), then you may have to do some command calls using svn.exe to "accept the (p)ermanent certificate, using the IDENTITY that runs the CC.NET service.
You'll probably have some dependencies you'll need to install. I would NOT install Visual Studio 200x or 20xx. Download and install SDK's and other things as needed. Keep the build machine "clean". Document what you install.
It is a good practices to have CC.NET running in the same environment as developer(s).
So having a standard Win7x64 OS for CC.NET is nice to reflect the dev environment.
CC.NET can be configured to access a remote or local Subversion repository depending on the svn configuration you setup.
So the answer is : yes !
Our team is going to be developing against SharePoint using local VMs. Our VMs are not allowed to join the host domain. Additionally our host nics are prohibited from using Internet Connection Sharing. We have a requirement to source control all our development work using Team Foundation Server. Our TFS installation is using Kerebos for authentication.
To be able to use TFS for source control we were thinking we could share a folder between the host and VM, do our work on the VM, save to the shared folder and then do check ins and such from the host which will be able to authenticate against TFS.
I'm hoping there is a cleaner way to do this or someone with similar restrictions can provide some insight.
Note: I have successfully setup a similar mechanism using Tortoise SVN and Ankh SVN that works, but management will not budge on the TFS requirement. Not that I blame them either, the license is very expensive and they want to feel they are getting their money's worth. Therefore TFS has to be included in the answer.
Here's a solution that works perfectly for SharePoint 2007 development.
We run virtualised instances of Windows Server 2008 on our Windows XP machines at the project i'm on. We use Sun VirtualBox as the virtualisation software.
secondly, each VM is a standalone domain controller + sql server + reporting server + analysis server + sharepoint server and as such isn't joined to the main domain.
when opening up Visual Studio 2008 and connecting to TFS you don't need the machine/server to be connected to the domain as the VM NATs through the host machines network adapters - use a fully qualified address for your TFS and you shouldn't have any problems connecting to TFS from within the VM.
you may need to turn off integrated windows authentication (IE -> Tools -> Internet Options -> Advanced)...
We also run VS08 in the VM and not on the host..
Another thing is to use WSPBuilder to build your solutions and create the deployment scripts for you (or alternatively just set up an external tool/command from VS08 that runs the stsadm.exe -o deploysolution command)..you can deploy effortlessly to the VM and ensure that it runs fine - then just check in your code, set up build scripts that fires off WSPBuilder on the build server to build the solutions for you and deploy from there (or copy the WSP up to the server and run them there).
I think your solutions is as clean as it will get.. you could map a folder on your host machine and open the Visual Studio project straight from there within the VM. Saves copying. Committing will have to be from the host. Use of TFS features will be a bit awkward, you'll have to open VS on your host machine as well to connect commits to work items etc. Not exactly what the investment in TFS was for.
How come they've dished out the cash for TFS but are not willing to facilitate it? The VM's should really be in the domain.. or at least a trusted domain.
We run the same setup except we do have SVN and can commit directly from the VM. Workable :)
BTW, if you develop for SharePoint 2010 this gets better; it'll allow installation on non-server OS's so you can develop on your local machine (which I guess, is on the domain).
I generally use VS2008 running on the host with the SharePoint assemblies installed to the GAC of the host. I use build events/build targets with a shared folder and sysinternals to build directly to the SharePoint VM's bin/GAC folders. This way Visual Studio builds directly to the SharePoint server and you do not have to manage 2 installations (host and VM). I would also recommend installing VS2008 debugger as a service on the VM for easy debugging.
Hope this helps!