How to avoid physical path in bzr+ssh://myserver/C:\mydir? - windows

I am starting with Bazaar (switching from Subversion, sorry if terminology is a bit off sometimes). Using Bazaar locally no problems.
Got bzr+ssh:// working on my Windows server (finally! and even ssh agent is working wow!)
Now I want a shared repository on the server from which the developers can branch to their machines. I want the repository in a specific folder, for example in C:\bzr\MyProject.
When I do:
bzr init-repo --no-trees bzr+ssh://myserver.com/MyProject
it creates the repository in C:\cygwin\home\user\MyProject in the home directory of my user account - it is understandable, but worrying.
Then as an experiment I also tried and succeeded:
bzr init-repo --no-trees bzr+ssh://myserver.com/C:\bzr\MyProject
This created the repository where I wanted. But how do I "map" or "alias" the URL (or bzr) so my developers can logon under their accounts and use URL
bzr+ssh://myserver.com/MyProject
to access the shared repository in C:\bzr\MyProject?
Obviously I don't want developers to use bzr+ssh://myserver.com/C:\bzr\MyProject because of the physical path in the URL.

Ok my own answer is if you want to run Bazaar on a Windows server for a development team who will access it over the internet,
and you are not familiar with Linux, Cygwin, SSHD and related stuff then it might turn out more complicated than you can bear.
I actually abandoned the Bazaar idea and gone with Mercurial. I must say Mercurial install on the server is also steep, but at least it is just Windows, IIS and only a bit of Python. Got it running in half a day.
Some of the problems that I had with bzr+ssh:// on a Windows server are:
Needs SSHD installed on the server. SSHD (from stripped down Cygwin) supplied with Bazaar refused to work. Had to install Cygwin and learn a bit of Linux stuff, how to run as a service, how to configure, how to generate keys.
Hard to add a new user in a way that does not request passwords typing for each command. Will need to generate a keypair, mock with copying the keys to th server in two locations (Cygwin's home user folder and Window's too). Probably need to log on the user to Windows to create a profile. Don't want developers logging on to the server actually.
Hard to set up a shared repository in a specific location on the server. Does not seem possible with bzr+ssh. Possible with sftp. Might need to use symlinks as bialix suggested above.
As a newbie to linux stuff I don't understand all implications of running sshd on the server and giving shell access to the developer accounts. Have to use bzr shell limited... documentation is scarce.
Basically, bzr+ssh:// on a Windows server seems to be what installing Subversion on a Windows server was like several years ago - hard. Hopefully it will get better with Bazaar too because I chose it over Mercurial initially.

Related

Configure Git Remote server with Putty For Windows Pc

right now i'm working on my school's development department.
Lately we've gotten a Ubuntu Server, I mean, the school has given us the server with Ubuntu OS.
The last week my boss said that he wanted to use Git on the server, but all our machines have Windows OS.
I've been searching a lot of information about doing this but i noticed that the information is mostly too old and obsolete.
I don't really know the exactly way to to this, i mean, i know that i need to update the server (sudo apt-get update), then install Git and assign the global user email and name, after that, get the ssh keygen but is in this point where i don't know what to do, because in some of the web tutorials they use their machines whit different OS.
Is there any proven new way to solve this problem? ->Configure with windows the private Git server and then use it with windows machines?
If you mean setup a Git server on Windows, no need for putty.
Install:
Git for Windows
Gitea.io (very simple setup: just one exe to copy, that's it)
And you have a Git server on Windows!

How to run Git server on Windows?

How can I share a Git repo on Windows? The "correct" ways appear to be to run "git-daemon" (unix specific) or run ssh (unix specific) or run an http front end for Git. If I just have two Windows boxes and don't feel like installing Unix just to run Git, what is the optimal way to share the repos between the two boxes?
If both machines are in the same LAN, you can put the repo in a directory shared via the regular Windows network protocol (SMB).
(Disclaimer: I'm not certain about locking semantics for SMB, so it could be that simultaneous writes to the repo could corrupt it. Then again, the same probably holds for Unix.)
If you want easiest way, you have to see at SCM-manager
The easiest way to share and manage your Git, Mercurial and Subversion
repositories over http.
In order to have http-served repository with nice Web-frontend and management you have to have only Java (Java, not JRE)
Another alternative instead of running a virtual machine is to run all the Unix stuff in Cygwin. With Cygwin you can set up an ssh server on your windows machine as well as gitolite. And it runs natively on your hardware instead of a virtual machine.
Cygwin installation is very straight forward. It's just a single executable that downloads the packages you need. Keep the installer around because it's what you'll use to add and remove software in Cygwin.
Running gitolite on Cygwin is not as simple but just google "cygwin gitolilte" and you'll find lots of tutorials.
Git is a distributed version control system. So, in most situations, you don't need a dedicated program to serve the content in the repository, you just need a way to access the repository from both machines. One way of doing this is like #thomas suggested and placing a clone of the repository in a shared network location.
Another way that I have found successful in the past as a broke graduate student, is to use Dropbox as the "master" repository. Basically, you git clone your repository into your Dropbox directory, then you can setup Git on both machines to push/pull from the Dropbox repository. Dropbox will do the syncing magic in the background. This only works for mildly active repositories.
What I have done in the past is just run a VM with a small linux client on one machine through virtual box. You only need to port forward the ssh port and you're good to go - no need for configuring the network to something complicated on the VM.
This will allow you to run things like gitolite to manage users.
For this and many other reasons, I've switched to running Linux for all my machines and just run windows in a VM when I need to do Windows development. Lots of great services that you can run on Linux are more easily connected to from the guest OS than the other way around.
If you will have only the 2 windows machines, you can add a url to the remote, but ensure it is done via the file protocol. ie:
git remote add origin file:///\\some-server/share/repo.git
Some people claim that if you use just a path, git will try to make hard-links between the 2 repos. AFAIK, msysgit does not do this and you can use a path with no file protocol:
git remote add origin /z/somepath/repo.git
if z is mapped to a share on the other machine. I didn't need to run a server in your scenario.

How to setup PC and Mac for using git

I use git both for Mac and PC.
When pulling Mac's git from PC, it's easy as I can use ssh.
git clone smcho#prosseek:~/smcho/setup
The problem happens the other way round : to pull from Mac. I guess there are two ways to go.
Method 1 : Connect to server
By using 'connect to server' in Mac, I can make PC's directory like that of Mac. Even though, the file permission issue, it works pretty well.
Method 2 : ssh
I could run cygwin ssh server (cygrunsrv -S sshd) to be accessed from other computers, but for me, I have to wait quite a while to get connection as I explained here. It's almost impossible for to use it with git, as I don't want to wait for minutes to get clone.
Here comes my question.
Is there any better way other than the previous two methods?
Is there a (natural) way to support ssh server from Windows (windows 7 precisely) not using cygwin?
I've started using the philosophy of trying to stick in the native environment that something is designed for.
With that in mind, my windows box has an ubuntu server virtual machine that hosts my git repositories. The nice thing is the linux + virtual box + git is an awesome source repository that is completely free. No extra machine and you can give it very little memory so it isn't a resource hog.
There is even another option:
If you use both computers for developing and just want to keep the repositories in sync, you could create a bare repository and use something like Dropbox to synchronize it.
I see two other solutions :
using a third synchronisation server: GitHub, the most famous (if your program is OpenSource), but you can also find free online private Git repositories
on Windows, you can set up the Git server ('git daemon' command). On MAC, you'll access to the Windows repository using the URL git://ip_of_windows_machine/repository/
You might consider another approach entirely. If you're using git as a revision control system that you might consider a hosted account for mastering your repository, maintaining backups, etc. http://github.com/ is the leader in the space for git.

Setup a Git server with msysgit on Windows [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
My friends and I are trying to setup Git for Windows using the tutorial Git Server: Gitosis and Cygwin on Windows, but we just keep running into problems.
What would a "Setup Git Server" guide for Windows using msysgit be like?
There is a comment in the tutorial above suggesting it can't be done with msysgit because gitosis requires the use of an SSH Server and Bash? What is a step by step guide (as there is not one available)?
Install mysisgit
?
I found this post and I have just posted something on my blog that might help.
See Setting up a Msysgit Server with copSSH on Windows. It's long, but I have successfully got this working on Windows 7 Ultimate x64.
Bonobo Git Server for Windows
From the Bonobo Git Server web page:
Bonobo Git Server for Windows is a web application you can install on
your IIS and easily manage and connect to your git repositories.
Bonobo Git Server is a open-source project and you can find the
source on github.
Features:
Secure and anonymous access to your git repositories
User friendly web interface for management
User and team based repository access management
Repository file browser
Commit browser
Localization
Brad Kingsley has a nice tutorial for installing and configuring Bonobo Git Server.
GitStack
Git Stack is another option. Here is a description from their web site:
GitStack is a software that lets you setup your own private Git server
for Windows. This means that you create a leading edge versioning
system without any prior Git knowledge. GitStack also makes it super
easy to secure and keep your server up to date. GitStack is built on
the top of the genuine Git for Windows and is compatible with any
other Git clients. GitStack is completely free for small teams1.
1 the basic edition is free for up to 2 users
With regards to the reference to the Tim Davis page - Setting up a Msysgit Server with copSSH on Windows - I used this to get a Git server running on Windows 7 Home Premium 64.
Below is a postmortem/update of what I learned in addition to his instructions.
Like Tim Davis said, this was an arduous and frustrating process, at least for me - I'm not too good with integration of this sort, but I learned alot in the process. I hope my pain benefits someone else in the future, because this was an arduous process.
There is a step to copy all the Git
executables into your CopSsh bin
directory. Instead of copying files
and figuring out which files are
needed, add the git bin path to your
git path. I did so by modifying my
.bashrc and CopSsh profile.
Here's what I added to .bashrc (in your CopSsh and Windows home directory):
gitpath='/cygdrive/c/Program Files (x86)/Git/bin'
gitcorepath='cygdrive/c/Program Files (x86)/Git/libexec/git-core'
PATH=${gitpath}:${gitcorepath}:${PATH}
Here's what I added to the bash profile (in CopSsh etc/profile):
gitpath='/c/Program Files (x86)/Git/bin'
gitcorepath='cygdrive/c/Program Files (x86)/Git/libexec/git-core'
export PATH="/bin:$syspath:$gitpath:$gitcorepath:$winpath"
There is some duplication here - it works for me, so someone chime in which is the correct place to modify the path.
The newer msysgit versions might not give you
the screen to choose the ssh
executable where you choose between the Git
ssh and PuTTY ssh. You'll have to
set GIT_SSH manually if you use PuTTY.
I didn't follow one part of the
instructions and that was installing
Tortoise - I used the command line
instead as that's how I prefer to
learn a vcs like I did with rcs and Subversion and
found that to work for me. I had
problems with the clone command
using ssh. Here's how I did it:
Git clone using ssh - can't find repository
This is where I banged my head the most.
The CopSsh install directory was
/Program Files (x86)/ICW. I got
away with this, but if I were doing
it again, I'd use a directory name
with no spaces.
These other sources helped me figure things out:
Another way to setup a Git server
on Windows:
http://code.google.com/p/tortoisegit/wiki/HOWTO_CentralServerWindowsXP
The client side of things:
http://toolmantim.com/thoughts/setting_up_a_new_remote_git_repository
An explanation of Git as a server
(not related to Windows, but a more
in depth look than installation
steps):
http://progit.org/book/ch4-0.html
Plus O'Reilly's Version Control with Git - the Remote Repositories chapter.
In retrospect, if I had known how time consuming this would be, I might have started out with Mercurial as I read the install on Windows is easier, but I'll have an opinion on that after I work with Git awhile and then try Mercurial.
I am not sure why anyone hasn't suggested http://gitblit.com. Pure java based solution, allow HTTP protocol and really easy to setup.
After following Tim Davis' guide and Steve's follow-up, here is what I did:
Server PC
Install CopSSH, msysgit.
When creating the CopSSH user, uncheck Password Authentication and check Public Key Authentication so your public/private keys will work.
Create public/private keys using PuTTygen. put both keys in the user's CopSSH/home/user/.ssh directory.
Add the following to the user's CopSSH/home/user/.bashrc file:
GITPATH='/cygdrive/c/Program Files (x86)/Git/bin'
GITCOREPATH='/cygdrive/c/Program Files (x86)/Git/libexec/git-core'
PATH=${GITPATH}:${GITCOREPATH}:${PATH}
Open Git Bash and create a repository anywhere on your PC:
$ git --bare init repo.git
Initialized empty Git repository in C:/repopath/repo.git/
Client PC
Install msysgit.
Use the private key you created on the server to clone your repo from ssh://user#server:port/repopath/repo.git (for some reason, the root is the C: drive)
This allowed me to successfully clone and commit, but I could not push to the bare repo on the server. I kept getting:
git: '/repopath/repo.git' is not a git command. See 'git --help'.
fatal: The remote end hung up unexpectedly
This led me to Rui's trace and solution which was to create or add the following lines to .gitconfig in your Client PC's %USERPROFILE% path (C:\Users\UserName).
[remote "origin"]
receivepack = git receive-pack
I am not sure why this is needed...if anybody could provide insight, this would be helpful.
my git version is 1.7.3.1.msysgit.0
GitStack should meet your goal. I has a wizard setup.
It is free for 2 users and has a web based user interface. It is based on msysgit.
There is a nice open source Git stack called Git Blit. It is available for different platform and in different packages. You can also easily deploy it to your existing Tomcat or any other servlet container. Take a look at Setup git server on windows in few clicks tutorial for more details, it will take you around 10 minutes to get basic setup.
You don't need SSH for sharing git. If you're on a LAN or VPN, you can export a git project as a shared folder, and mount it on a remote machine. Then configure the remote repo using "file://" URLs instead of "git#" URLs. Takes all of 30 seconds. Done!
There may simply not be such a guide. If so, you may not have much luck convincing anybody to write one, because it would be a lot of work.
I would recommend either of two things. The easier one is to follow the guide you have slavishly, which means forgetting about msysgit.
The harder one is to put up a Linux server - perhaps as a guest under Windows using VirtualBox (free) or VMWare or Parallels (pay), and then follow one of the many sets of instructions Google will lead you to. But you will probably find those instructions are insufficient - they usually assume you've already set up an ssh server, for example, so you have to get that info elsewhere. I've done that twice, and can say that unless you're already something of a Linux guru, it will be a struggle.
I did what Bob Murphy suggested was the "hard" option.
I installed Ubuntu under VMWare Server (free) at work and then followed this guide on setting up Gitosis. I found it much easier than trying to get it going under Windows. Once it's set up you really don't have to touch it because Gitosis administration can be done from Windows by pushing updated versions of the gitosis.conf file. Any work I do need to do on the server directly is done via PuTTY so I don't have to use the horrible VMWare Server interface.
I've recently been messing around with VirtualBox at home and I've found it much nicer/easier to work with than VMWare Server, so it may be worth looking at that.
I just wanted to add my experiences with the PATH setup that Steve and timc mentions above: I got permission problems using shell tools (like mv and cp) having Git's shell executables first in the path.
Appending them after the existing PATH instead this solved my problems. Example:
GITPATH='/cygdrive/c/Program Files (x86)/Git/bin'
GITCOREPATH='/cygdrive/c/Program Files (x86)/Git/libexec/git-core'
PATH=${PATH}:${GITPATH}:${GITCOREPATH}
I guess CopSSH doesn't go along well with all of msysgit's shell executables...
I'm using GitWebAccess for many projects for half a year now, and it's proven to be the best of what I've tried. It seems, though, that lately sources are not supported, so - don't take latest binaries/sources. Currently they're broken :(
You can build from this version or download compiled binaries which I use from here.

Best way to interface between Windows dev platform and Linux test platform?

my project is a PHP web application. This applies to my test server (local), not production server! I am also the solo developer on this project (however, that may change in the very far future). Also, all my source code is committed to a repository and the production server gets the source code from the repository.
I do my development in Windows while my test server runs on Ubuntu (perhaps you can also recommend me another distro that is easy to use and can serve as a good web server). I need an elegant way to interface between the two environments. Currently, I do my coding in Windows and then FTP the changed files to the test server. However, this is quite cumbersome and tedious since I have to manually go to my FTP client each time. Suggest me something elegant please! Perhaps FTP sync? or OpenVPN (where the root www directory on test server is acts like a folder in Windows)? Thanks for your awesome time!
Easiest would be in Ubuntu, right click a folder then click "Sharing Options", then share the folder. In Windows, connect to the share, and work on that copy.
If you're using version control, using continuous integration like Hudson ( http://hudson-ci.org/ ) would help if you create a task that builds/exports the website for the testing server. This approach would be better in the long term, but you'll waste a day setting it up initially.
I prefer SFTP to FTP.
That said, ExpanDrive lets you map SFTP servers to local drive letters, which then means you can use any text editor to access your files directly on the test server, or use other mechanisms to keep the files in sync. Since they show up as two local drives, you can use just about any product out there.
If you want to use FTP, you can just map the drive in Windows Explorer. If you open up My Computer, then go to Tools > Map Network Drive, you can map a FTP server folder to any local drive. Just type in the address as the folder, ie. ftp://mscharley#192.168.0.10/htdocs
This will atleast save you a trip to the FTP client...
Is there any reason you couldn't just test on your local computer? At my job, we all develop and do developer testing locally, most of us using Windows. Our production and test servers are all linux based. Working locally is really nice, because you don't need to worry about making changes on the server with every small change.
Another option would be to create a checkout or working copy of your code on the server, and then run svn up or svn export (or equivalent using your version control software) each time you change the code on the server (assuming you are sshd into the server). This is kind of slow, but it's easy. The other option would be to write a script that goes through the svn logs for the recent commit and only exports or updates the ones that changed. This is much faster, and for all I know, there is already something out there that this.
Finally, some IDEs allow you to edit files live over ftp\sftp. Basically the IDE downloads a copy of the code and then reuploads it when you save.
Currently I develop on windows (PHP) as well and deploy on a Linux box for testing and production. This is how I do it.
Set up a local development server with e.g. WAMP.
Set up your code base in version control, e.g. Subversion.
Checkout your code base onto the testing/staging server, not just only on your local dev. environment.
In the early stages of development you want to deploy to the testing environment A LOT to sort out any discrepancies between your windows and linux environments. When your programming efforts turn more into program flow type programming this constant testing will probably slow down. But still take the effort to test on a regular basis.
To test your code base on staging do an svn update. I just log in with an SSH session to do this. A key thing here to note is that you do not have to make any config changes to your code base. If you do need to make config changes to your environment on staging it worth while spending the time to SCRIPT this process rather than this being a manual process.
Do the same for production. I use an Subversion check out on production as well. Make sure you set you .htaccess file to deny access to your hidden .svn folders and script the deployment especially if there a config changes necessary.
Some ideas:
Use a server environment under windows (e.g. EasyPHP).
Use a development tool that can save over FTP (e.g. ultra edit).
Use a network drive connected to the remote machine via FTP.
Use a network drive connected to the remote machine via Samba.
Run a linux distro inside a virtualization tool (e.g. virtual box) and write from the windows host to a share directory of the guest host.
Use dropbox to sync files between machines (there is more a hack than an "enterprise" solution).

Resources