I am a Mac-based (10.8) web developer, trying to work with other Windows-based developers. They are using SVN, although most of them do not check out files to local repositories. They mostly edit the file on the local server via Explorer, and then use TortoiseSVN shell enhancement to right-click and "commit" what they just edited.
I cannot seem to do this, as my preferred SVN tool Versions (as well as Dreamweaver CS6) require access with the SVN, HTTP, etc. protocols. I get errors trying to use the file system.
So, I am trying the command line, navigating to the file I need to edit, open it, edit, save. I can run svn status on the directory and I see the file status as "M". If I try svn commit -m "updated" myflie.css or similar, I get an error:
svn: Unable to open an ra_local session to URL
svn: Local URL 'file://webstage-01/svn/repository/fc-dev/assets/css' contains unsupported hostname
I looked in the .svn folder "entries" file an see this:
10
dir
20788
file://webstage-01/svn/repository/fc-dev/assets/css
file://webstage-01/svn/repository
2012-06-26T16:08:10.220007Z
20747
JSmith
So it looks like that's where it's getting the path from, which is not a valid MacOS or Unix path.
Suggestions?
It sounds like the local server is already a checked out working directory that everyone is sharing. This is the completely wrong and awful way to do Subversion. In the end, you have no idea who is making the change because they're all using the same client. Plus, there's no guarantee that working clients use the same format of the working directory. If someone has a version 1.6 TortoiseSVN on their system, they could damage that working copy.
The correct way is for everyone to checkout a local copy of what's in that Subversion repository to their local machine (Windows or Mac), and then do their changes there and check it in. You won't have the issue of someone messing up that directory. You know who is making the changes. You won't have an issue of what happens if two people try to make the same changes at the same time. It's the way Subversion is suppose to work.
The Mac has the Subversion command line client. (Assuming you're using Mountain Lion -- the latest release) You need to install XCode (free from the Mac App store), and then in XCode, install the command line tools. Look at the on line Subversion manual and learn how to do the checkout in Subversion, create your own working directory, and check in from that.
There are many options if you want a Mac OS X GUI Subversion client. I highly recommend you look at Pathfinder](http://cocoatech.com/pathfinder/). It has a built in Subversion GUI client, but it also has many Finder enhancements that make it an excellent Finder replacement -- especially for power users. It's $40, but I think it's worth it just for the built in Terminal client.
I don't think you can do that. The svn folders on "local server" were created by a platform-specific tool like TortoiseSVN on Windows. Obviously it will have paths, etc. specific to Windows. You will need to checkout separately and make commits.
Also, BTW, set the EOL property to 'native' so that you do not run into cross-platform EOL issues.
Related
On my home laptop with Windows 7 x64 (NTFS) some of mercurial repositories become stuck after unknown reason. The problem is when I try to run hg log or hg diff:
Can't access file
D:\user\my-hg-repo-root-path\='FRX'
In same time, icoming, pull, update, push, add, commit work well.
So, last several days i live without history or diff preview on the home laptop.
I've not found any reason for such a problem, as same as what FRX means. Do you know the reason of this problem?
PagerExtension?
That's where this ='FRX' might be coming from. Look at your ~/.hgrc.
It looks like this is a file that has been created by some windows application (from http://www.file-extension.com/files/FRX/: "As a binary form file, the FRX file extension can be found working with Visual Basic.") probably during an execution of VB programs, and it could be possible that you do not have the read rights on this file.
If this file is not important for you, I'd suggest to remove it from the working directory, maybe using admin rights.
Is there any useful tool that can store history of my folder locally like SVN does?
For example I can commit (however not to server but locally) or it can automatically track folder history.
The idea is to view history of my folder and rollback something or so (like in SVN but without server)
This is needes for Windows
Git should do the trick nicely. It is distributed so you can just use it locally without connecting to a server.
http://code.google.com/p/msysgit/
What you describes sound a whole lot like the core of distributed/decentralized version control systems (DVCS). The most popular DVCSs are Git and Mercurial (and Bazaar to some degree, though it seems an order of magnitude less widespread).
In fact, I'm doing precisely what you describe for some non-programming projects, with Mercurial (specifically TortoiseHg - the equivalent to TortoiseSVN) and it's working perfectly. Git long had a reputation for inferior Windows support and GUI tools, but I wouldn't be surprised if this has changed. I've never really used Git (wasn't ever dissatisfied with Mercurial, so I only use it for checking out the source of projects that use Git), so I can neither judge its fitness for your usecase nor recomment a frontend.
You can use even SVN (TortoiseSVN) with file:/// protocol for this task (create local repo without server)
I've been using Vim (MacVim) exclusively for months now, and I love it. Before using Vim though, I used Coda (I'm on OSX), and the one thing I miss about Coda is the way it marks my files for publishing via FTP whenever I edit them. I can then choose to upload the modified files single files individually, or to publish all of them in one go.
Is there anything that will do this or similar in Vim?
I'm aware netrw can edit directly over FTP, but I have all my sites running locally as mirrors of the online sites, so I need to edit locally and publish files remotely as and when I need. I've Googled for solutions but can't find anything.
I'm far more productive in Vim while in the editor, but having to open up an FTP program and hunt and peck to copy across files as I edit them seperately is a real pain, and makes me less productive overall when working on websites when compared to working in Coda.
Any suggestions welcome :)
Transmit, Cyberduck and YummyFTP (the ones I know) all have their own version of "automated folder syncing" where you work locally and any modified files are uploaded on change: you setup an "observer" and never have to hit a special button or shortcut again.
If you want to only use MacVim you could write a little command that uploads the current file on save: a script that would use the current file's path to construct an scp command. But this doesn't seem very portable/practical to me. It appears some people have already written something like that: here and there.
The right way is (not only in my opinion) to:
have everything under some kind of VCS like Git, Subversion or Mercurial or whatever floats your boat
write your code in a local clone/checkout and test the hell out of it on a local server
commit only working code
push milestones to a staging server used by you and your clients to test everything, this part can be automated via a post-commit hook or something like that
deploy only validated changes on your production server.
All the aforementioned Version Control Systems can be used directly from Vim's command line with :!git commit or :!svn update… If you need more abstraction, Fugitive (Git-only) or VCSCommand (multi-VCS, my choice) are here to help.
On your loss of productivity due to uploading files: I think it's very normal because you essentially perform very different tasks with very different neurological needs. This speed bump can also be experienced when previewing a layout change in your browser, looking up a color in Photoshop or any other similar task. I don't know of a way to pilot Photoshop, Chrome's dev tools or Outlook from within Vim and I don't think such a gizmo could reallistically exist so you will probably have to bear with it.
You can try git-ftp - a git based command line ftp client. Then you can manage your project as a Git repository, and git-ftp will only upload the files marked with Git - and only if they have changed.
The downside is that you are going to have to learn Git - and that's a bit overkill for what you need.
The upside is that you are going to learn and use Git.
I have since stumbled upon a Vim plugin which works with Transmit (which I happen to use as my main FTP client) and allows me to upload the current file to the server with a simple keymap (Ctrl+U) as I edit.
This strikes a nice balance between being a very simple solution, and one that does enough of what I need to improve my productivity significantly.
Any more suggestions are still welcome!
I LOVE using TextMate on my MacBook. It's great.
Unfortunately, I want to edit some files directly on my dev server, since it's difficult to recreate the environment locally. I'm using Git, so one alternative is to just edit locally, git commit, git push, and then git merge, but that's kind of complicated every time I want to make a simple change.
I'd rather just ... use another solution. One thing I tried is mounting a hard drive via MacFusion, and then loading that in an editor. But that's so freaking laggy/slow!
Has anyone cooked up a better solution?
OK - here is the one that works on Mountain Lion.
Go to http://osxfuse.github.com/
Install FUSE for OS X
Install SSHFS for OS X
Then the following commands on your terminal:
mkdir /Volumes/SSHFS
/usr/local/bin/sshfs username#host:/path/to/dir /Volumes/SSHFS
Done.
I would also recommend using the ReMate plugin as pointed out by another user to prevent TextMate from beach-balling every time you refocus it. Link:
ReMate http://ciaranwal.sh/remate
I use Fetch and TextMate for just such tasks. Fetch can be set to use TextMate as an external editor and can even automatically open files in TextMate by double clicking.
Saving the window in TextMate automatically pushes the file back to the server. Of course you would have to commit the changes on the server at a later time.
I'm sure most Mac FTP clients could do the same.
The best thing would be using TextMate's rmate script, follow the link and you'll find the instructions bellow, I recommend it since it will make your life easier and handle all the Nitty-Gritty.
I use the free version of TextWrangler for just this and it works great. I can load and save files over sftp.
The correct answer is to use sshfs and make sure "Perform atomic saves" is checked in the Textmate preferences window. The easiest way to setup sshfs is to use Macfusion. http://macfusionapp.org/.
Try one of these methods.
see: http://wiki.macromates.com/Main/FAQ#projects
also have a look at:
http://www.gnu.org/software/tramp/
You don't need to push every time you make simple changes; git is a distributed version control system, you commit to your local repository for the small changes. You should only push to the remote repository once you finished working on a feature/bug (or for really huge feature, a complete subfeature). Well, that's assuming you can recreate the environment; which apparently you can't.
A decent text editor can have integration with your favorite control version system; if you cannot configure your editor to commit and push from inside your editor, get a decent editor.
An even better editor can be set to save, commit, push, compile, and run your program all in one click or keypress.
If you are not able — for whatever reason — to replicate your environment locally and still want to use TextMate, the FTP client+TextMate combo is the best solution I can think of. MacFusion and all the other similar solutions are neat on the paper but awfully slow.
If you feel adventurous and confident enough to drop the TextMate requirement, SSH+Vim in the terminal works amazingly well.
Are you positive you can't replicate at all your remote environment?
I know this question already has several answers, and it's been a while, but I wanted to also point out DokanSSHFS - This will use SSH to make a local drive of the directory location on the server that you choose. Then you can use your editor of choice to edit the files as if they were on a local disk.
Most of the proposed solutions are centered around sshfs in one form or another. I have tried these solutions, but I found that reliability of filesystem is not always as good as desired.
There is tool called rmate, which allows editing of remote files in text mate.
Use command from ssh session to edit file on the server:
rmate file_name
The readme on github provides easy to follow instructions on how to set it up.
MacFusion is pretty sweet for free - basically ssh-mounting of directories.
http://macfusionapp.org/
Transmit 4 has a similar feature, tho it costs $$.
Try http://ciaranwal.sh/remate/ if it seems slow, as that will disable textmate from refreshing the file list so often.
Use Fuse for OS X http://osxfuse.github.com and the companion package, SSHFS (same URL) and install them. I installed the MacFUSE compatibility libraries from there too, just for good measure.
Then, install http://macfusionapp.org and follow the instructions located here ( https://github.com/osxfuse/osxfuse/wiki/SSHFS ) to configure macfusion to use the newer libraries.
I had trouble getting authenticated with password, so I set up ssh key authentication and used macfusion without password. Works like a charm.
If you do use an IDE, you could just set up an SSH tunnel to your dev server and edit your files from the comfort of your favourite IDE. Saving the files locally would automatically then push the files on the dev server as well
P.S: I am NOT endorsing the use of IDE
You need rmate it works fine to edit files on your server via ssh using TextMate on you local machine.
Github link here
rmate might be another choice. On server side, you type rmate /path/to/file. The file will be transferred to local machine, where you use some editor like Sublime Text or VS Code (TexMate may also work). To use it, one needs to install both server and client.
For server side, there are several ones in various languages. Choose one you like. Here is the Github repo.
On local machine, as far as I know, VS Code and Sublime Text have their extensions to receive files. For VS Code, refer to here. For Sublime Text, refer to here.
On the other hand, Microsoft just announced an official remote editing extension for VS Code (not released yet).
For those remote machines not having ruby or if bash not compiled with /dev/tcp, but has python, this works: https://github.com/scriptmaster/rmate-python
If you have pip:
pip install rmate
or simply:
wget https://raw.githubusercontent.com/scriptmaster/rmate-python/master/bin/rmate
chmod +x ./rmate
mv ./rmate /usr/local/bin/rmate
then rmate /path/to/file
especially if you are in a containerd-os with restrictions (with only python and docker) such as kubernetes-vm or gce-vm
you don't need vs-code-server, atom-editor,
We are currently using VSS for version control. Quite few of our developers are interested in a distributed model (And want to get rid of VSS). Our network is full of Windows machines and while our IT department has experience maintaining Linux machines they would prefer not to.
What DVCS systems can host their central repository on Windows while providing..
Push access to the repository.
Basic authentication. Mostly just a way to allow or deny access to the whole repository. No need for fine grained access.
Server process so users don't need write right to the repository reducing the risk of accidentally messing with it.
On the client side a GUI such as Tortoise would be more or less a requirement (Sorry, Windows shell sucks. :|). Ease of installation would be a huge plus as our IT department is already quite low on resources. And using windows credentials for authentication would be an advantage but not a requirement as long as the client is able to store the credentials.
I have had a (really) quick look at Git, Mercurial and Bazaar.
Git seemed to use ssh or simple WebDAV for repository access, requiring write permission for the users.
Mercurial had a built in http server, but this seemed to be only for pull purposes. Update: Mercurial supports push as well.
Bazaar Seemed to use sftp for repository access, again requiring a write permission for the users.
Are there windows server processes for any DVCS systems and has anyone managed to set one up in a Windows land?
And apologies if this is a duplicate question. I couldn't find one.
Update
Got Mercurial working for push purposes! Detailed list what was required can be found as an answer below.
Mercurial's almost certainly your easiest option on Windows.
If you didn't care about authentication, you actually can trivially allow hg serve to permit push. To do so, you merely need to add the following to the .hg/hgrc file in the repository you wish to serve:
[web]
allow_push = *
push_ssl = false
The first line says that anyone may push to this repository. The second tells Mercurial to allow pushing without SSL, since hg serve does not currently natively support HTTPS. At this point, users can push to your repository without having an account anywhere. If you're simply a small shop, that's probably fine--especially since you can use Mercurial's ability to sign changesets to guarantee a much higher level of verifiability than HTTP Basic will provide, anyway.
For a larger, shop, though, you'd be totally right in wanting at least a simple barrier for committing. To do that, you need to make two changes. First, you'll need to put Mercurial behind a web server with either reverse proxy support or CGI support. Thankfully, recent versions of IIS support both. You can consult the CGI directions in the Mercurial Redbook for Mercurial-specific steps, and Microsoft's guide to setting up CGI applications in IIS 6 for help on the IIS side.
Next, you'll need to set up some basic authentication. IIS provides HTTP Basic out-of-the-box, which, as a bonus, can authenticate directly against your domain, keeping administrative overhead to a minimum.
Finally, you'll want to change the allow_push line to support only specific users by specifying a comma-delimited list of user names. For example:
allow_push = benjamin, ted, the_cow
That's it. Mercurial will now allow push from users who can authenticate via HTTP Basic authentication, and allow pull from everyone else.
After Benjamin pointed out the HTTP serving CGI scripts I decided to try those out and managed to get a repository hosted over HTTP. The Redbook which Benjamin linked was of much help as were two Mercurial wiki articles. One which describes Mercurial publishing in general and another containing step by step instructions for setting up the HgWebDir CGI script.
These instructions weren't completely foolproof though so I had to poke around a bit. Most likely as I'm running 64bit Vista. The instructions below document what I did. Now that I've done it once I'd probably do things in another order so don't consider these step by step instructions.
Mercurial
First I acquired the Mercurial binary from http://mercurial.berkwood.com/ which got installed into d:\dev\Mercurial. I created a repository for testing under d:\dev\testRepo repository using hg init. The d:\dev\Mercurial\library.zip contains Mercurial library files required by the CGI script so they were extracted to d:\dev\Mercurial\library. Something which confused me at first is that when I opened the zip file I received an error message and saw no contents. Just extracting the file to a directory worked though.
For the web script, I downloaded Mercurial source which contained the hgwebdir.cgi which got moved and renamed to d:\dev\Mercurial\webroot\hgwebdir.py. The step by step article contains good instructions for modifying the hgwebdir script for Windows. They also contain instructions for hgweb.config which in my case ended up looking like this:
[paths]
/hg/hgwebdir.py/test = D:\dev\Mercurial\testRepo
Also the repository wanted the following config so I could push there without SSL. Note I am using Basic Authentication to authenticate users currently. I had to create the config in D:\dev\Mercurial\testRepo\.hg\hgrc and add the following lines to it:
[web]
allow_push = *
push_ssl = false
Python
The CGI script is a Python script so it requires Python. It's seems pretty picky on which Python version executes it. One of the articles mentioned that running it requires same version that was used to build the Mercurial. In the end I got it working on Python 2.5 x86 after trying Python 2.6 x64, Python 2.4, Python 2.5 x64.
IIS
Two things I missed and had to install were CGI support and Basic Authentication. Both of these were installed through Control Panel, Programs and Features. Once done with installation I created a virtual directory (Which I later changed to an Application) in IIS pointing to D:\dev\Mercurial\webroot. The virtual directory required an CGI handler for *.py files which could be added from Handler Mappings. The executable was D:\dev\SDKs\Python25_x86\Python.exe %s. Once IIS had permissions to the webroot directory I could navigate to http://localhost/hg/hgwebdir.py/test and see the repository.
So now the read access was working. When I tried pushing to the repository I received weird error messages telling me it wasn't a real repository.
After an hour of debugging I ended up copying the whole D:\dev\Mercurial\library\mercurial tree under webroot so that Python could find D:\dev\Mercurial\webroot\mercurial\hgweb\hgwebdir_mod.pyc. After this Wireshark was reportting Access Denied errors in the stack trace. No idea what the real reason to this was but changing the virtual directory into an Application in IIS and moving it on top of an application pool which ran using Local System account the access denied errors went away.
Also at some point I gave HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WinSock2\Parameters registry key more permissions so IIS could access it. Doubt that it requires these after using Local System account.
Once these were done pushing stuff to the repository using hg push http://localhost/hg/hgwebdir.cgi/test was working!
Problems and solutions
Where to find the library files.
They were in the library.dll under Mercurial installation folder. I just had to extract them even if my unzip program refused to view me its contents.
How to get the Python script to run
Download the correct Python version for x86 architecture as the script uses some x86 libraries. The correct Python version depends on the Mercurial version. For 1.2.1 it was Python 2.5 x86.
Alternatively you could try building Mercurial from sources with whatever Python version you want but in my case this failed when building extensions.
How to set CGI up in IIS
First make sure CGI is installed in IIS. This wasn't assumed to be true in the IIS instructions Benjamin posted.
Create a new Module Mapping for *.py in IIS Handler Mappings. The correct Module is CgiModule and the executable is your Python executable + %s
How to allow the CGI script to write to the repository
Make sure the script has everything it requires. I had to move the library\mercurial\hgweb\hgwebdir_mod.pyc to another place.
Make sure the script has permissions to everywhere it wants. I solved this by Creating a new Application Pool for the CGI script that used Local System account, converting the Virtual Directory to an Application in IIS and selecting the new Application Pool.
After reading Mikko's Answer which almost worked for me, I came up with my own notes for installation. My setup was designed to be a "non protected and open" repository that members of my team could use installed on a Windows 2008 Server.
1. Install Python.
The version of Python I used was Python 2.6.2 and I used the Windows x86 MSI Installer.
Install for all Users.
Install to C:\Mercurial\Python
Use Default Feature Options.
2. Install MinGW.
The version of Minimalist GNU for Windows I used was MinGW 5.1.4
Install the MinGW-5.1.4.exe.
Choose the Download and Install Option.
Choose the Current Package Option to Install.
For the Components to Install Select the "Minimal" option.
Install to C:\Mercurial\MinGW
3. Modify your path.
You need to add in locations to your environmental path at this point.
Add 'C:\Mercurial\Python26;C:\Mercurial\MinGW\bin' to the path (Order Matters.)
4. Install Mercurial.
The version of mercurial that I used was the latest release in the stable branch and I did not use the binaries, but used the source code. I wanted to compile mercurial myself so that it would work with whatever version of Python I had installed so I didn't have to worry about any compatability issues which I found to be the biggest challenge with other install methods. The easist way to get the source is by downloading the "zip" file.
Mercurial Stable Release
Extract Zip File to C:\Mercurial\Source.
Build the Source at command prompt.
python setup.py build --force -c mingw32
python setup.py install --force --skip-build
5. Modify your path.
You need to insert into your environmental path another location for the 'hg' command.
Add 'C:\Mercurial\Python26\Scripts;C:\Mercurial\Python26;C:\Mercurial\MinGW\bin' to the path (Order Matters.)
6. Create your Config file.
You need to have a default user name set if your going to do any commits locally on this server.
Create file '"C:\Documents and Settings{username}.hgrc"'
[ui]
editor = Notepad
username = your_name
6. Test your Install.
Open up a new command window and test with 'hg debuginstall' to validate. You should see something like the following.
Checking encoding (cp1252)...
Checking extensions...
Checking templates...
Checking patch...
Checking commit editor...
Checking username...
No problems detected
7. Setup Web Directory.
Create Directory 'C:\Mercurial\Web'
Copy the hgwebdir.cgi file from the 'C:\Mercurial\Source' to 'C:\Mercurial\Web'
8. Configure IIS7 for Centralized Repository.
I used the DefaultAppPool which is using .Net 2.0, Pipeline=Integrated, Identity = ApplicationPoolIdentity.
Ensure CGI features are available in IIS7.
Control Panel/Programs/Windows Features/IIS/App Development Features/CGI
Add App into IIS on the Website you wish.
Alias=Mercurial -- Physical Path=C:\Mercurial\Web
On the App select HTTP Modules and add a new Module Mapping.
Request Path=*.cgi, Module=CgiModule, Executable=C:\Mercurial\Python26\python.exe %s, Name=Mercurial.
When Prompted to add entry to ISAPI and CGI restrictions list say yes.
9. Test your Web Setup.
You should now be able to browse http://localhost/Mercurial/hgwebdir.cgi and see and empty repository list.
10. Configure IIS7 for Friendly URL
I did not like having the unfriendly URL and this step allows us to remap the URL to something more friendly. Install the URL Rewrite Moduel 1.1 Extension for IIS.
On the Mercurial IIS Application in IIS Manager featurs View select URL Rewrite Component and install a new Rule.
Choose Add Rules, then the Template 'Rule with rewrite map.' Rule Action=Rewrite, Specify Rewrite Map=Mercurial
Add a mapping Entry. OriginalValue='/Mercurial/Repo', New Value='/Mercurial/hgwebdir.cgi'
11. Create Mercurial Repository
You can now create a test repository.
Create a Directory C:\Mercurial\Repository and ensure IUSR account has the permissions to write to the directory. (If on Domain account is more like IUSR_{ComputerName}.
Create file C:\Mercurial\Web\hgweb.config to list the repositories.
[paths]
/ = C:\Mercurial\Repository\**
Add a directory C:\Mercurial\Repository\Test and initialize the repository with 'hg init'
** If you want now to be able to push without ssl create in the .hg directory of the repository a hgrc file the following lines.
[web]
allow_push = *
push_ssl = false
References:
Mercurial Wiki Windows Install
HG Book
Step by Step
Publishing Mercurial Repositories
For a team taking the first step away from VSS I would have suggested using SubVersion for source control and either TortoiseSVN or VisualSVN for the client.
But if the team has made the decision to switch to a DVCS then I'd suggest Mercurial because of it's better support for HTTP and windows on the client via TortoiseHg.
If you're looking for:
Distributed development support
Run Windows servers seamlessly
And a great GUI
You're exactly describing Plastic SCM
Excuse my necroposting and shameless self-promotion, but I've just released an alpha version of HgLab, which is a Mercurial Server for Windows with full pull-push support and Active Directory integration.
SCM-agnostic (to some degree) Windows-solution with Repository-frontent and management today may be SCM-Manager (Git, Mercurial, SVN repo out of a box with a single requirement of JVM)