I have a strange SVN server configuration issue I cannot figure out.
A previous employee setup Collabnet svn server (version 1.6.9) on a windows server at work which we use for development. It's a great system, love using it.
We use a local LAN path for the repository with all our various folders, like this...
"svn://server1"
It has one repository called "repo".
I have recently installed a second SVN on another server (same version, same OS)
It has one repository called "main". In order to access it I have to use the svn path of ...
"svn://server2/main"
So the question is.... does anyone know how we ended up with one server requiring to use a "repo name" after the server name (and does not work without it) and one server not requiring a "repo name" (and does not work with it)?
The main reason for asking is I also need to setup additional repositories on the original server and do not want to affect the current configuration. I assume this is some level or option or configuration or a "default repo" setting or something, but I just can't seem to find where and how it was set.
Check the entry in your conf file. If you have your svn information within a location tag, the location is the only way to access the repository.
Related
I have 2 separate Teamcity web application instances running on separate servers accessing the same git repository.
This seems to be causing issues with the VCS root configuration.
The specific error message is:
Error collecting changes for VCS repository ... 'git fetch' command failed... 301 Moved permanently
I get this message for every build configuration with every teamcity project in my installation.
I must maintain 2 separate teamcity application instances on different servers - one that builds Microsoft Windows software artifacts and the other that build Linux based artifacts.
The only workaround that I currently have for this problem is to delete the VCS root and set it up again - only to discover that the next day the problem is back.
I can't keep doing this forever - there must be a better way to address this.
Does anyone know how?
After working with Jetbrains support, they root caused the issue to the use of http:// in the github URL instead of https://.
So, IOW, when you specify a github repository URL, you must use https:// in a temmcity VCS root configuration.
I'm the only developer in a team and will be working on a private project that doesn't need to be placed on the Github or somewhere else online. My entire project will be located in one of my local machine folders. Is this possible to create a project in TeamCity that points to my local folder? I'm using TC version 10. When I navigate to Create Project i only see Manually, Github, URL Repository and BitBucket Cloud Repository. Logically thinking I went to set up the project Manually, but there is a field Project ID which seems like require some sort of URL. Just curious if this ever possible with Team City? Thanks.
Yes, it is possible.
Choose git as a type of repository and in mandatory field Fetch URL specify local path: /path/to/repository.
Click Test connection to make sure Teamcity is able to fetch data.
You won't be able to configure triggers against this repository, it is still open issue: https://youtrack.jetbrains.com/issue/TW-12162
See screenshot .
with TC 2017.2.2 from URL Repository you can just give the path
file:///home/user/dirOfProject
Say I've got an upstream repo (origin) that was added with
git remote add origin file:////upstream.host/repo.git
The repo.git is acually a windows shared folder where I and my dev colleagues have r/w access assigned.
Now, I want to set up a post-receive hook on upstream.host that notifies Trac about freshly pushed revisions for automatic ticket updating. Basically, this is done by calling an executable on upstream.host that does some work in the database there.
However, I notified that the hook for some reason doesn't work.
So I've set up the hook to print everything she's doing to D:/temp/post-receive.log and issued a git push in order to trigger the hook.
When I looked into D:/temp on upstream.host, there was no logfile created.
Then, another question of me came into mind: https://superuser.com/questions/974337/when-i-run-a-git-hook-in-a-repo-on-a-network-share-which-binaries-are-used.
When actually the binaries of my machine are used for executing the hook, maybe also the paths of my machine are used. I looked into D:/temp and voilá, here we have the post-receive.log.
I traced the pwd to the logfile and it is not D:/repos/repo.git (what I expected) but actually is //upstream.host/repo.git. Obviously the whole hook is executed in the context of the pusher's machine and not in the context of the repo machine (upstream.host).
This is no problem for me since I have admin access to the remote machine and could use administrative shares in order to get my hook going (i.e. \\upstream.host\D$\repos\repo.git etc). But this is an issue for my colleagues since they are plain users and no roots.
How do I set up my post-receive hook properly so that it works as expected?
How do I force my hook to be entirely run on the remote machine without using anything from my machine?
Do I really have to implement a real server hosting my repo? Or are there other ways that don't need a server?
a post-receive hook is run after receiving data on the machine that is hosting the repository.
now the machine that is "hosting the repository" is not the file-server where the actual packed-refs and other git database files are stored. (this file-server could be anything from a redundant cloud-based storage appliance to any old NAS-enabled "network disk").
Instead it is the machine that runs the "git frontend" (that is, the git commands that actually interact with the database).
Now you are using a "network share" to host your (remote) git repository. For your computer (the client), this is just another disk device (like your floppy) and the git on your client will happily store database-files there, and run any hooks. But this is your computer, since it is being told to run the remote locally - simply because the file:// protocol does mean "local".
Btw, the fact that your remote is named upstream.host is meaningless: this name is only there for you to keep track of multiple remotes, but it could be called thursday.next instead.
So there is no way to run any script on the file-server that happens to store some files names pack-refs and similar.
If you want to have a git server to run hooks for you, you must have a git server first. Even worse: if you want a git server on machineX to run scripts on machineX, you must install a git server on machineX first.
The good news: there is no need to "implement a real server". Just install a pre-existing one. You will find docuementation about that in the Git Book, but for starters it's basically enough to have git (for interaction with the database) and sshd (for secure communication via the network; and for calling git when appropriate) installed.
Finally: i'm actually quite glad that you need to have software (e.g. a server) running on the remote end to execute code there. Just imagine what it would mean if copying some html files to your USB disk would suddenly spawn a web server out of thin air. Not to think of w32-virusses breeding happily on my linux NAS...
Is it possible to specify a remote settings.xml file for maven to use?
So it could be convenient to update one settings.xml file in some remote location (server), and the rest of the dev team wouldn't have to download it manualy.
Quite likely you could do this using tricks outside maven itself, such as symlinking or, as mentioned before me, sharing them through a repository.
But you probably should not. The settings.xml file is used for local settings - specific to your machine. You use this for example to specify the location of your local application server or a local database connection, etc. You would have to force every user to use the same file system layout and server setup, which probably requires more hassle than a shared settings.xml would save.
The proper way to share settings across a project is to include them in the project's pom. If you want to share across a team or organisation regardless of project, you can use a parent pom, or even several layers of them.
Simple answer no, cause the settings.xml defines the configuration to access remote resources furthermore it could contain passwords/keys etc. which would not make sense to store remotely.
You can create a git repository which contains ${HOME}/.m2/ included the settings.xml as a template so the onboarding is simpler.
I'm trying to setup Mercurial on developer workstations so that they can pull from each other.
I don't want to push.
I know each workstation needs to run
hg serve
The format of the pull command is
hg pull ssh:[SOURCE]
What I'm having problem with is defining SOURCE, and any other permission issues.
I would believe that SOURCE ends with the name of the repository being pulled from. What I don't know is form the host name. Can I use IPs instead?
What permission issues do I need to look out for?
SOURCE == //<hostname>/<repository>
All developers or test stations are running Windows 7 or Windows XP.
I have searched for this answer and have come up empty. I did look at all the questions suggested by SO as I typed this question.
This is probably a simple Windows concept, but I'm not an expert in simple Windows concepts. :)
The hg help urls output has these examples:
Valid URLs are of the form:
local/filesystem/path[#revision]
file://local/filesystem/path[#revision]
http://[user[:pass]#]host[:port]/[path][#revision]
https://[user[:pass]#]host[:port]/[path][#revision]
ssh://[user#]host[:port]/[path][#revision]
and a lot of info about what can be used for each component (host can be anything that your dns resolver resolves or a ipv4 or ipv6 address. I beleive on windows systems UNC paths count.
Also, you appear to have some confusion about when you can use ssh. You can use ssh:// URLs to access repositories on the file systems of systems that are running ssh servers. If they're running hg serve then you can access them using the http:// URL that hg serve gives you when you start it. It's usually used for quick "here grab this from me and see if you can tell me what I'm doing wrong" situations rather than for all-the-time sharing.